How can we deliver faster with Scrum?

Scrum and 'moving faster' are treated synonyms in leadership discussions.

Not sure from where did they get this idea of expecting everything to happen in a fast space by embracing Scrum?

Let us discuss today in this blog what are the aspects an organization embracing Scrum has to focus on faster delivery.

Borrowing this image from the internet where someone like me would have stumbled upon in the first place to understand the different roles in Scrum and the aspects they focus on. Here again, we see the role of Scrum Master focus on 'Build it Fast' and this could also be one of the reasons for leaders to drive better efficiency over time.

I resonate a lot with what Maarten Dalmjin originally wrote on 'Stop talking so much about the three different Scrum roles'

Anyways what more I can write about that topic when Maarten has voiced his views already.

Coming back to our focus in this blog post on 'Delivering Fast' with Scrum, here are few tips for practitioners to consider:

Work Items in Smaller Units

Remember to always come up with smaller units of work that can get done easily within a Sprint. Try leveraging the real benefit of continuous Product Backlog Refinement. The Product Owner should ensure there is just enough work for the Scrum Team to pull and accomplish within the Sprint. Remember Bill Wake's Twenty ways to Split Stories'.

Another interesting blog post by J B Rainsberger also comes in handy on how to split Product Backlog Items vertically and small enough.

Limit the Work In Progress

Collaboration amongst team members ought not to be seen as a complicating activity but rather as a simplifying one, in so far as work in progress is limited and transparency over it is improved.

Most of the time the Scrum Teams struggle to get the work done at the end of the Sprint and the primary reason being, a lot of Product Backlog Items (User Stories) remaining in progress. An increase in Work in Progress promotes multi-tasking and context switching delaying work getting done. Some of the useful tips to focus on a few and get it done are:

1. Set Work in Progress limits and never start new Product Backlog Items until in-progress ones are finished. We can try this not only with Kanban but also with Scrum Teams and see results.
2. In Sprint Planning, have a plan in mind of when stories will be worked on and delivered within the Sprint. This is definitely not a promise or commitment made on the pull sequence but an opportunity to draw a forecast and work towards it.

Focus on Outcomes & not on Outputs

The biggest challenge called out by organizations practicing WIP limits is on the utilization front. According to me, that is fine as long as the Sprint Goal is met at the earliest. A classic analogy is that of a toll road express rides to fully utilized city roads and the challenges with the ever-growing traffic.

Remember what happens with accidents, bad weather, road repairs, etc in both scenarios. I don't need to explain what would be better.

Given the complex nature of work and uncertainty throwing a lot of surprises, definitely focus on Output measures like Stable Velocity, Say-do Ratio, 100% utilization, etc are going to slow down from real progress to happen.

Instead, we need to bring more focus towards realizing customer outcomes and value delivered with 'Being Faster'

Wrap Up!

Even though I've shared what I do know a little around faster delivery, am not fully convinced of tagging 'Speed' with Scrum as the best thing to happen.

Given the empirical mindset embraced by Scrum, Speed is not the ultimate thing as a benefit in front of learning and helping the customer solve their problems delivering early and often using Scrum.

Feel free to read, like, and share your views/feedback in the comments section.