Scrum: Why It Doesn’t Work

Perspectives From a Certified Scrum Master

By, YuChao Sng

About Me

I am a certified scrum master and I’ve been running a scrum team for the past 1 year. In addition, I also have 10 years of experience working on technical development in different setups. In one big organization, I used the traditional SDLC (or what agile advocates like to call “Waterfall”), in a small family-like setup, verbal requirements writtened down in notepads, and in my most recent organization, Scrum.

By now, most scrum practitioners should realise that Scrum works only in theory or have difficulties working even in a very very small set up.

Before writing this article, my PO asked me: “ Why write such an article that will potentially ruin your own career?”

Well, the truth is, the impact is not really so great on a personal front. I am not only a Scrum Master, this is just my current role in my current project. I have experience as a programmer, a database developer, a system analyst, a business analyst, a trader and a writer and I can transit into any anytime.

The reason why I had waited this long is so as to garner enough experience of running my scrum team, having spoken to enough agile coaches (3 to be exact) and having listened to stories shared with other scrum teams so that I can give an honest assessment of the framework (or some would say, mindset). It also means that I am padding others' experience onto my own. Now, one year into this role, coupled with another 9 as a techie (13 if you add 4 years for my undergrad in computer engineering), I believe I’ve seen enough.

And had enough of this nonsense.

My Motivation For Writing This

Firstly, let me make it clear my motivations for writing this: For the greater good: to discourage companies from trying to onboard this framework because it will be super costly in terms of:

1. Time to get to finished product.
2. Multiple reworks.
3. Demoralized staff.
4. An unhealthy relationship across the organization structure.

To Begin with: It’s not all bad

Well, I’ll certainly start out by writing about the good stuff first, because no matter how bad it is, there must be something positive, either as causes or effects.

Time-boxing in Daily Life

Definitely one of the best thing about scrum is fixed time-boxing. The idea is simple but can be applied to your everyday life: given a list of things (i.e. your backlog) you have to do, give each item an effort estimate, prioritize them by urgency, business value and dependencies (generally, you can use the word “importance”). Then you put them into a time-box called a “sprint”. This sprint is usually 2 weeks. By the end of the sprint, showcase what you have done (i.e. your deliverables) to the sponsors and PO in a session called a “sprint review”.

I love the idea of time-boxing. Not so much in software development but more of its application in our daily lives.

Whatever you do, give yourself a set time to do it and try to finish it. If you are unable to complete everything, put it back into the backlog, revise the effort, think about what went wrong (sprint “retrospective”) and plan for your next sprint, this time with a lower total effort.

Time-boxing allows you to understand yourself better, be more accountable in picking up tasks and seeing them to completion.

However, let me clarify this: time-boxing is NOT unique to SCRUM. In traditional project management, there is the project schedule with the proper timeline and everyone is supposed to adhere to it. The difference lies in the fact that in SCRUM, you are supposed to have deliverables by the end of the sprint and the sprint period is fixed.

The Scrum Team

One good concept of Scrum is frequent communication. The idea of Scrum itself involves a lot of time communicating within the scrum team. In fact, there are ceremonies to ensure that you talk. The most frequent being the “daily standup” where you update the team on 3 things: what you have done, what you are going to do, and what impediments are you facing.

Assuming that communication builds cohesiveness in teams, frequent communication thus means that by the end of a few sprints, one of the positive effects is that you will get a close-knitted team*.

*unfortunately, this assumption cannot be true if there are constant communication breakdowns and misalignment of interests.

The Theory and Job Creation

I cannot go on to the failures of Scrum without first saying that it is in fact, a good idea in theory. If you look at it component wise and even thinking about the flows (the connections between each component), the theory of the scrum framework sounds good. In fact, the 17-page document is so good that it spawns a whole new industry just selling the Scrum methodology. Yes, I’m talking about job creation for 2 main roles: Scrum Masters and Agile Coaches. But in reality, they are a huge cost to most organizations. And I’m gonna tell you why.

Why Scrum Fails

The Ever-Changing Requirements

Reworks

Many people see benefits of a Scrum development framework as frequent deliverables and allowing for changes along the way. That is, giving sponsors and PO the flexibility to change their requirements along the way until the final product is delivered. I don’t see this as a benefit. In fact, I see this as one of the most detrimental thing ever.

Perhaps the creators of Scrum did not really thought it through, or they did not state their assumptions clearly enough. But this changing of requirements is really a misnomer, or can even be termed as “mis-selling”.

Most businesses who were sold this assumes that you just need to tell the development team roughly what you need and then when the items are delivered, you will have a clearer understanding and visualization on how it looks like and how it functions and you made changes and better decisions along the way.

But this is really a huge problem. This idea gave the PO too much leeway and causes lapses in responsibilities and promotes laziness of the mind.

