Enthusiasm vs Readiness: Sustainable Pace for Organizational Change
CASE STUDY SNAPSHOT
Industry: Financial Services
Organization Size: Large
Topics: Reference Model, When to Scale
Website: Alex’s website
“Looking ahead too much at big change can sometimes make you forget where you are and what the next step is.”
Imagine picking up a book and feeling like the author could have been a fly on the wall in your team meetings, or in your boardroom–that the challenges experienced and tackled in the book are the very challenges that you face as the leader of your organization. That’s exactly what happened when the leader of a Financial Services Company with a 24% year over year growth rate picked up “Scrum: The Art of Doing Twice the Work in Half the Time”.
This organization wasn’t in trouble. They were consistently listed as one of the top 5000 fastest growing companies in the United States. They weren’t looking for a rescue, but they were looking to continue their great trajectory by creating a proactive transformation.
As a first step, Alex and his team visited the organization. They talked to the customer-facing teams and leadership, who were based in one state, then went to the software teams located in another state. They found that the initial statement was correct: the organization was not just heavily Waterfall but almost Anti-Agile; in fact, the business analysts were forbidden from talking to software developers.
Alex and his team started the engagement by mapping out the different value stream processes. This enabled them to identify their biggest bottleneck and best opportunity for intervention: the Florida software teams. They decided this was the best place to stand up their reference model. He got them organized into 6 cross functional teams and began Scrumming in 1 week Sprints. Many of the business Analysts became Scrum Masters and the Product Team became Product Owners.
As soon as the reference model began scrumming, cultural concerns started to emerge. There was confusion around where the logistics fell when using Scrum. Managers who were used to defining their authority by those that reported to them felt lost and feared for role security. There was a layer of Department heads used to controlling budget, hiring and vacation time. This wasn’t brought up when discussing a change to Scrum because this was an area the company didn’t want to change. Learning this the hard way made clear the need for greater transparency and communication.
Despite the challenges, company survey results showed a huge improvement after just 8 Sprints. Communication Adequacy improved from 1.9 to 3.6 on the 5-point scale. Prioritization went from 1.7 to 4.1 and Transparency improved from 2.0 to 3.9. Moreover, the teams were able to deliver considerably more value each week than they ever had before. The design teams quadrupled their velocity and throughput and the legacy code teams doubled theirs! Perhaps most impressive was the fact that this increase in velocity enabled the teams to focus on remediating the technical debt that was building up and significantly improve the quality of the work being delivered. Prior to adopting Scrum, the team of teams had a backlog of 100 bugs and it was consistently growing. After 8 weeks of using Scrum, the backlog of bugs was down to just 17 and shrinking, an 83% improvement in quality in just two months.
These are remarkable results, and perhaps even more impactful are the lessons learned along the way. So, remember, enthusiasm isn’t readiness. As Sheive cautions, “looking ahead too much at big change can sometimes make you forget where you are and what the next step is.” Instead, he urges those involved in transforming to Agile ways of working to “make sure you know where you are starting. Dig deep on this.”
Organizations considering changing their way of working to achieve true business agility should establish a strong understanding of their starting point, taking into consideration both the bad things they want to change, as well as the good things they want to keep in place as the organization evolves. And they should make this visible to the teams. As Sheive advises, “make sure everyone is clear on what will and won’t change… especially for managers, or you get friction and a vacuum of speculation.”
Who is Alex Sheive
Alex is a Scrum Trainer, Scrum@Scale Trainer and Coach/Consultant at Scrum Inc. He was first exposed to agile software development in 2000 at Thoughtworks, where he was fortunate enough to rub elbows with multiple future authors of the Agile Manifesto and since 2008 he has used Scrum to build software both as a lead developer and entrepreneur. He has found Scrum to be transformative on projects ranging from financial risk systems to DIY gaming platforms. Alex is a digital nomad who has traveled literally around the globe, living in nine different countries while only getting food poisoning in three. He enjoys speaking about technology (2x SXSW presenter) and mentoring entrepreneurs on lean product development based on his own successes and failures.