Introducing Scrum at a company where everyone hates Scrum
Introducing Scrum at a company where everyone hates Scrum
"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." - George Bernard Shaw
I worked at a company where everyone hated Scrum. When I say everyone hated Scrum, I really mean everyone.
From the top of the leadership down to the managers of teams and the developers writing code. ‘Hate’ seems like a strong word to use, but it was definitely appropriate. I never figured out where the hate came from, as almost nobody had used Scrum before.
The dislike for Scrum was so bad that I was treated like the village idiot when I started talking about adopting Scrum: “Oh no, not this guy again”.
By now you might be thinking: why on earth would somebody want to introduce Scrum in such a hostile environment? Hold on to that thought, I promise to get back to you.
When you read articles about introducing Scrum, they often describe how important it is to start at the top. The articles often also stress how important it is to have experienced Scrum Masters when you start doing Scrum.
This definitely isn’t one of these beautiful, orchestrated stories that starts at the top. This is the ugly and messy story of how you can introduce Scrum from the trenches without any Scrum Masters.
Joining a hot start-up growing at lightning speed
I joined one of the hottest start-ups in the Netherlands. We were growing fast and featured in the news almost every month. If we advertised a job, we would have 500 applicants within days. Everyone wanted to work for us.
Working there felt cool and exciting, like being aboard a rocket: to infinity and beyond. Our future looked shiny and bright.
Below the surface, we started to experience growing pains. Growing pains are normal once you start scaling up.
All the duct-tape solutions that seem fine before, suddenly stopped working and needed to be fixed urgently. Most of the time was spent putting out fires, distracting you from doing meaningful work.
We had a lot of problems in our development process. If you worked at a start-up before, some of them may be familiar:
We were using a watered down version of Kanban without WIP limits. Imagine a Kanban board with a giant traffic jam every single moment of the day.
Backlog Items would be issued to developers in isolation. Developers would work on Backlog Items without discussing them with other people or any form of refinement.
A JIRA workflow of more than 20 steps, where only specific people could transition tickets between statuses.
We copy-pasted the Spotify model, without knowing what problem we wanted to solve. But it looked really cool in our job ads!
No CI/CD in place. Releasing required a huge amount of manual and coordinated (testing) effort between different teams.
Development teams weren’t cross-functional and depended on people outside of the team like designers, QA and DevOps.
To make matters even worse, our priorities changed daily. Not that changing priorities made a difference to what happened. Our development process felt like moving through quick-sand. Changing priorities upstream did not affect the flow of work downstream.
The main symptom of these problems was the inability to meet any timelines. Being a bootstrapped Software-as-a-Service start-up, a lot of promises with timelines were made to help close deals. But we were not in any position to deliver on any timelines.
As a Product Owner, I constantly had to hop on calls to explain why features were delayed to customers. I then had to rub my crystal ball and tell them when I would expect features to be released. Then rub it again, because I often was wrong. All these calls were a draining and exhausting ordeal, leaving everyone dissatisfied.
We were unable to predict what would be finished the next two weeks, so how could we make any promises at all?
So to get back to the initial question: why would anyone want to introduce Scrum at a company where everyone hates Scrum?
I believed Scrum would help solve all these problems and put me in a position to be a better Product Owner. To be more specific: Scrum wouldn’t solve any of these problems. Scrum would put the Development Teams in a position to solve these problems on their own.
I decided to take a shot at convincing management of adopting Scrum.
Convincing management to adopt Scrum
I tried to persuade management to allow one of my teams to work with Scrum. These were the main arguments I used:
We had a lot of young and inexperienced people in our development teams. Our Kanban-like process was too light-weight and did not provide sufficient foundation to build upon. There was no planning, refinement, reflecting on the process or reflecting on the result of the process. By starting with Scrum, we would be able to introduce a solid foundation that would fill that void by introducing the Scrum events.
By introducing a more prescriptive process with a solid foundation, we would be able to reach a place were we can forecast what we could finish in two weeks. This would then set us up for success to forecast timelines even further in the future.
Management was not yet convinced, which was understandable. They liked being able to change direction every day. I probably sounded too much like a zealot and did not tailor my message well enough to explain how it would solve the problems they cared about.
Someone from management actually gave me the following advice: “Stop talking about Scrum. Everybody here hates Scrum. Come up with your own, new terminology so they won’t know it’s Scrum. This will help remove a lot of resistance that exists.”
She was right, but I believed this solution would even introduce more problems in the long-term. So I decided this wasn’t the way to go.
Then something happened that would give me the leverage to introduce Scrum.
Moving to Barcelona for half a year
We opened a new office in Barcelona in a great location with superstar hires. We were not able to find a good Product Owner and we were in dire need of one. I was asked to move there for 6 months and act as their Product Owner. If things went well, I could decide to stay or hire a replacement.
I accepted under a single condition: the Barcelona office would have the freedom to decide how they would want to work. I even explicitly said: if they would want to work with Scrum, then so be it.
The condition was accepted. The door was now open to introduce Scrum as a Trojan Horse in the company.
Scrum is a Trojan Horse, because in the end it’s a process framework that helps discover the real working process. So by introducing Scrum, you’re introducing a lightweight vehicle to implement even more changes in the organisation.
Introducing Scrum from the trenches
When I arrived in Barcelona, I asked the teams how they would like to work and we discussed using Scrum. The developers had positive experiences with Scrum. So they immediately agreed to try it out. I also reassured them by saying that if they didn’t like it we could always revert to the old situation or change it however we wanted.
The Scrum Trojan Horse was planted and ready for action.
We were not allowed to hire a Scrum Master, as it was deemed to be a waste of money. I was not allowed to appoint anyone the role of Scrum Master, as leadership thought it would distract our developers from coding. Damn, I was hoping this would be easier!
Because of this, I initially had to wear two hats: Product Owner and Scrum Master. I was fine with doing this, because as a Product Owner I can’t deliver value if we suck at delivering. Especially with all the timelines that already had been promised to customers without being involved.
With our freshly minted Scrum Team we had our first challenge ahead of us. An extremely complicated new module was promised to a customer with a fixed timeline, without any developers who would build it being involved in forecasting the timeline. It would also require collaboration with all teams in the company to succeed.
The team in Barcelona had to deliver the new module and we decided to give our best to make it happen. The module was super-complicated and would require coordination across all teams in the company. The timeline was very aggressive and we were doomed to fail.
We went into refinement with our new Scrum Team and broke down the module in small chunks of work together. We kept the scope as simple and small as possible, without putting the problem it was supposed to solve at risk. After finishing our first Sprint, we were reasonably confident to be able to deliver a first version in two more Sprints.
After three Sprints in total, we delivered the feature as promised. The customer loved the feature when we showed it. Management was surprised that were able to deliver on time. I also was able to forecast when the remaining features were expected to be completed. We also met each of these feature milestones on time. People higher-up were amazed and happy with the results!
Releasing the Trojan Horse with support from leadership
After seeing Scrum in action, management became convinced that Scrum was the way to go. They decided to open the Trojan Horse: all Development Teams should start using Scrum. For me it was a big surprise, as I did not expect to convince them so easily by just delivering a big feature on time.
From one day to the next, our management told all Product Owners that they had to start using Scrum with their Development Teams. Still with the same limitations: no hiring of Scrum Masters or appointing people to be a Scrum Master. But it was a start!
I received a lot of messages on Slack from people that were unhappy. I heard many different arguments against Scrum. Scrum was never going to work for our organisation. It would just slow us down and introduce more bureaucratic overhead. Estimation is impossible, so there is no world where Sprints makes sense.
All the people who never liked Scrum in the first place had to start using it. They were grumpy, but they had no choice. We started with Scrum in an ugly place. Nobody wanted to do it and nobody had any knowledge about Scrum.
Just like in Barcelona, all Development Teams immediately started doing Scrum. No Scrum training. No sitting in a meeting room for a couple of days to teach everyone Scrum. Just do it and let’s get started! Of course I tried to support them to the best of my ability, but I had to do this on top of my Product Owner job for multiple teams.
My strategy was to focus on teams who had Product Owners that were excited about using Scrum and support them to the best of my ability. I was working from Barcelona, so it meant hopping on a lot of video calls. Over time the enthusiastic Product Owners started to help out the other Product Owners with using Scrum.
Nobody understood yet (myself included) why Scrum is the way it is. We ended up with Zombie Scrum, performing all the events without really understanding why.
A concrete example of Zombie Scrum in action was our Sprint Review. Our Sprint Review was just a demo day where everybody showed off features that weren’t finished. It was more of a contest to show-off how great your team was (and cover your ass in case you weren’t delivering). It should have been focused on showing what you actually completed and getting feedback on it from various stakeholders. And then afterwards discussing together what are the next things we should be working on.
Still, our head- and heartless version of Scrum was outperforming anything we did before. No more changing priorities each day, which created focus. Each Sprint we discovered better ways of working through the solid foundation of Scrum. We may not have understood the essence of Scrum, but were still reaping many of its benefits.
Scrum empowered teams to solve their own problems
I achieved the questionable honor of introducing Scrum in the unlikeliest of places. Most of it by virtue of being a stubborn and just not being able to let go. And by being lucky that I ended up in a situation where I had some leverage.
After Scrum was introduced, even the biggest skeptics reached out to me to say how much happier they were. Scrum helped surface many of the issues I mentioned and empowered the teams to solve them or get support from others to solve them. All Scrum Teams actively pushed for changes to help resolve their problems to deliver features.
Were they always able get their proposals implemented? No. More often than not they would still bump into a wall. But over time all the successes began to add up and improve our way of working.
Some examples of the many successes that were achieved after introducing Scrum:
Priorities no longer changed daily, allowing the teams to focus and finish what they started.
Jira workflow was reduced from more than 20 steps to 7 steps.
Teams started to deliver far more predictably. Unforeseen complexity still would sometimes rear it’s ugly head and cause delays. But this is impossible to prevent.
Teams gradually became cross-functional, with having all the necessary knowledge of QA, DevOps and design part of the team.
A more stringent Definition of Done resulted in CI/CD being put in place.
Developers were happier than ever before, because they started to be involved in forecasting timelines and could focus on delivering quality.
We moved from component teams to feature teams.
Later on, with the help of our Learning and Development department we arranged a great Scrum Trainer (Hans van der Burgh), who helped to plant the first seeds to fix our Zombie Scrum implementation, by explaining why Scrum is the way it is.
The training paved the way to hiring Scrum Masters and Agile Coaches, as people understood their job better now. It helped to make Scrum a first class citizen of our development department. I even began giving Scrum training in our company to new hires and in our summer school.
We performed a heart and mind transplantation on our zombie. In the end, our Zombie Scrum was no more. Almost all Scrum skeptics had magically disappeared as well.
It would have been far easier if we had given our Scrum a heart and mind to begin with, instead of creating a hideous monster where it needed to be added afterwards.
Sometimes you have to accept you can only start moving from a dark place into the light, unless you are willing to accept not moving at all.