‘Scrum is an awful project management methodology’

A tale with a twist

Here is another story I wrote years ago (November 2019), sadly still relevant. I hope you enjoy reading it.

A tale with a twist

We were a shadow of ourselves, drained. It’d been a month since we launched our latest payment product and it had only brought catastrophe. The product was super unstable and users hated it. And this didn’t surprise us either.

To make matters worse: we serviced the entire globe. The incidents would also flow in at nighttime, requiring immediate resolution. The lack of sleep and the stress were unsustainable. At one point — during the retro — Carl shouted: “We can’t work this way anymore! Who are we fooling?”

The decision

Carl was right. We needed to do something. So we decided to stop using Scrum as a project management methodology. It changed everything for us and I recommend all of you to do the same.

Scrum comes with a lot of promises, like “[…] twice the work in half the time” (Jeff Sutherland — one of the creators of Scrum). But our work did grind to a halt with Scrum. High time to dismantle this Scrum project management methodology!

A warning before you proceed: brace yourself. It’s getting really ugly.

Danger zone by 2allmankind

Sprint Planning

Let’s start with the Sprint Planning, taking the example of the 8th Sprint of our project. I could have picked any other Sprint development phase of the project — the planning was all the same anyway. Our Scrum Master presented the work that was laid out for us, directly copied from the Gantt chart created by the Project Manager.

Sure, originally it was us who came up with all the work that was required to complete this project, but that was months ago. Since then it had become clear that we didn’t have a clue about the complexity of the work when we did that planning. It was all far more difficult than expected. So at the 8th Sprint, we were way behind schedule and had to step up to “win back time”.

On top of that, our initial assessment of what needed to be done felt outdated at this point. When time progressed we came to understand there were other needs from the users, based on input from Sales. But these had to wait for phase 2 of the project. If this would ever come. Meanwhile, we were still stuck in phase 1 with the realisation we probably would not deliver the value we wanted to achieve. Which wasn’t very motivating.

There wasn’t much we could do though. We had committed to a plan. And we had to follow that plan because changing it was too hard to do. The steering committee would never accept it.

To tell you the truth: we were lucky as we had only one project. The reporting team had to deal with four projects at the same time. The priorities there were determined by escalations and influencing powers of the (project) managers. This could also happen mid-sprint. That team really had it bad.

The good thing about the planning sessions was that they were very short. How long does it take to receive instructions for the coming two weeks?

Stand-up

This was the shortest meeting, but the most draining one. Even if they were finished within 5 minutes. We were ripped out of our coding routine and had to say what we did the day before and what we would do on that day.

And then we had to bring forward our impediments. As if they would ever be resolved. Let’s take an example of something that I constantly had to deal with.

I worked on code as I was told during the planning, but constantly got disturbed by Jane from the QA Scrum Team. Saying that she found bugs that I needed to resolve. I couldn’t, as I had to work on the new code. Still, it bothered me that my coding from the previous Sprint had errors.

What to do except for raising the impediment? Which was then put on the impediment lane, with no-one ever looking at it anymore until I would raise it again. At a certain point, I would not raise impediments anymore.

Every one of us basically had the same line during the stand-up and after 5 minutes we could return to coding. Except that we had to get back into the zone, losing an additional 30 minutes of productivity.

The reporting team though had stand-ups that lasted for an hour. Every day. This was because they had to deal with all these changes during the Sprint and constantly had to juggle how to avoid further escalations. Which was basically a mission impossible.

The demo

Demos. Another futile exercise. Typically we had nothing to show, so we would cancel the demo. Sometimes we had interesting working codes and on these occasions, we showed them to the project manager. You could wonder why though. He was merely interested in the percentage of completion of the project and was often put off by how little we achieved in two weeks. As stated already: the demos were totally worthless.

The Retro

The retro was the funniest event as it allowed us to blow off steam. We could get things off our chest unless the project manager was attending the session. But that rarely happened. Only when he had to blow off steam too, at our expense. The bad thing was that the retros became repetitive. We discussed the same things over and over again and nothing changed.

Crunch time

Every project has a crunch time: the weeks or months when you have to deliver the project and deal with the backlash of unstable software and user complaints. These were the weeks where we more or less threw Scrum out of the window. We often skipped the rituals in those weeks where we easily worked 80+ hours. This is where we said that enough is enough.

