As much as I like agile, I know that it has its limitations. In fact, I’m dealing with one such limitation on a current project.
This project is fairly large and pretty nebulous. Though the business goals are clear (i.e., we know why we’re doing it), a lot of other things are not. We have many open questions about both business requirements (what specific features/functions we need to build) and technical underpinnings (what’s the right set of technologies for this problem).
Our initial approach to doing this project was firmly based in a standard agile methodology. We compiled a backlog of epics, prioritized them, picked the most important ones, decomposed those, defined acceptance criteria, and began executing.
As we went along, it quickly became apparent that something wasn’t working. The team was unhappy with a lot of things: no clear direction, a lot of meandering, lack of a shared understanding, and, most alarmingly, an apparent lack of progress.
Now, it’s important to note a couple of things here. First, this was a group of smart, dedicated, and experienced engineers. Second, there was a lot of work being done by everyone. In other words, this was a strong team that was doing everything they could think of to succeed.
Yet it wasn’t working and we wanted to figure out why. Here’s what we found.
We Build, Therefore We Are
Agile 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 Are
But 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
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.
Submit an article or tip
