We Build, Therefore We AreAgile methodology is designed to produce. Everything you do on an agile team is geared towards one goal: building things. This mindset of delivery impacts a lot of things. It impacts how people think and communicate about the work they do (i.e. stories) and the progress they make (i.e. story points completed). In fact, agile teams measure progress (and by extension success) primarily by how much they’ve built. Agile practices also have built-in safety checks to ensure that the team is continuously focused on delivery. Consider what happens when no cards are finished in a given iteration (the dreaded “zero velocity”). If the team is any good, a retrospective for such an iteration will inevitably involve a lot of soul searching and brainstorming on how to get back on track. In short, agile teams are conditioned to equate building things with success.
We Learn, Therefore We AreBut what if it’s too soon to start worrying about building things? What if there are too many unknowns to work through? How do you evaluate progress when you can’t complete story cards? Our team struggled with this very issue. There was a cognitive dissonance that formed in everyone’s mind: since we’re not building anything concrete, we must not be making progress. And if we’re not making progress, we must be failing. Well, making things is just one way of making progress. Another is learning things. For instance, one of the core principles of the Lean Startup movement is validated learning. It works through a simple yet effective process of hypothesis testing. By formulating and then testing hypotheses, the team seeks to learn. What they learn leads to more hypotheses, a change in direction (pivot), or stoppage. So, we decided to modify our approach and adopt these ideas. Instead of trying to build a feature, we look to learn. Instead of writing stories, we formulate hypotheses. Instead of showcasing functionality, we review findings. By the way, we’re obviously aware of spikes as a way to deal with unknown and answer questions. In fact, you can certainly call what we’re doing a kind of extended spiking. Whatever you call it, I think the key is to have a disciplined, structured approach to iteratively build up understanding.
Why Does This Matter?This seemingly subtle shift in mindset from delivery to discovery makes a surprisingly big difference. Suddenly, spending time investigating something that aids in testing the hypothesis doesn’t feel like a distraction or a waste of time. Getting an answer, even a negative one, feels just as satisfying as building something. Generating and pursuing more hypotheses feels like progress is being made. This is important because people and their outlook on things are important. Success and failure are both infectious. When you’re succeeding, you’re motivated to succeed more. When you’re failing, you’re motivated to give up.
Haven’t I Heard All This Before?Dan North wrote about this very phenomenon in his post called “Introducing Deliberate Discovery” a couple of years ago. In it, he recommended systematically going after unknowns in order to reduce ignorance and risk. We were certainly inspired by his insights when trying to figure out how to deal with our situation. In fact, we decided to use the hypothesis testing metaphor to implement the concept of deliberate discovery on our team. Let’s see how well it works out.
You may also like:
Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!