we go - not just at the end.
With some minor investment we've made performance testing a part of the build verification process, and we use the final build of the day to performance test the most complex areas of code. We also create an ongoing performance benchmark that evolves as the complexity of the application evolves. This allows us to compare the transaction response times between nightly builds to detect and address problems early. We introduce performance testing into each sprint with a simple user story such as "as a user of [application] I want to experience the same performance level when performing [some action] when there are [x] number of users on the system." Any performance-related issues that we uncover that cannot be addressed during the current sprint for "whatever reason" are addressed in a "hardening sprint"—a final sprint for every release that has no planned features, but is dedicated to quality improvement. In some cases this sprint has no other purpose than to address outstanding minor issues to improve the overall quality of the product.
The Journey Continues
Our Agile transformation is far from complete. My guess is that we'll always be on the journey. In fact, continuing to learn, refine and improve is really what Agile is all about. However, we have already reaped tremendous benefits from our efforts. Our teams are happy and productive, and we have doubled our yearly release capacity. Finally, we have driven down costs, especially in the area of "reporting overhead"—those days (or weeks) every month where management is gathering data and reporting status are gone. I certainly feel the evidence is building that the Agile approach can yield transformational results.
By nature, Agile promotes visibility. Daily stand up meetings and sprint reviews give excellent views into how projects and teams are progressing. However, in the enterprise, visibility must extend beyond the team room. Project managers need to be able to see how their teams are progressing, department heads need visibility across a portfolio of projects, and management needs to be able to look at all of these projects and teams from an organizational perspective for effective decision making. The key is to have the visibility be automatic—not require team members to change the way they work - reporting has become more of a monitoring effort and we have learned that we must carefully handle real-time unfiltered information.
The Right Tools
Trying to cram a tool down a team's throat is a recipe for failure. However, scaling Agile to an enterprise is impossible without them. If you provide tools that truly map to the way the teams work, supporting them and enabling them to be more efficient and collaborate, they will adopt them.
Borland's executives are committed and enthusiastic about the transformation. They attend sprints and sprint reviews (obeying all the protocols), and they make it a point to showcase and reward good sprints. They have also learned to accept that with visibility comes empowerment and responsibility and[BU9] to treat news as not good or bad—just news.
Agile for the business, not for the sake of Agile
For Agile to work in an established software organization, management must be flexible and pragmatic in the application of Agile principles. They must also be judicious in selecting projects and teams for transition. Allowing teams to be a little bit different in their Agile adoption and adjusting to account for different types of work projects can yield big results. And, it is absolutely critical to have the historical data and analysis capabilities to understand how your Agile projects are performing (are