What is happening in the real world is this: PO gave development team a rough idea of what is required, don’t write proper requirements and expected results, and rush to start work before the developers where given enough information on the big picture. Sometimes, the joke is on the PO: he/she doesn’t have a clear idea or what he/she wants (but supposedly that doesn’t matter since “changes are part of Scrum").

Unfortunately, this is wrong. Because, in order to work on an application, there is the architecture and program design to think of. Where should certain computations take place? How and where should data be transformed? Which programming language to use? Which framework to adopt? If you are in this field, you will know what I am talking about.

And you know what is coming next when requirements change: Reworks.

Mona Lisa

Of course, this is a known problem in Scrum and the church of Scrum tried to explain using the Mona Lisa picture and how a picture (the end product) will look like in the end: having a skeleton, then a rough idea of where to colour what colour, then proceed to paint the final product. This is the so-called “iterative approach”. Unfortunately, “add-on pack” doesn’t gel with the idea of Scrum itself.

The iterative approach is actually opposite from what scrum is selling to sell: frequent deliverables.

The reason being that the term deliverable means that you have to show your stakeholders something. The iterative approach will be akin to:

Sprint 1: we got the design framework out.

Sprint 2: we are starting to build the framework for the different classes that will interact with each other. Just the function names, no codes yet.

Sprint 3: starting to do some coding within some functions. We prioritized and focused on those parts that will interact with other classes.

Sprint 4: Finally, we can show that this feature and that feature can interact with each other. Just a basic functionality. Nothing of the features requested yet.

Sprint 5: Ok. We can getting this feature and that feature out for this sprint.

Sprint 6 to Sprint N: continuous delivery of features and refinement of features.

Sounds good? Did I mention that the backlog is owned by the PO and prioritization is done by the PO? Okok… some scrumies will start to argue that with the Dev team inputs, scrum will work as ideal.

One question here: How many sprints do you think the PO is willing to keep facing the firing squad (god bless if it’s really just a few sprints!) where only technical stuff are completed without any visible features to show to the non-technical stakeholders? I mean, not everyone is working in the tech firm where you can showcase your design architecture as a feature!

The truth is, in the non-tech companies, the backlog WILL BE incremental. And that is when you will be seeing delivery of the left side of Mona Lisa face and then the right hand because we may be lacking enough paint colours to complete the right side of the face for this sprint (pending another team) or because the developer whose expertise in face is now being assigned to paint Marilyn Monroe’s lips for another project.

And that brings us to the next pragmatic issue…

Dedicated Resource in a Scrum Team

Raise up your hands for those people out there working in scrum teams. How many of you are working on multiple projects right now?

Sorry, I lost count. Maybe just… how many are just working on just 1 project?

Good for you! Now… how many POs are handling just 1 project?

How many Scrum Masters are just doing running 1 scrum team and has nothing else to do?

For all those people who raised their hands to the above, how many of you are in non-tech companies?

The truth is, ideals are ideals. Unless you are in a super generous and rich company, you probably have a lot of items at hand that belongs to multiple projects.

With productivity a huge focus now, businesses want to ensure that they utilize the hours they pay for their developers. That means everyone will have to be doing something, anything, even when infra is not setup yet or requirements are still on a blank page.

Sprint: Time-boxing in Software Development

I mentioned previously that I love the idea of time-boxing. In fact, you can apply time-boxing to many different tasks in life. You can time-box your trades if you are a trader, you can time-box your exercises and training if you are a sportsman, you can time-box your sleep, your lunch time, etc. As long as your activities are routine, got to be routine, you can time-box them. In fact, you can even time-box your writing as a writer because it enforces discipline.

However, the issue with Sprint is this: the backlog is owned by the product owner. The product owner is usually someone who is non-technical and focuses on visible deliverables.

This means that a development team will have very little freedom to select the sequence of the work. There will be arguments (or discussions) every 2 weeks with the PO on what should be done first. Over time, this put a strain on not only the relationships, but the fatigue of such constant disagreements also causes mistakes and overlooking of major system design issues.

When your developers reached a stage where they are no longer willing to do their development on the context of the major application design, that’s when you will start facing long-term issues and the built-up of technical debts. They started coding what the PO wants, one feature by one feature. Sometimes even hard-coding the module “because the reusable component is only 3 sprints later”.

Know that you are probably too deep into this shit if you started hearing things like: “That’s not in this sprint.” “That’s the feature you asked for.” “We will need to rework the previous feature to accommodate this.” “But you said last time that you don’t need this, now if you want it, we will have to do major reworks.”

Not Realistic

Perhaps all the reasons why scrum doesn’t work can be summarized as “Not Realistic”. Put it simply: it only works in a very controlled and protected environment, kinda like experiments in a lab. The real world, unfortunately, is full of other elements that could impact the development and delivery of a software application. The above is just a short list of what I have energy to write down. You can google and find many articles already online that talked at length about why and how Scrum sucks.

2 Most Common Replies From Agile Coaches

I had wanted to end this article on the previous segment, but I think this article wouldn’t be complete without putting in 2 of the most common “reasons” from agile coaches that I’ve heard during consultations/Q&A about the practical difficulties in implementing Scrum:

1. I can still see “waterfall” in your process/sprint.
2. This is not a Scrum problem, this is a business problem.

The 2 statements above is basically saying this: “Scrum works. If it doesn't, the problem is not with the framework, it’s other problems or you are not implementing it correctly.”

Think about this:

If Scrum is so good, why is it so hard to get it working in real-life?