Being a Scrum Master can be tough. You are accountable for helping organisations change the way they approach complex work. You are there to help them adopt an empirical approach to dealing with change and uncertainty.
While most people will recognise the need for change, for the most part, people do not want to change or be changed. Most large and successful organisations are built to resist and prevent change. To maintain the system that has got them where they are now (big & successful). Sometimes when you try to change how things are done, you will make enemies who prefer the status quo. If you upset enough of the wrong people you may end up “changing” yourself out of a job.
This is something we always have to be conscious of as a Scrum Master. If things are easy it may be a sign you have retreated from the challenge of being a change agent. If you do too much and push too hard you might upset the wrong people and get yourself fired. All of us who become Scrum Masters have to be aware of the tight rope that we walk and decide how much risk we are willing to take.
As I gained more experience as a Scrum Master, I became more confident of taking risks that may lead to my removal. At this time I was on my journey to become a Scrum.org Professional Scrum Trainer so I saw this as part of my learning journey. How could I teach people where the limits may be if I hadn’t tested them myself. As a result, I got myself fired on multiple occasions. So for your education and entertainment, here is the story of one of those times.
The first time I was fired as a Scrum Master I was working for a large company whose market share had been in steady decline for many years. Innovation was low and they needed new ideas to survive. I had recently been brought in to help them achieve 2 important objectives. The first objective was to help them to learn about and start to use Scrum. The second objective was to help them develop a new innovative product. Although the development of this product was high risk, it offered a potentially massive cost reduction opportunity and could have revolutionised their industry. It could also spark some much-needed innovation in the organisation which had been lacking for too long.
Soon after being hired, I helped the organisations first Scrum Team. We worked in 1-week Sprints and built Done Increments that really were “Done” and actually worked. We inspected the product each week in the open-plan office, where a wide and varied group of stakeholders and senior managers were able to attend and see what we were doing.
And they were impressed, seriously impressed! We were producing more in a week than most of their teams produced in 3 months. People got excited about the potential of Scrum which sparked lots of other teams into learning more about it and starting to experiment with it. My first objective was achieved.
However, Scrum is about transparency and what that transparency reveals is not always welcomed. The organisation worked in a traditional way and when I arrived a Project Manager had already “sized” the project I was to work on and decided it would take 6 months. This was fixed in a plan and change was frowned upon.
Once we had completed a few Sprints, measured our delivery capability and compared it to the volume of “committed” work in the Product Backlog, it was clear there were at least 12 months of work. This was assuming no new scope was added, no changes were requested and no estimates turned out to be wrong, all of which was very, very unlikely.
I discussed this with the Project Manager and this information was not welcomed. I suggested some possible changes to help. Reduce scope, add more people or allow more time among other simple things. These suggestions were all rejected. I was told that we just needed to “get it done” on time with the resources we had now, no matter what. The evidence clearly showed this was impossible, but no one was listening.
A short time later, the Project Manager informed me that he had a solution to the problem. He would end my contract and use the money saved to fund a new Developer in order to get the work done to the original timeline. I was a little shocked but recognised that this was potentially a good idea, except for 2 significant problems.
The first problem was that 1 additional Developer would not make enough difference to reduce the timeline of the project from 12 months to 6 months. It would likely make 1-2 months difference at best. They would still fail to deliver as planned.
The second problem was that they would lose the services I was providing as Scrum Master. I was confident my impact was critical and the team would slow down substantially if I was no longer there.
One impediment I had helped remove was the massive burden of meetings placed upon the Developers. I had been able to reduce the meetings they were required to attend (that were unrelated to our current product) from 4 hours a day to less than 1 hour a day. I knew this would immediately revert if I wasn’t there and the project would suffer massively as a result, making even the original 12-month timeline impossible.
Ultimately, my objections were noted, ignored and my contract terminated. At this point, I should have been sad, but I was relieved. I didn’t want to be on another death march project and had long before this decided I would no longer be part of a system that inflicted it on others.
Some years later I bumped into some colleagues from this organisation and they told me what happened after I had left:
- The Project Manager took charge, abandoned Scrum and hired the new Developer. The Developer turned out to have the wrong skills and did not fit into the team. The delivery rate of the team decreased.
- The 4 hours of meetings each day returned. Each Developer now had 3 hours a day less to get their work done. The delivery rate of the team decreased more.
- The Project Manager upset some Developers by not addressing any of the impediments that were slowing them down. Motivation declined and the delivery rate slowed to a crawl.
In the end, the project was completed after 18 months. 12 months longer than originally planned. The product was of poor quality as so much technical debt had been accumulated to meet even this date. Most of the interesting features that could have made this an industry-changing product has been descoped so the product had low current value.
Unsurprisingly, the product failed in the market place and most of the effort that had gone into it was wasted. But there was one interesting side effect of this failure from such a promising start.
A few important people remembered my predictions and advice at the start of the project. Evidence had shown that 6 months was impossible, but no one listened. At this early stage, they had choices. Difficult choices, but choices nonetheless. The choice they made was to remove Scrum (and me!), despite the strong early progress.
Some managers saw the wasted opportunity and decided to reintroduce Scrum. More investment was made in training and support. Now many years later they have hundreds of people using Scrum every day to build and support their products. It took some time, but they got there in the end!
Change is hard. In more traditional organisations it can take many failed attempts before people start to “get it” and real change happens. Along the way, you may have to decide whether to sacrifice yourself or be sacrificed to enable this real change. Being a Scrum Master is hard!
In my next post, I will tell you about an organisation that I decided to walk from (probably shortly before I would have been fired anyway).
---
Hi, my name is Simon Kneafsey and I am a Professional Scrum Trainer with Scrum.org & TheScrumMaster.co.uk. I am on a mission to simplify Scrum for a million people. I have helped over 10,000 people so far and I can help you too.
Learn more at TheScrumMaster.co.uk and signup for our newsletter with 80,000+ other Scrum practitioners.