I have been working with Scrum teams since 2009. I had no training but needed to find a way to help my team produce more value for our customers. I had just built a continuous integration process for a team of 9 folks. With this one change, our teams incidents after release were reduced by half, and our ability to move from dev to test environments went from days to hours. With this organizational win, I earned the trust to try more changes.
Our delivery team read Agile Delivery with Scrum by Ken Schwaber and Mike Beedle. We started doing stand-ups, identified a scrum master, and created a continuous delivery pipeline. We went from a quarterly delivery schedule to monthly sprints. Daily life was a bit more messy, because our shorter delivery cycles highlighted issues that had been with us for years. We knocked the challenges down one by one, usually in collaboration with other groups and departments. Within months our shorter times to delivery and reduced bugs in production were no longer wins that were celebrated, but instead became the norm expected of us.
When I left that group we still had challenges, but the transparency we created allowed our management and our customers to know what we were delivering and when. We went from deploying and releasing code in an overnight process to one where our deployments were completely disconnected from feature releases. We turned over feature release to our customers and they could manage releasing their features when it was most convenient to them.
I worked with several groups after that and saw similar results. Leadership was often skeptical and conservative to accept change. As they saw success and gained more control on their features, they wanted more and more.
I have since learned more about Lean, Agile, and Scrum in particular. I believe that the success of these teams to management and leadership are due to:
- Reduced time from ideation to delivery
- Reduced incidents after deployment
- Faster Time to resolution when incidents do happen
- Increasing the number of deployment/release opportunities
I think the teams involved embraced Scrum because of:
- Increased psychological safety when introducing change
- Increased autonomy of tasks
- Opportunity to self-manage and make changes that improve daily development processes
- Opportunity to see customers and the value they are bringing to them
I do not think that Scrum is a silver bullet for organizations. It only works when there is engagement and trust in and around development teams. Transitioning teams to Scrum and improving Scrum teams is often messy and shines a spotlight on problems that have been there all along. This spotlight sometimes causes people to believe that Scrum is the problem rather than a mechanism that highlights problems.
When organizations move from a command and control system to one of self-managing teams, I have seen large scale changes and improvements over time as I listed above. I look forward to working with organizations wanting to make that shift.
Leave a Reply