SCRUM is not dead - it can still ruin your project

Our experience with SCRUM in a deterministic project

In this series of articles, I want to share exciting things about our way of working: challenges, organisational methods, work techniques, technical solutions, and much more. Enjoy!

Some people say Scrum has failed.

Ron Jeffries, one of the 17 original signatories of the Agile Manifesto, replies: “Democracy has failed when idiots and evil people get elected. Religion fails when people do bad things. Medicine has failed when people don’t take their meds.

And I say: 

What if the democratic majority has voted to take down your house, your religion demands your sacrifice, and the prescribed pills are making you worse? What would you do?

While I agree that some projects fail because of misuse, I also think that others fail because Scum is not the right solution.

Here is why.

The hype

There is a lot of hype around Scrum, and people react to it as they do with Bitcoin or Unicorns: they think it is good to invest in Scrum because so many people invest in it. While the success of Bitcoin and Venture Capital directly depends on how many people invest, it is not valid for a methodology.

Also, the articles that compare Scrum and Waterfall are biased in favor of Scrum by presenting wrong or incomplete information.

Our experience

We also fell into that trap and chose Scrum for our mobile app refactoring project. Though we used some parts of Scrum in the past, this was our first project when we tried to apply it by the book. We were enthusiastic about the promises of Flexibility and Efficiency and had the support of the entire organization.

During the project, we experienced the nice part of the meetings since they involved more team interaction with discussions on both technical and organizational aspects.

But we also faced challenges.

Story Points

The first challenge was dealing with Story Points - juggling points, time, and velocity. It took me time to understand that Story Points have no value on their own; the value is in the ability to estimate the effort, while the points are a tricky way of representing estimates. Developers invented the Points because they couldn’t explain how they evaluated the work to the stakeholders. Hence, developers decided to obfuscate time estimates into Points.

Some say that points are not related to time, but this can’t be true since you plan to deliver a certain amount of points during a Sprint. For example, you have two weeks with six developers = 60 MD.

These people manage to obfuscate estimates even from themselves ;o), probably to avoid the pain of admitting that they’re not able to manage estimates.

Some articles analyze even deeper why we shouldn’t use Story Points.

Working Increments

The next challenge was to deliver adequately tested working increments. The idea of increments is to have a functional version of the product after each sprint so it can be delivered to the customer to collect feedback.

To achieve that, we had to split more significant components or modules into intermediate working versions, which sometimes don’t bring valuable feedback. This splitting brings extra effort without a noticeable outcome.

Then there’s testing - while more testing is always good, it takes much more effort to test increments than running them on complete logical sets of features. Testing partial flows requires defining test scenarios that become deprecated when the whole flow is finished.

In our case, we should have defined our Definition of Done instead of following common opinions.

Project planning

We initially estimated six months for the project, but it took two years. Most important is that at any moment during the project, we couldn’t know when it would finish. The whole idea of Scrum is to manage uncertainty, so it doesn’t give ways to set clear deadlines. If we need a delivery date, we should rely on other methodologies.

Conclusion deducted from The Scrum Guide

Now, rereading The Scrum Guide, it is clear that we failed because we applied SCRUM to a project with a clear scope and well-defined requirements. Here is why:

Scrum has three pillars: Transparency, Inspection, and Adaptation.

According to The Guide, “Transparency enables inspection” while “Inspection enables adaptation”.

So, Adaptation is the result of the other two pillars, and I can see it as the main reason for Scrum's existence.

The definition of Adaptation states: “If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted.”

So we’re doing Increments to ensure that the product doesn’t become unacceptable. But in a project with a precise scope, we could address the risks of an “unacceptable product” by setting a few milestones to check the status. No need for more unless we have serious doubts regarding the quality of requirements or the team's ability to understand them - which is not our case.

In conclusion, in a deterministic project, we don’t need Adaptation (by Scrum definition), so we don’t need Scrum.

Flexibility & Transparency vs. Incompetence

I suspect that Scrum is so popular because some Product Owners promote Scrum by promising Flexibility while hiding their inability to produce quality requirements. Also, it would help them escape the responsibility - it is easier to justify delays when issues are shared regularly with the stakeholders. Though the transparency is excellent, this could pass the burden of decisions on issues to the stakeholders. In this case, it is not easy for a stakeholder to make a difference between an unexpected issue due to the innovative type of the project or poor analysis.

I’m only referring to projects with a clear scope when stakeholders have rightful expectations for a fixed budget and deadline.

Sometimes the stakeholders are the ones that choose Scrum without thoroughly understanding the implications. They often do so because they like the idea of tangible periodical statuses. In this case, it is the job of the Product Owner and designated Scrum Master to understand that the stakeholders need transparency. They should analyze if Scrum is the best option for the project or if it is better to use a different methodology and to assure good transparency with other means.

Are we going to use Scrum again?

While we kept using some Scrum Events like The Sprint, Sprint Planning, and Daily Scrum, we can’t say we’re using Scrum. According to The Guide, “While implementing only parts of Scrum is possible, the result is not Scrum.”

In the future, in a proper project and after analyzing different options, we may use it again.

In the meantime, we’ll keep improving our methodology by testing different approaches, inspecting them periodically, and adapting based on feedback (sounds like Scrum? ;o)

P.S.

Scrum is like a religion with a strong theory that is left to be implemented in a democratic way where the majority's opinion will prevail, even if they are wrong. In the meantime, teams must carefully choose the right pill by empirically testing different recommendations while being accountable for the possible side effects.

Growth
Ghenadie Dumanov
August 5, 2022