In the context of agile, process improvement frameworks are analagous to defined software development processes. They pre-define the characteristics of a mature functioning software process, rather than permitting empirical measurement, goal setting and adjustment.
Oddly, the CMM identifies the most mature software processes as optimising and describes them in a very similar way to how Schwaeber would describe empirical process control. However, they anticipate that software processes transition through less mature structures first (repeatable, defined and managed).
- Measurement is domain specific
- Improvement is an on-going activity
- Requires whole team participation
- Best effort assumption
- Working harder won’t improve the process
- Blaming is pointless and counterproductive
- Root causes, not symptoms
Process
- Data is gathered from a variety of sources, including project team members and automated tools. Some additional metrics may be synthesised from this data.
- The data gathered is then used to evaluate the project team’s performance in the previous iteration and identify root causes of problems.
- The team may identify a whole range of potential actions to take as a result of the previous iteration.
- Finally, the selected actions are implemented during the next iteration.
- The effect of implementing these actions will be reviewed after the next period of work is complete.
Root Cause Analysis
Five Whys
The first release was delivered late.
- Why?
- Integration took longer than expected.
- Why?
- A number of incompatabilities emerged late in the sprint.
- Why?
- Integration was performed at the end of the sprint.
→ We should perform integration throughout the sprint. Note that ‘5’ is a heuristic - the root cause may be revealed by asking the question why more or less times. A good guide to whether you’ve identified the root cause is to ask whether applying the proposed solution would prevent it from reoccurring in the future.