In the last post, we looked at the traditional approach to project management in terms of how scope, budget, and schedule relate. Now we’re going to make a couple of shifts in how we look at the resulting triangle.
When looking at this triangle through an Agile lens, we make two fundamental changes. The first is how we view our requirements. Each requirement is prioritized from the most valuable to the least. Our picture looks remarkably similar:
We still may estimate our budget and schedule the same way AND we may still have a deadline (real or arbitrarily set).
The second fundamental change is how we execute the work; we will execute in iterations (we could also execute in a flow-based approach with the same effect). This produces working software starting with the most valuable requirements first. In each iteration, we have working software as a product. Our value production now looks like this:
As we produce the most valuable items first, we get an initial bang. Then each iteration is slightly less bang as the value of items decreases. Our iterations have everything needing to be done to have our product potentially shippable.
Now we have lots of choices of when to be done. We may decide the project delivered enough value early and after fewer than the planned number of iterations. This happened on a USDA project I had within the Branch I managed. We released early and at less cost, not because Agile promises anything cheaper, but because the amount of value our customer (as defined by our product owner) decided was good enough for what they needed and they had other higher value needs for the money.
Or we could hit the hard deadline and release what has been built because we’ve produced something that works and has some value, though it may not be as complete as we like. Again at USDA, this happened while I was working on a program in support of the American Recovery and Reinvestment Act of 2009. By being able to release, we provided working software to the program and its customers so that loan applications could be received when the customer was required to receive them.
With the concentration of ‘milestones’ occurring at the end of iterations and producing working, releasable software, quality is baked in. A separate beauty of this approach is I only need to know the details of what I am starting work on at the moment, not in the future. It’s rolling wave planning to its fullest.
So with that said, there are lots of avenues to explore? What are your concerns or interests? Let me know and we can explore them here together.