Scrum@Scale Case Study
Systematic: From Good to Great
Strengthening the definition of “Ready” for Product Backlog items helped Systematic double their process efficiency.
“Systems can be measured and data magnifies learning. Careful attention must be paid to the human dimension because poor use of data will destroy productivity.”
– Carsten Jakobsen and Jeff Sutherland
CASE STUDY SNAPSHOT
Trainer Name: Carsten Jakobsen
Organization: Systematic
Organization Size: Large
Industry: Software Development
Topic Backlog Decomposition and Refinement, Product Ownership
Date: 2009
Website: https://agileeducation.org/trainer/carsten-jakobsen/
Summary
In 2009, Scrum@Scale Trainer Carsten Jakobsen began working with Systematic, a large international software development company. Upon collecting some initial data pertaining to high-performance patterns in the company, he noticed that two projects in particular were performing two to three times better than the rest. In this case study, Carsten demonstrates the importance of the pattern of ready, and related measures of process efficiency, in bringing teams to a higher level of performance.
Starting Scrum@Scale From a High Baseline
Systematic is a robust systems and software integrator with customers in over 50 countries and over one million users worldwide. Their core business areas are in the public sector, healthcare, defense, intelligence and national security, and information management. According to a whitepaper prepared jointly with the founder of Scrum, Jeff Sutherland, Systematic has a level five Capability Maturity Model Integration (CMMI) certification.
By 2009, Systematic’s highly-educated workforce (62% have advanced degrees) of 1,000 people had been using Scrum for two years. And so Carsten wanted to understand both in qualitative and quantitative terms precisely how the two high-performing Scrum teams were doing so well, even given the strong Scrum baseline in the organization.
Understanding “Ready”
Qualitatively speaking, he found that the two high-performing teams encountered challenges, performed detailed retrospectives, and generally spent time investigating what they had done once they had done it. Quantitatively, he wanted to understand how to take the learning from these two teams and bring this performance to the other three teams under consideration.
He discovered that these two teams, labelled A and E, had an average productivity of 140-192% and 258-365%, respectively. What Carsten found was that, in both cases, the Scrum Master of the team would not allow work to enter a Sprint when it was not yet “Ready.” So, when a Product Owner came forward with work that was more of an idea than a concrete task, the Scrum Master would ask the Product Owner to refine the idea to the point where Scrum team members could break the idea into a palette of discrete, implementable tasks. In order to carry this learning over to other teams, a checklist is available to determine when an idea is Ready to enter a Sprint (an example can be found in the whitepaper).
The Results of the Ready Pattern
The notion of the flow of story implementation is a measure of the productiveness of a team. Here is an example of this measure. If a story has two days of effort to implement and has five days of calendar duration to complete, then the flow of story implementation is 40%–i.e., this is the ratio of the projected implementation effort to the calendar duration of implementation. Carsten discovered that, prior to the SMs insisting on only Ready tasks entering a Sprint, teams average flow of story implementation was 23%. And, after only Ready tasks went into a Sprint, teams averages a flow of story implementation of 55%.
Even as Systematic grew from a company of 500 to 1,000 (between years 2014-18), their process efficiency remained stable with high flow and productivity. An analysis of work resulting from only Ready tasks entering a Sprint showed higher customer satisfaction with the product and also higher team satisfaction. Projects can pattern the success of these learnings by documenting their practice in a Ready checklist and ensuring features are prepared properly before they are decomposed into stories committed in a Sprint.