user stories that apply to improved test automation or more detailed feature documentation. These planning sessions not only help us improve both the product and our process, they are tremendous in engaging the entire team in the process of shaping a release (critical to driving a sense of ownership). Transparency in an Agile environment really means the entire team owns the release and must have enough information in order to determine a true course of action.
Extending and supporting collaboration and visibility in an enterprise environment
As we scaled our Agile efforts, we began to understand the need for tools to support the teams' collaboration, enable information sharing, and ease the process of reporting to management. It was quickly apparent that the traditional cork teamboards, index cards and sticky notes we were using were not going to scale as we expanded the reach of Agile in our organization. In addition, since our transformation was an initiative that had visibility at the highest levels within our company, we needed to provide visibility into our processes, a defined way to gauge our progress, and the mechanism to measure it. As such, we developed a set of applications to support our Agile transformation. TeamDemand connects marketing and the field with product management and engineering, providing a way for us to collect, evaluate, prioritize and track all of the requests that come into the development organization. We use TeamFocus to manage the execution of both our Agile and traditional projects, and our teams use its "virtual corkboard" in their daily stand ups and sprint reviews. Our managers, including myself, use their TeamFocus dashboards to track "in-flight" metrics—defects, test coverage, requirements volatility—across their project portfolios, while upper-level management gets the "big picture" on how the organization as a whole is performing through TeamAnalytics' business intelligence dashboards.
Beyond Acceptance: Infusing Performance Testing into Agile
A great deal of the discussion in the Agile world as it relates to testing seems to be centered around the need to do acceptance testing of features and functionality. However, moving to Agile development does not in any way eliminate the need to do performance and scalability testing. In the more traditional development models this testing is done at the close of the release cycle—the absolute worst possible time to uncover performance issues (especially ones that are related to architectural design). Done properly, Agile provides a mechanism to overcome the shortcomings of the final "testing" phase.
During our transformation, we found that to achieve the benefits of Agile while maintaining acceptable product performance levels we had to make an upfront investment in the code development effort and in performance benchmarking. Basically, in order to enable performance testing to take place iteratively, our development teams had to slow down and learn how to develop the code in a way that would make this possible. First, we made it clear to all teams that performance was a team responsibility and that working code performing badly may not be considered "complete." The result was a slight slowdown in code development, which ultimately enabled us to speed the overall process and improve performance.
As we got more sprints under our belts, we learned many practices that would help us translate this principle into results. We now ensure that there are sufficient hooks in the code to do performance benchmarking and to avoid the need to re-work critical performance testing scripts. We also make the distinction between performance testing and scalability testing, which includes things such as memory leaks or time to-restart which require extended calendar time. Making this distinction allows us to performance test as