The Effect on Productivity

Overall our measurements didn’t just tell us that employees were happier and teams more stable; they also showed that the company’s delivery was significantly faster and of higher quality than before self-selection.

Measuring productivity in software development is difficult, and as far as we can tell, no one has discovered the perfect measure. Our way of understanding and tracking overall productivity was driven by finding measures that may not be perfect but drive the right behaviors. Therefore, we chose to focus on the following metrics:

• Throughput: the number of user stories shipped within a time period

• Cycle time: the time from when work begins on a request to when it is deployed to end users

• Quality: the number of bugs on production and failure demand, that is, work necessary to correct errors and shortcomings

The company’s average cycle time was cut in half over the course of a year and quality measures also indicated significant improvements.

While we knew these were measures that could be gamed and manipulated, we had chosen them specifically for this particular reason: Most people will attempt to “game” any metrics or key performance indicators (KPIs) they are presented with, and gaming these metrics will bring positive outcomes.

Slicing features into smaller user stories and releasing to production more often—for example, to increase throughput numbers—would generate only positive outcomes. It would only increase our ability to generate value early and lower the risk of building big features.

Since self-selection we’ve seen a significant rise in the number of user stories shipped to production. Our hypothesis that stable squads made up of people who had chosen to work together would be more productive proved to be true. The days of disbanding squads at the end of a project just as they were starting to work well together or disbanding them because we, as managers, had gotten the team composition wrong seemed a long way behind us.

Of course, improving productivity doesn’t create success; it’s possible to run fast in the wrong direction after all. We saw more features being released and also more products and improvements that users loved. It wasn’t all about getting stuff out the door, though, because the healthier our squads became, the more they would collaborate with the product owners. They would often have new feature ideas, question the value of prioritized features, or find new and innovative ways to test concepts early.

As discussed earlier in the section Today’s Work Demands Stable Teams, research by Rally Software showed that stable teams are up to 60% more productive. Our company saw similar results, and our throughput doubled over the course of the first year.