I was thinking over the weekend about how to present certain aspects of agile to non-technical people. One aspect of agile that is particularly difficult to get across is the idea of accepting change. It feels wrong, at least in an industry like the defense industry, with carefully negotiated contracts and a history of cost overrun, to say that agile prefers accepting change over following a plan.
At the same time, I firmly believe that agile, much of the time, reflects the way we really do engineering when we do it right. So I figured there had to be similar behavior on good programs that I could point to.
Quite a while ago, I heard a story from a former Marine colonel who had worked in the Pentagon putting together budgets. This was around the time when computers were first becoming usable for these kinds of tasks and portable enough to have handy and running during the planning meetings.
Each budget cycle, the approvers would look at the list of items that were not funded, and would identify a number of things that just had to get funding. For the first time, with a computer handy, the team could make that change in the meeting and immediately see the results.
The effect was enormously positive, because it changed the nature of the interaction. Instead of the approvers insisting on a course of action, and the budget team finding a way to make it work (or having to come back and admit failure), the team could make the change immediately, and immediately present the results. At that point, they could say, “Yes, sir, we have made that change. Unfortunately, this means that those essential barracks upgrades have now fallen below the line and won’t be funded. What would you like us to do?” The whole structure of the interaction changed in order to put the people making the decision in a position to be responsible for the consequences of that decision.
I think there are two important things about this story that we can apply to the idea of presenting agile’s acceptance of change. The first is that our relationships with customers are better when we can say “yes” instead of “no”. Too often, I’ve seen engineering leads in meetings with customers come across as telling the customer what the customer wants, because they are concerned about scope growth if they accept what the customer is saying. Unfortunately, the customer does not have the detailed insight into the budget or the differential cost of the approach they want, so they just hear someone saying “no”.
Second, the agile methodology of accepting all changes, but putting them into a prioritized backlog, not only gets the customer to take responsibility for the impact of changes that they request, but it empowers the customer as well. If a customer sees a feature that’s already been implemented, and requests changes to it, the team can come back during the next release planning and say, “Dear Customer, we have room for these items in the next release. Would you like us to spend time changing something that already works, or implementing new functionality?”
The best part about this is that there is no wrong answer to that question. It might sound like we’re treating the customer as if they are stupid, and are teaching them a lesson for having the wrong priorities, but we’re not. The customer might say, “Actually, that new functionality that I thought was very important is not a big deal, but the changes I requested are absolutely essential to how we use the system. So do the changes first.” And that is perfectly fine! Even in a tightly-negotiated contract there is room for changes, especially trading one item of scope for another. The best-run programs I’ve seen engage in that kind of friendly horse-trading all the time, as something is harder than expected, or priorities change, or the customer realizes that what they asked for is not what they wanted when they see it.
Again, this goes to a belief I have seen validated many times by agile teams, which is that good agile teams look a lot like good teams using any other methodology. To me, the advantage of agile is not that it brings in all kinds of new practices. Rather the advantage of agile is that it makes official the practices that good teams and good leaders were already doing, while under a traditional methodology that practice might have been “outside” the methodology or even officially discouraged by it.