Beware of Gaming of Measures, and Inspect and Adapt

Make sure measurements reflect actual improvement

As you work on process improvement, be sure that improvements are genuine, not just changes in what work is being measured or team composition.

Different teams take different approaches to what kinds of work are assigned story points (which is one of many reasons that cross-team comparisons are such a challenge, and cross-organization comparisons are pointless). Some teams assign story points to defect correction work, and some don’t. Some assign story points to spikes, some don’t. Some of these variations work better than others, in my experience, but what never works is changing the kind of work that counts as story points instead of making genuine process improvements. If you find a team that’s gaming its measures, treat that as an opportunity to decriminalize the mistake. Take a systems view of the behavior, and fix the system that’s causing the problem. According to the “Mastery” part of Autonomy, Mastery, and Purpose, teams generally want to improve.

If you find a team that is gaming the system rather than using measurement to improve, investigate what is undermining the team’s natural desire to improve. Is it excessive schedule pressure? Insufficient time for reflection and adaptation? Lack of permission to make process changes that would lead to improvement? This is an opportunity to reflect on your performance as a leader and assess the effect that’s having on your teams.

Inspect and Adapt

In addition to the formal retrospective, the Inspect and Adapt mentality should apply end to end on Agile projects. Scrum provides several structural opportunities for Inspect and Adapt to occur:

• Sprint planning

• Sprint review

• Sprint retrospective

• Any time a defect is discovered to have escaped beyond its sprint

Effective use of Inspect and Adapt depends on having some impatience. Teams that are patient with their problems end up living with them for a long time and not improving. Teams that insist on doing something about their problems can improve incredibly rapidly.

Effective use of Inspect and Adapt can also benefit from some structure and transparency. We’ve had success with teams putting proposed process changes into their product backlogs and prioritizing and planning process improvement work along with their other work. This helps avoid the failure mode of retrospective findings becoming “write-only” documents and avoids the issue of too many changes being made at one time.