Improving Productivity

ABOUT THIS CHAPTER   How do you summarize effective Agile’s approach to process in four words? My answer is, “Fix systems, not individuals.” I talked previously about decriminalizing mistakes, which is important. But decriminalizing mistakes does not mean ignoring them—it means coming together in an open, respectful, collaborative way to understand the factors that led to the mistake and changing them so that the mistake cannot happen again.

A common misimplementation of Agile is, “Work as fast as possible”—but this prevents ever really getting better. More effective Agile implementations concentrate on going faster by getting better.

Scrum as a process improvement baseline

If we go back to the days of Software Capability Maturity Model (SW-CMM), Level 2 was a “repeatable” process. That established a baseline that supported measured improvements at higher levels in the SW-CMM. A high-fidelity Scrum implementation accomplishes the same purpose. The Scrum team has a baseline process that it follows consistently, and the team can improve from there.

Process improvement guidance

The desire to improve productivity is pervasive, but how do you know whether your team is improving? How do you measure productivity?

Although software productivity is next-to-impossible to measure on an absolute scale, story points and velocity provide a way to measure productivity improvement on a relative scale, and that sets the stage for dramatic improvements in productivity.

Comparing a team to itself over time is the primary, valid use of story points for productivity measurement. If a team had been averaging 50 story points its first 5 sprints, and it averaged 55 story points its second 5 sprints, that suggests that the team’s productivity has increased.

Team productivity improvement

The first step in improving productivity is to establish a measured, believable productivity baseline using velocity, as described in the previous chapter, “More Effective Agile Measurement.”

Once you have established a velocity baseline, you make a change and compare the team’s velocity for the next few sprints to the baseline velocity. After a few sprints, you’ll gain insight into whether the change increased or decreased productivity.

Here are some examples of changes whose effects you can measure by using velocity over time:

• You introduce a new collaboration tool

• You change part of the technology stack

• You move the Product Owner from onshore to offshore on a geographically distributed team

• You tighten up your Definition of Ready and spend more time refining stories before implementation work begins

• You change your sprint cadence from 3 weeks to 2

• You move your team from cubes to an open work bay

• You add a team member partway through a release

A change in the numbers will not always be definitive, of course. In general, with productivity measurement, it’s good to adopt the attitude that, “Measurements give you questions to ask and suggest places to look, but they don’t necessarily give you the answers.”

What’s possible with team productivity improvement

Short sprints provide frequent opportunities to experiment with process changes, track the results of changes, and build on the successful changes. Improvements accumulate rapidly with this approach. We have seen teams double their productivity or better.

Some implications of this can be unexpected. We’ve seen multiple instances in which teams wanted to “vote a problem team member off the island” because of poor performance. In each case, the story was similar. The manager asked, “If we remove that person, will you commit to keeping your velocity the same?” The team responded, “No, we will commit to increasing our velocity, because that person is dragging us down.”

In another instance, we worked with a digital content firm that had teams at two sites. The first site had a team of 15 staff members, and the second site had a team of 45. Through rigorously tracking its velocity, monitoring work in progress, and analyzing its wait states, the team at the first site concluded that it was spending more time and effort coordinating with the second site than the second site’s work was worth. The second site was retasked to a different project, and the original project’s overall output increased with just the 15-person team at the first site. They effectively quadrupled their productivity through a disciplined use of Agile productivity measures.

Organizational influences on productivity

Scrum experts repeat this mantra: “Scrum doesn’t solve your problems, but it shines a bright light on them so that you can see what they are.” Sometimes Scrum exposes issues the team can work on by itself, and sometimes it exposes issues that need to be addressed by the organization. Organizational issues we have seen include these: