So I’ve decided to kick off this blog a series about how Scrum can go awry, because sadly I’ve seen it far too many times, and I’d love to save someone the agony of ‘WHY ISN’T THIS WORKING!?!’
I’ve attempted to put scrum into practice many times over the course of the last 4 years, and I have found 1 way that has given me great success: Sticking as close to strict Scrum as possible.
I don’t say that to say you can’t throw your own spin on Scrum with your team, but if there is one thing that I’ve seen happen over and over, its seeing the idea that each team’s process should be different as an excuse to stray for the formula often far too early.
A classic example: Making Scrum master and Product Owner the same person. Often times organizations still want a single person doing all the ‘managerial’ organization for the team. Before I go off on a tangent of every very good reason you shouldn’t (lets be honest, enough has been written on the subject), I’ll tell you that I’ve done it successfully.
How? I was forced into that situation for 2 years, and finally I got the balance right. Obviously though 2 years to figure out a way to do that process productively is way too long, and really it highlights the fact that its not recommended.
I had to learn how to manage a backlog, acceptance criteria, and story point/velocity tracking along side fostering productive discussions, ensuring roadblocks were being addressed, and keeping from being so involved that the team didn’t learn to fix its problems itself. It was a HUGE skill set to learn, particularly with respect to keeping myself from being a traditional manager. And let me tell you, I’m glad to just be a Product Owner at this time.
That role separation is one of many things that is critical to Scrum. 2 years was entirely too long to learn how to subvert something that Scrum is built around. What’s more is that this is just one of many ways teams and organizations try to tweak it to their advantage, only to set themselves up for failure.
It leads to an interesting question: Why is it so hard to successfully tweak scrum? Is there some Scrum gods that bestows the miraculous gift of Scrum productivity only to those teams that practice it strictly?!
My conclusion, based on my experience, is that Scrum is not some miracle per say, its a winning formula. Just like any formula, if you remove one part of it, you need to replace it with something that is able to make up for each value it represents, which puts you in less treaded ground.
There are no guides to how to be a Scrum Master/Product owner for instance, and I can say that if I were to train someone all the things that I learned, it would take several months and sprints to impart that knowledge successfully because its a balancing act that requires a solid grasp of each situation that comes into play.
So why do we see this keep happening? Why do we see Scrum teams doing Not-Scrum things?
There have been two cases I’ve seen:
- The organization is unwilling to adapt to Scrum and trys to blend existing processes in with Scrum to get a (mutant) hybrid approach instead of examining each of its existing processes and figuring out if it enables a Scrum team.
- The team itself believes that since the team owns its process that it can change some of the Scrum tenants to be ones that they are more comfortable with.
The first situation is one that makes my skin crawl out of having experienced it, and I wish those same organizations would move to something like Feature Driven Development, or at least Kan Ban because setting the expectation of ‘this is Scrum’ when you won’t do the full process sets a bad example of what Scrum can really do.
Teams, however, making the changes themselves is dangerous and ultimately falls on the Scrum Master to keep inline. This is tricky because you want the team to be empowered, but Scrum process isn’t something that should be thrown to the wayside without VERY careful consideration, and more important still EXPERIENCE!
In Scrum: The Art of Doing Twice the Work in Half the Time, Jeff Sutherland uses the martial art concept ‘Shuhari’ to really help explain when a Scrum practitioner should start to tweak the process to suit their situation.
The idea is that ‘Shu’ is the stage at which one does the process as close to its original intention as possible. A beginning Scrum Team should be allowed and expected to practice true Scrum and little else but. Once the team has done so for a while, and has an understanding for what the process does and some of its value, the team progresses to ‘ha’ where they can detach from some of the norms and some times improve the process for their team. Eventually, the team can get to ‘ri’ where they fully understand each part of the process and the values it presents and without following the processes per se can gain those values. These team’s are Scrum even without its structure.
They are also rare.
Most teams that I worked on never were able to properly get into the Shu stage, and I have seen some that believe, well before they’ve finished storming as a team, that they are at the ‘ha’ stage. I fear that is a dangerous road, as leaving the process too soon means having to learn a new process without appreciating what its replacing. Such a situation cripples Scrum teams progression, and needs to be avoided at all costs.
While that belongs majorly on the Scrum Master to enforce, I believe that its something that organizations that have chosen Scrum need to echo as a company value that, that Scrum teams start with Scrum and nothing but, and only after mastering and understanding it, start to throw their own spin on the process. To do anything else is to accept Scrum will go awry, and the boons that come from it will fail to materialize.