Recently a client told me that they were adopting the Spotify Model. Which sounded great at first. Spotify has published some great articles and videos about how they have grown and transformed their organization to be agile. Then it occurred to me that what he was saying was completely wrong.
Scrum is a framework for developing, delivering, and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.
Sprints, standups and story points have come to symbolize Agile methods much like burgers, fries and cola symbolize fast food.
Ready for your Agile Happy Meal?
I hope not.
Like researchers of fast food, we now know that the Agile Happy Meal contains unnatural ingredients that decrease agility and cause process indigestion.
In 2007, a series of experiments led my colleagues and me to increase our agility by dropping story points and velocity calculations.
Those same experiments led us to replace fixed-length sprints with a flow-based workflow, and move from standup meetings to frequent team huddles.
Our process today looks nothing like a by-the-book, mainstream Agile method largely because we actively look for process waste and experiment to discover better ways of working.
In this blog, I'll explain why we dropped story points and velocity calculations and what you can do to work successfully without them.
Combining agile and non-agile into a jerry-rigged mishmash misses the point of working in an agile way. Teaching people about agile and agile terms doesn’t need a newfangled management-speak hybrid. Traveling around the country to visit the 25 exemplar services, I saw people who had traditional project manager backgrounds but who had seen the benefits of agile. Agile isn’t just a set of rules, it’s a mindset. An approach to solving problems and meeting user needs. Let’s not lose sight of that.
My opinion is clear now, the more you empower teams to choose their stack and platforms the more they feel like they own the overall solution, the more they want to make it work and show the world their choice was not only correct but inspired. we need to empower and enable these teams to do this to truly realize the power of agile or in fact any team development.