Selecteaza limba
Our experience with SCRUM in a deterministic project
Some people say Scrum has failed.
Ron Jeffries, one of the 17 original signatories of the Agile Manifesto, had this to say in response: “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.”
In his opinion, all good ideas eventually fail due to flaws in execution or flaws in the people putting those ideas into practice.
But I have a counterpoint to that argument:
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?
Yes, some projects fail because people misuse Scrum. But in many other situations, Scrum is at fault because it is simply not the right solution for the project.
Here is why.
There is too much hype around Scrum. Many people react to it as they do with Bitcoin or Unicorns - they think it is a good investment because so many invest in it.
In the case of cryptocurrencies and startups, success often relies on early investor interest. If a project can attract more investors, it has a better chance of avoiding failure.
But hype or popularity is NOT a sustainable foundation for a methodology or framework!
And along with the hype, there is outright bias. Articles that compare Scrum and Waterfall are often biased in favor of Scrum. The supporting evidence is either incomplete or mispresented.
The first challenge was juggling with Story Points, time, and Velocity. Scrum promised that Points are a better way for estimation than Man-Days. So, we started defining our measure of a Point and synchronizing our team’s perception of Points. Then we measured the Velocity - in our case, it was around 20 points per two-week Sprint for six developers.
In the end, 20 points were equal to 60 MD (6 developers * 10 days), which means we got to a measure of 1 Point representing 3MD for our case. So we got back to MD.
One could argue that the Points can handle different productivity of the developers: one point could mean 2 MD for a senior and 5 MD for a junior. But we can solve this by using the MD as our team's average productivity. And in this case, we wouldn’t complicate our way of working with a new concept.
So why use a tricky way of representing estimates? Maybe the answer lies at the beginning of the Story Points, when they were invented - according to Ron Jeffries, developers decided to obfuscate time estimates into Points because they couldn’t explain to the stakeholders how they evaluate the work. In conclusion, Story Points had the aim of reducing Transparency!
More articles analyze on a deeper level why we shouldn’t use Story Points.
The next challenge was related to the delivery of 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 create increments, we had to split more significant components and modules into intermediate working versions. But with just a partial functionality, these versions usually didn’t bring valuable feedback, so splitting brought 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 created our own Definition of Done instead of following the common opinion.
We initially estimated six months for the project, but it took two years. And the worst part about it was 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. We should rely on other methodologies if we need a reasonably accurate and achievable delivery date.
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.”
Based on that logic, we were doing Increments to ensure that the product didn’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.
There is no need for more unless we have serious doubts regarding the quality of requirements or the team's ability to understand them - which was not applicable in our case.
In conclusion, in a deterministic project, we don’t need Adaptation (by Scrum definition); by extension, we also don’t need Scrum.
I suspect that Scrum is so popular because some Product Owners promote Scrum by promising Flexibility while actually hiding their inability to produce quality requirements.
This approach is also incredibly convenient for such people, as it would help them escape individual responsibility. After all, it is easier to justify delays when issues are shared regularly with the stakeholders.
While transparency is excellent, it could easily pass the burden of decisions on issues to the stakeholders. It is not easy for a stakeholder to make a difference between unexpected issues arising due to the project's innovative nature and those created by poor analysis.
I’m only referring to projects with a clear scope where 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 such cases, 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 that does not sacrifice transparency.
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, if a particular project demands its use, we may consider using it again. But we will only do so after thoroughly analyzing the different options available to us.
In the meantime, we’ll keep improving our methodology by testing different approaches, inspecting them periodically, and adapting based on feedback (that does sound suspiciously familiar, doesn’t it?! ;o)
P.S.
Reflecting on my experience with Scrum, its underlying theory, and its hype, it feels more and more like a religion implemented democratically. As a result, teams are blindly adopting Scrum based on the majority's opinion and not on arguments.
For me, this is where Scrum fails so spectacularly.