We said: “Let’s stop with Scrum project management!”

As I said before the situation was unsustainable. We had to do something about it. We needed to implement radical changes. And stop using Scrum to manage our projects. This was the best decision ever. Here’s why.

We took the red pill Septimiu

Our new way of working

We knew that we had to change to survive. The company literally stopped growing. We were in trouble. We started with assessing the nature of our environment to determine what would be the best course of action.

Nature of our product environment

We came to understand that our product environment wasn’t predictable at all. We clearly were not able to create detailed plans months ahead, because constantly things changed along the way. For example: new insights into how to solve a certain topic, what we learn from software that already had been built, market developments… We acknowledged that our product environment was complex.

Small steps

Now that we understood that our product environment was complex, we decided that we only should take small steps, assess what we did and then determine what to do next. We chose an iterative approach. The iterations could be everything between a day and a month, depending on what was deemed best by a team.

From project to product

We let go of the idea of projects with a determined scope, budget and duration. Instead, we moved to embrace a product vision and embarked on an iterative journey to reach this vision. With that, certain roles and meetings became obsolete like the the project manager and the steering committee. Often we could find other roles for the people involved. But they had to adapt to the new way of working and the culture change.

All capabilities to build a working product in one team

We decided that we needed to have all the capabilities to build a working product in one team. We moved away from having specific Business Analysis teams, Coding teams and QA teams. These capabilities would all be in one team, depending on what was required to build the product iteration.

One person responsible for the priority of the stories in the backlog

Our team was lucky to have one project manager, but other teams weren’t. We decided to extend the idea of only one person being responsible for the product backlog, owning it. This would help to shield the teams from being totally disoriented and help them to regain focus.

Every iteration has a goal

We decided that every iteration should have a goal and that stories that would be added to the iteration plan would be selected to help reach the goal. By having a goal the team was empowered to focus on what to do, which would also help collaboration within the team. An example of a goal could be: “Let’s build our first full end-to-end piece of functionality to learn from it and show our stakeholders what it entails”.

Teams predict how much work they can pick up and determine how they work

We also stepped away from the situation where others told the team how much they should do. We came to the conclusion that the people in the team know very well how much work they can pick up. They could best predict what they could achieve as they were the experts. We also determined that teams could find their own way to reach the iteration goal. No one would tell them how anymore.

Daily discussion about the goal

We also changed our stand-ups. First of all: teams could determine themselves if they wished to stand or not. More importantly though: the stand-ups were about the progress towards the iteration goal and with that changed to a true team thing. With everyone committed to that goal all of a sudden the stories weren’t set in stone either. They couldn’t be! New insights could lead to changes to the backlog, removing obsolete stories and adding other ones that helped to reach the goal.

Demos: more than demoing the software

The demos changed too. They turned into interactive sessions in which we still showed what we built, but also discussed what goal we had for the iteration and what we did to meet this goal. We also did start to have discussions with the stakeholders on what to do next. Because that wasn’t predetermined anymore. The demo turned into a meeting where strategic discussions took place. All kinds of new insights could lead to a new order of the backlog, impacting the next iteration.

Retros resulted in improvements

Our retros changed too. We didn’t use them as complaining sessions anymore. Instead, we discussed how we could improve the way the team worked and all kinds of facets would be covered. From team interaction to company culture impacting the team, from coding standards on the team level to company rules and regulations. Anything that could help to improve the team would be discussed and the most pressing topics would be actioned.

Freedom by Fotorech

Major results

By abandoning our old way of working and embracing an iterative approach we moved away from the standstill. We were able to deliver more features than before and those proved to be far more valuable to our stakeholders than what we delivered before. We mastered the art of doing twice the work in half the time.

Our users are happier, our teams are happier and management is happier. We are back in the game!

My advice to all of you is to do the same as we did: assess your product environment and then determine if you need to change your product delivery approach. I guarantee that if you do this you will be amazed by what you will achieve!

End Note

I admit it. We called our previous way of working ‘Scrum’. We thought that we had a business process that was suited for it. But our business process didn’t fit at all. On top of that, we didn’t know what Scrum was about. We then moved to a different way of working which was adhering to the spirit of Scrum.

We went from a type of Zombie Scrum to true Scrum. And we are happier than ever.