Presenter Dave Nicolette
Objectives
Participants will learn how to measure and monitor agile development projects in a way that is meaningful to all stakeholders, based on certain key principles of agile thinking:
- Track and report everything necessary and nothing more. (Simplest thing that could possibly work; maximize the amount of work not done.)
- Ensure all stakeholders receive timely, accurate, and actionable information relevant to their respective roles. (Transparency, collaboration, continuous improvement, early delivery of business value.)
However, relatively few real-world situations are ideal. Therefore, participants will learn about organizational characteristics that may call for additional measures beyond the minimum necessary to track a mature agile team working in a supportive organizational culture. We will discuss metrics that are useful in the following circumstances:
- agile team in an agile organization
- mature agile team in a traditional organization
- immature agile team in a traditional organization
Management in a traditional organization needs to learn where waste exists in their current software development process. We can track measures that make this clear. For example, in the case of an immature agile team working in a traditional organization, we can show trend lines to follow (a) number of tests, (b) number of test passing, (c) number of tests that used to pass but that are now broken. Obviously, there is no value in tracking these measures separately for a mature agile team, because they will ensure all tests are passing anyway. Immature teams are usually not very disciplined about this, and it will be meaningful to track these three items separately. We can then use the metrics to show management where a certain form of waste exists and how agile methods address the problem. This can help us gain support for agile adoption in the organization. The same metrics can help the team in its continuous improvement effort.
Contents
Since an agile team delivers working software in every iteration, it is possible to measure results rather than elapsed time. Since each feature has customer-defined business value, it is possible to measure the business value delivered to date at any point during the project. Since the team is delivering real business value regularly, it is possible to measure their delivery effectiveness. Based on measures of their delivery effectiveness, it is possible to measure the success of the team's continuous improvement efforts. Since the solution is elaborated incrementally, it is possible to measure software quality attributes continuously throughout the project to avoid defects and technical debt. Because any impediment to delivery is exposed quickly, it is possible to identify and mitigate risks early and, if necessary, cancel an ill-advised project before losing too much money.
This presentation describes the various stakeholders who may have an interest in knowing the status of an agile project, which particular pieces of information each of them needs and at what level of detail and frequency they need it, what the measures mean and how they can be used. It deals with variations in the maturity of the agile team; why certain metrics may be meaningless for a mature agile team yet essential for an immature team. The presentation also covers variations in how metrics may be compiled and reported to satisfy stakeholders who are skeptical of agile methods and to support change agents who need hard data to support their case for further agile adoption in the organization. It also shows how patterns in the trends of metrics across multiple iterations can expose subtle process smells and agile execution problems that may escape notice in day-to-day work.
Format and length: 60 min presentation