Lesson: Agile Development with Ian McFarland

Step #6 Questions: Asking questions is the single most important habit for innovative thinkers

There are lots of interesting little tidbits of classic Agile theory and one of them is the five whys. The idea with the five whys is when you're doing something you want to ask yourself why are you doing it. Then you want to do that again, "And why is that important?" The idea is by five times asking yourself "why" you usually get to the right thing. The idea is that there are exactly five whys, and the idea is like "So we're trying to ship on Thursday."

"Why are we trying to ship on Thursday?"

"Well there is a News Week article that we want to be timed with against."

"Why do we care about that?"

"Well it's actually by this really influential person."

And you may come to the conclusion that it is totally the right thing to do. And you may come to the conclusion like actually you are solving the wrong problem. Or like "Oh we're having real trouble with caching."

"Why do we care about caching?"

"Well because we are having a performance issue."

"Well how is the performance issue affecting us?"

"Well it is reducing the engagement on site."

So you sort of get to the core question of why. Sometimes you will find a whole different pathway to solve the problem by really understanding and stepping way back. Usually the last why somewhere out there is because we are trying to increase customer satisfaction, increase revenue, do something that's business related. So putting it into that context sort of attaches it to why we should care and it helps us prioritize better. It helps us to frame the real problem we are trying to solve instead of the local local problem we're trying to solve.

Good Agile and good Lean are about shortening feedback cycles. With anything we're doing, there is a nonzero likelihood that we're doing it wrong, that we're not doing the most effective thing we could be doing, that the results that we are expecting is not the result that we will get. So, shortening the time for feedback on anything that you do is a core idea in Qlink theory, it's a core idea in Agile, it's a core idea in Lean. What thing you're looking for feedback on varies by where you are, macro- and micro-scale. In a test, for example, you might be looking for a test that does invalidating in the shortest possible time that adding these two account balances results in the thing that I want. So that's the kind of feedback and you can make that feedback loop incredibly short. You can run the test in a few milliseconds. So you've now reduced the risk that you're going to predicate a bad decision on incorrect information from a previous decision. You've shortened that down.

The same is true with product risk. Having continuous deployment means that you're getting stuff in front of customers as quickly as possible. Doing good paper prototyping before you've built anything really gets value in front of customers. It helps you to understand if you're actually solving a meaningful problem before you go investing a bunch of money in it. Because the fact is software takes about the same amount of money to produce per hour regardless of whether it's producing value or not. The cost side is isolated from the benefits side. There's a certain minimum amount that you need to produce in order to produce this business value.

The classic example that Eric Ries talks about in his book is when they spent six months building this elaborate integration with all these chat servers for IMPU, and it turns out nobody cared. He could've literally spent that six months on the beach doing nothing, and it would've produced just as much business value and would've been much less aggravating. Of course, conversely, really what would've been better, they could've then started the next experiment the next day and started to find out, no really, what people want is the Avatar stuff. It's not only the six months of effort, but it's also the six months of time that elapsed. You shouldn't have been on the beach. You should've been the next day out there with the sketches saying, "Hey, how about this?" And then finding signal in the market so that then they could've accelerated. They were still successful, but they could've accelerated their success by six months and not burned all that capital and all the rest of it.