Today there's no shortage of organizations undertaking an agile transformation. However, when you ask many of those organization's leaders why they are pursuing an agile transformation in the first place, more often than not their answer is “agile makes us go faster.”
But, despite the pervasiveness of this answer, it has one glaring problem:
Agile does not make you go faster.
In fact, it's not uncommon for agile teams to begin to slow down early in their agile adoption. This can be due to a multitude of reasons, such as teams learning to work together in a new and different way, teams adjusting to the world of adaptive planning, or teams placing a greater focus on quality at the point of creation, rather than holding quality concerns until the end.
But, then what does it do?
But if agile doesn't make you go faster then what's the point? The point is that agile lets you get to market sooner, which is actually much more powerful.
An agile approach encourages your team to work in smaller batches, which allows you to release those batches to market more frequently. This ability to release to market more frequently brings a host of other, much more important, benefits beyond simply letting you go faster.
One such benefit is that a more frequent release cycle enables you to respond to customer requests and feedback more often since the lead time between request and delivery is shortened significantly. This also means that you can respond to other developments much more quickly, such as unexpected developments in the marketplace or surprise moves by your competitors.
Another benefit is that you can now start to realize a return on your investment much sooner than compared to a traditional release cycle. By getting your product into market sooner, or at least a small slice of it, you now have the opportunity to begin to generate revenue from each newly released slice of product. That revenue can help to repay the cost of initially developing your product's first release as well as help to fund the development of later releases. This can be of significant benefit since creating a product that at least partially funds later iterations of its own development can significantly change the economics of that product.
The common of theme across each of these benefits is that while each can make your team appear to be moving faster, none of them will actually cause it to do so.
Discovering the right path
But shorter release cycles coupled with a decreased time to market actually bring with it another, less often cited benefit.
If your team were to simply go faster then the chances are good that they'll realize their objective sooner. However, simply going faster makes no guarantee that that objective is actually the right objective.
But increasing your number of releases also increases the number of learning opportunities for your entire organization. This means that not only do you now have more chances to discover what the right objective of your team is, but you also have the opportunity to do so further upstream. This is because each release to market is an opportunity to inspect the results of that release, both in terms of market acceptance and customer response, and then to determine how to adapt your product accordingly before the next release.
Becoming a learning organization
Intentionally creating additional learning opportunities as a result of releasing your product to market more frequently is the first step to helping your organization become a fully capable learning organization. Moreover, this change can be incredibly powerful because as the marketplace becomes both more dynamic and more competitive, only those organizations who have successfully embraced their future as a learning organization will survive.
Want to learn more about how to make agile work on real teams? Check out my course, Agile in the Real World from Pluralsight, for tips and techniques to help your organization get the most out of their agile adoption.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.