In my last five columns I addressed six of the key behaviors essential to Agility in projects: Learning and adaptation, collaboration, customer focus, small self-directed teams, embracing Lean principles, and Progressive Requirements Elaboration. In this article, I will address the next key characteristic: Incremental Delivery.
This approach to developing systems has withstood the test of time because it mitigates many of the risks of system development. It narrows the scope of each increment to a specific set of problems, making those problems more tractable. At the same time, it limits the integration issues, because only a limited collection of new components are being integrated at any one time.
The only real complication that is introduced by the use of incremental Development is Regression. Every time an increment of functionality is added to a previously working system, there is the danger that it will regress -- that functions that worked previously will mysteriously stop working. But we have developed rigorous Regression Testing methods to limit the number of regressions that can escape our notice.
Incremental Development works -- which is why the Agile methods use it.
"This is what we have built so far. Is it what you need? Are we moving in the right direction?"
Agile teams seek their customer's acceptance of the product-to-date after each iteration of development. The team has done their best to build what their customer told them to build. That includes good engineering work, comprehensive testing, and whatever else was needed to build a high-quality product.
But in the end, quality comes down to satisfying the customer's needs. If we miss that mark, then all of the other good work we have done is wasted. The only person who can tell us if we are building the right product is the customer. So in addition to all of our other quality activities, we must seek our customer's acceptance of the functionality we are building regularly throughout the project. Waiting until the project is over before seeking their acceptance is as counter-productive as declaring that the patient is cured before we check for a pulse.
Because the Agile approach is so customer-centric, it only makes sense that we would seek their acceptance regularly. That way, we can never go very far off track. When any increment of the product moves in the wrong direction, they will tell us loudly and clearly that something is wrong. And that will allow us to quickly get back on track before things have gone too far wrong.
The purpose of incremental delivery is to get feedback on what has been developed to date. Demonstrating the product to one or a few customers and asking their opinion will gain us a certain amount of valuable feedback. But how much more feedback could we get it the product was actually used in production?
It is for this reason that Agile teams look for opportunities to promote their product-to-date into production as early and as often as it can be done. Obviously, there will be limitations on how early or often they can do this. But if the project is planned with incremental release in mind, it can often be done successfully. For example:
Collaborative Users -- Pick out a small subset of system users who will be willing to engage with the development team in this way. They must recognize that early releases do not constitute the final product, and that each incremental release is another step toward fully satisfying their needs. And of course, they must willingly provide the feedback we need, or the effort of making multiple releases will be wasted.
Tolerance for Change -- How often these users can accept new versions of the product is an important consideration. If they can accept quarterly changes, then releasing after every few iterations would be possible. In the best of circumstances, they would be able to accept a new version of the product-to-date at the end of every iteration!
Critical Mass -- Then identify the critical mass of basic functionality that is necessary for the product to be viable for those users. That can be your first release -- the basis on which much more functionality will be built. And depending on the size of that critical mass, that first release could happen quite early in the project.
Delivery into production provides the ultimate in feedback as an Agile team is developing a product. A truly Agile team will seek out these opportunities.
In the final article of this series, we will discuss how all of the behaviors we have covered so far are planned and managed. Tune in next time for our discussion of Iterative Planning & Adaptation.