Don't worship at the Altar of Scrum

I am a Scrum Trainer with Scrum.org.  I work with lots of organizations to help them become more agile.  I see a lot of bad Scrum.  More than my fair share.  Sometimes I see so much bad Scrum that it makes me question why I do this.  This post is my attempt to remind myself why.

What is bad Scrum?  Lets start with what it is not.  Scrum is not about following rules.  There is an industry full of people that have turned Scrum into a religion.  I kid you not.  They even have names for themselves.  They call themselves 'white robes'.  They obsess over every change to the Scrum guide and translate the 'founders' intent for you.  They will speak of your dysfunctions (sins), they will point out your deviations from the one true path and they will shame you.  Scrum is not my religion.  Don't make it yours.  Be skeptical.  There are no higher beings when it comes to Scrum.  I am not a high priest and I don't need a high priest.

Scrum is not about mechanics.  They are merely there to serve a purpose.  The mechanics are a means not an end.  The mechanics do not define the result.  Can I follow all the rules and mechanics and have bad Scrum - you bet.

Scrum is freedom.  Freedom from the tyranny of trying to meet someone else's commitments (made for you.). It is freedom from being told to be 'accountable', meet your 'commitments' and other 'motivational' words.  It is freedom from being measured against someone else promises.  It is freedom from feeling like a cog in an endless machine.  It is freedom to question, to discover, to disagree, to decide how to work, how to improve and how to make your own promises.

What is bad Scrum?  If you are not feeling any of these freedoms and you are 'doing' Scrum then you already know the answer.  Bad Scrum is mechanical.  It's a belief in magic.  If we stand up for 15mins every day, attend lots of meetings, call someone a Scrum Master then things should be better right?  A Scrum Master just books the meetings and makes sure everyone turns up right?  Right?

If we decide the features that should be in a release and we decide what date that release will ship we can just tell our self-organizing team and they should be able to deliver it, right?  Welcome to bad Scrum.  If we decide that the Project Managers should be Scrum Masters but our new teams are self-organizing and therefore accountable for the outcomes, welcome to bad Scrum.  If you are being asked to 'drive success' for the team then you are not part of the solution.

Lots of companies decide that Scrum has too many holes.  It doesn't dictate documentation, dependencies, scaling etc.  We need to define that.  So they reach out to a prescriptive model (SAFe - I am looking at you) or 'customize' it to add what is missing.  Welcome to bad Scrum.

The gaps ARE the power.  The gaps are where we can decide what works best for us.  The gaps are the opportunities.  Revel in the gaps.  Glory in the gaps.  The gaps are what makes this what it is.  The gaps are where teams can actually define their own future.  The gaps leave room for a self-organizing team to exist.  Scrum doesn't need to be customized - just fill in the gaps with what makes your team special.

There is genius in empiricism.  Predicting the future is hard.  Adjusting to evidence is easy if we are given the chance, and people are willing to hear the truth.  A team that is allowed to self-organize don't need anyone to 'drive' them.

Good Scrum is not about measuring adherence to practices or mechanics.  Be skeptical.  If your consultant arrives and defines success by measuring practices, think about what you are advocating.  You have created a proxy for success.  That proxy involves post-it notes and standing up.  Really?

Good Scrum is exciting.  Good Scrum teams have purpose.  They have fun.  They are not defined by the length of their planning meeting.  Good Scrum teams do not need someone to 'empower' them.  I have my own power thanks and I don't need yours.

Good Scrum teams crave feedback.  They crave it from their process, their products, their stakeholders, and each other.  Feedback is power.  Feedback drives improvement.  The Scrum framework gives us a way to gather feedback.  Our response to this feedback defines us.

These teams need someone to care.  Someone to care about more than just the next feature, or project deadline.  Scrum Master this is you.  You are there to create the environment for this type of team to exist and thrive.  You are there to gather this feedback, and help your organization act on it.  Do nothing and expect no improvement.  Scrum is merely the vehicle that will surface these opportunities for greatness.  They will be challenging, they will appear unsolvable.  They are not.  Look at each day and ask yourself - 'are we better than yesterday?'

Your job has nothing to do with booking meetings.

If you care - I hope we meet.

What type of Scrum do you have?

 

 

 

Image courtesy of https://www.flickr.com/photos/matthewalmonroth/14486687503 - licensed via Creative Commons