PM Articles > Alan S. Koch > What Makes a Project "Agile"? Part 6: Incremental Delivery

What Makes a Project "Agile"? Part 6: Incremental Delivery

The Essence of Agility
What makes a project "Agile"?
Part 6: Incremental Delivery

by Alan S. Koch, PMP

When developers claim that they are "Agile," how can you know that they're not just hacking? Their methods are unorthodox, even weird! Is there a way to see if they know what they are doing? The Essence of Agility consists of those sets of observable behaviors that distinguish a truly Agile team from a bunch of hackers claiming to be Agile.

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.

Incremental Development

Incremental development is not a new concept. People have been developing systems incrementally for decades. And although Agile projects build the product in smaller increments than we traditionally think of, the basic premise is the same. First, build a foundational framework, and then add functionality onto that framework a little at a time.

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.

Customer Acceptance

What is unique about the Agile approach is what we do with each increment of the product after it is developed. Rather than just continuing on with developing the next chunk of the product, an Agile team will bring the product-to-date to their customer for his or her reactions.

"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 regularly seek our customer's acceptance of the functionality we are building. 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.

Delivered to Production?

The phrase "Incremental Delivery" mainly refers to the Agile team's delivery of their product to their customer for acceptance. Every Agile project does this at the end of every iteration. But Agile teams would prefer that "delivery" not stop there.

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.

Becoming More Agile

If you already practice some form of iterative development, you already have the basis for doing incremental delivery. And adding this piece of Agility to your toolbox can be done before many of the others are in place. It is an important enabling practice for many of the other parts of the Agile methods.

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.

Related Links
Conducting retrospectives after each iteration allows the team to improve the next round for themselves and their customers. Big, visible charts keep everyone up to date on what's completed and what isn't. Even non-Agile teams can use techniques like spiral project phases to incorporate incremental delivery.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

How would you manage the quality of the product, if every requirement cannot be defined before the development?

What are the minimum set of processes that would be implemented for agile/ iterative development?

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.