once a sprint is started the train has left the station. The work cannot be interrupted and no changes can be made.
The benefits of this approach in terms of our ability to rapidly respond to changes in the market or customer needs cannot be overstated. In one instance, a market event caused us to shift priorities around several key features of one of our products mid-stream. We were four months into development, and were facing significant changes that were key to deliver the "right" product. If this had happened in a traditional delivery environment, we would have been "back to the drawing board" and quite likely would have needed to add another six months to the project schedule. Instead, we were able to adjust course, shift the remaining sprint priorities and cut that additional time in half.
Transformed Customer Relationships
The Agile approach to delivery involves a material change in the way the delivery organization interacts with customers. At a time when many companies are seeking to be more customer-focused, Agile provides a model for development organizations to collaborate with their customers to drive greater levels of satisfaction. Customer relationships under Agile can - and should - evolve into outright partnerships.
This is extremely powerful, but can be potentially dangerous if it is not managed correctly. In an Agile environment, customers have near complete visibility into the development process. They participate in sprint reviews and have access to early versions of the code. Throughout the process, they provide input as to whether you are meeting their needs or not. For these reasons, it is critical that you ensure customer profiling is a part of your evaluation when choosing projects to transition to Agile. Selecting customers who are willing to participate in the process is extremely important.
We were fortunate, in that the customer in our first Agile project was clearly a partner, and as the process unfolded, the benefits exceeded our expectations. Once the customer became used to frequent releases, they no longer felt the need to try to get every possible request into the next release. They knew the schedules, they understood how work was being prioritized, and they could see the impact of changes. This created the opportunity for us to have real discussions on priorities, since releases could be staged in terms of weeks - not years.
Crafting the conclusion of this article was somewhat difficult because the story of our transformation continues. We still have a lot to learn. And that is part of the beauty of Agile. As an empirical process, it leaves room for continual discovery, growth and improvement. Will Borland ever be 100 percent Agile? It is possible, but unlikely. And, I believe that most enterprises that begin to shift to more agile approaches will find themselves in similar situations.
My job is to maximize my resources in order to efficiently and predictably deliver results - in the form of high-quality software - to my business. So, as we continue our Agile transition, I also continue to learn what types of projects, and frankly more importantly, what types of teams deliver the most return from transitioning to Agile. Managing a broad portfolio of products in different stages of their life cycle and investment priorities is just a fact of the business.
Thanks to the visibility that Agile methods automatically encourage, we are a much more transparent organization and we have achieved much stronger operational oversight. Our teams are happy and productive, and we have increased our number of releases per year by 100 percent. Finally, we have driven down costs, especially