How We Reduced Cycle Time from 164 Days to 8 Days in 6 Months

BACKGROUND

In December 2020, my friend Adrian Galarza and I delivered a Scrum.org Scrum Pulse Webinar - A Cycle Time Journey: 164 to 8 Days in 6 Months that summarized the journey of Adrian’s Scrum Team. Some key topics that we covered in the webinar were…

1. How do we define “cycle time” in our context?
2. Why should a business care about reducing cycle time?
3. What adjustments were made in the entire organization as part of a 4 year Agile enablement?
4. What challenges was this specific Agile Team facing when this journey began?
5. What 4 key sets of adjustments made by the specific Agile Team that is the subject of this case study?
6. What were the 7 key outcomes that were accomplished as a result of reducing cycle time?
7. Besides a reduction in cycle time, what measurable improvements were made in increasing forecast reliability and throughput?
8. Who were the 7 key roles and communities that made these improvements possible?
9. What are the 6 key recommendations we would like you to consider if you want to create similar outcomes in your context?
10. How can you learn more?

Due to horrible time-management on my part, we could not answer all the questions in the webinar, so we are answering them in this blog instead. You might get more value from reading this blog if you watched the recording and reviewed the slides that are available on the webinar page - A Cycle Time Journey: 164 to 8 Days in 6 Months

We have organized attendee questions in 3 broad categories and answered them below…

 

ORGANIZATIONAL CHANGE LEADERSHIP

VISION: What was the mission and vision for improving this cycle time?

We tried getting everyone aligned on following the agile values, agile manifesto, and improving flow throughout the system. These were more of a North Star to guide us instead of specific Vision or Mission.

 

METRICS: What metrics did you use?

We use the standard metrics like…

1. Velocity - # of Story Points ”Done” (DOD included deployed and usable in production)

2. Cycle Time - # of Business Days for a Sprint Ready PBI to go from Active to “Done”

3. Defect Count – Cumulative count of open defects

4. WIP Aging - Average age of PBIs that are started but not done

5. Velocity Attainment – Actual Velocity as % of Target Velocity.

 

EXECUTIVE REPORTING: How was the progress reported to executive management that is used to Gantt Charts type reporting?

We review progress in sprint reviews, which our stakeholders almost always attend. I think this is the most important.

We also built on-demand dashboards that include trends in the indicators Executives cared about the most…

1. Release Burndowns
2. Release Forecast With Cone of Uncertainty
3. Open Defects
4. Open Impediments

Most importantly, we've built a culture of psychological safety, transparency and regular, measurable improvements that has earned stakeholder trust for our team.

 

STAKEHOLDER ENGAGEMENT: How did the scrum masters engage stakeholders outside the team to show up and collaborate more?

It took many conversations in Sprint Reviews as well as on 1-on-1 discussions with stakeholders. Additionally, it took getting leadership alignment and consistent messaging from all levels.

 

CHANGE RESISTANCE: How did you overcome resistance from people who wanted to work in the traditional, waterfall way?

It took alignment between all our leaders and consistency of messaging that they all delivered to all teams. This also took decentralizing our deployments from a Change Control team and giving the scrum teams more autonomy over deployments to Dev and QA. We also streamlined our legacy deployment process into CI/CD pipelines which removed a painful friction to frequent deployments.

 

ROLES & RESPONSIBILITIES

PO: Should the Product Owner be on IT side or Biz?

In my opinion, I would first look for defining characteristics in a PO. I would seek on who is available to the team, motivated about the role, trusted by stakeholders, and is able to learn quickly. A bonus on top of that, would be deep knowledge about the business processes relevant to your product. This blog might help you select the right person for the role - The Professional Scrum Product Owner: A Starter Job Description

 

BA: How did you overcome the challenge of BA’s not understanding how the system is built?

The person who previously played the role of the BA re-interpreted her role by helping with backlog refinement. We did not have a culture where one person like the BA is supposed to have all the answers about how the system is built. Instead, we built a culture focused on asking the right question, making it safe for team members to be vulnerable and admit they don’t know the answer and by making it safe for team members to request and receive help.

 

TESTER: You use “tester” word in your context. Does Scrum allow testers?

I used the word in context of the function they were performing at that time and not as a role or title. In my team, we do functional and regression testing in both manual and automated ways. It's also done by our developers, business SMEs, product owner and end users.

 

UAT: How did you overcome the cycle time delays due to the old-fashioned way of conducting UAT (i.e. in environments like Dev, QA, UAT, etc.).?

To shorten the feedback loop and reduce risk, our business stakeholders are part of our Scrum team and conduct UAT inside the Sprint. UAT is part of DOD.

 

CADENCE & RELIABILITY

CADENCE: What was the sprint cadence you folks started off with? What was sustainable cadence after improvements?

We've maintained two-week sprints the entire time with our team. In addition to all 5 scrum events, we added a pre-planning meeting at the halfway mark of the sprint to look ahead at the next sprint. This gave us insights into what was coming up next. While the large majority of PBIs for the next sprint had already been refined by this point, pre-planning gave us a chance to see if we needed to adapt or further refine any PBIs that are coming up in the next sprint.

 

RELIABILITY: How did you help the team create reliable sprint forecasts? My teams often overcommit and typically roll over some points.

We were also overcommitting earlier in the team's evolution. This took alignment with leadership on messaging.

All leaders consistently delivered 2 messages to the team…

• The ultimate measure of success is delivering valuable, high quality working software and not maximizing the story points forecast at the end of Sprint Planning.
• It was important to minimize WIP and WIP-age.

We created on-demand dashboards that anyone could use at any time to visualize trends in these indicators and we inspected these trends at each Sprint Review.

Since the team got a consistent message from leaders on what mattered, we discussed obstacles and made adjustments. As Peter Drucker said, “What gets measured gets managed.”

 

CONCLUSION

Remember that organizations are complex adaptive systems made of these pesky, weird, unpredictable organisms called human beings like me. Blindly copy-pasting what worked in our context to your context and expecting our results might be a recipe for disaster. As mentioned in the webinar, understand the underlying principles and values that guided us and find the practices that make sense in your context. Be prepared for failure and disappointment. Persist, inspect and adapt until you get it right. It is so worth it.