Scrum: not for you? Fine. But your article with criticism is dead wrong!
A Journey to Show what the article gets wrong
A response to “Why Scrum is the wrong way to build software.”
A Journey to Show what the article gets wrong
Many people think Scrum doesn’t deliver, that is unfit for the purpose of creating software. One of the many articles that touched this subject is Adam Ard’s “ Why Scrum is the wrong way to build software.” It gets many reads and claps. It is 2 years old, but still it is occasionally listed as one of the top stories concerning Scrum. The article is only a 3 minute read in which Adam Ard lists 14 apparent reasons why Scrum is doing it wrong.
I decided to respond to this article. It will be a bit longer than 3 minutes to read. Giving counter-arguments needs to be done in a solid way. Some people advised me to forget about it.
Responding to such an article would only bring new attention to it. My reason to still do this is that the article has had the attention for two years. And that will probably not change if we choose to ignore. There are too many faulty implementation of Scrum. We can’t simply ignore this and have Scrum’s name tarnished again and again.
So here we go. I will tackle the arguments one by one.
1 Because all product decision authority rests with the “Product Owner”, Scrum disallows engineers from making any product decisions and reduces them to grovelling to product management for any level of inclusion in product direction.
I don’t know how Adam Ard came to this conclusion. This is not what the Scrum Guide is saying. On the contrary:
“The Product Owner may do the above work (Product Backlog Management, WJA), or have the Development Team do it. However, the Product Owner remains accountable.” – SG
So the Product Owner should be in the know and should agree with what the Development Team does on Backlog Management. Having one person accountable only makes sense. This makes things transparent.
2 Scrum, in accounting for all the engineer’s time in a tightly managed fashion, discourages innovation — which typically occurs spontaneously and outside of any schedule or system of good predictability.
The funny thing here is that Scrum recognizes that working in complex environments is a journey, a discovery.
Scrum is built upon empiricism.
“Empiricism asserts that knowledge comes from experience and making decisions based on what is known.“ — SG
Empiricism is a concept that often is neglected when doing Scrum. And this is not only an oversight, but even invalidates your Scrum adoption.
This is why the Daily Scrum is so vital, as an example. Every day you should inspect if new developments could have impact on the Sprint Goal and then adapt.
This is also why the Sprint Backlog is a forecast of what will be worked on. A forecast only, because you can’t possibly know everything that will happen during the Sprint. As a result the Sprint Backlog emerges during the Sprint, because of new insights requiring you to adapt.
And another thing:
“The team model in Scrum is designed to optimize flexibility, creativity, and productivity.” — SG
Scrum is modeled to optimize creativity.
3 Scrum encourages “least amount of work possible” solutions — to conform to its strict predictability requirements.
Well, I already discussed the strict predictability requirements. Complex environments, empiricism and all of that.
This leaves us with the “least amount of work possible”:
“They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality” — SG
This is a clear statement I’d say. But granted, Adam Ard says “encourages”, not “tells”. Technically this does not cover the complaint. But there is nothing else in the Scrum Guide that promotes “least amount of work possible”.
I guess he means one of the principles of the Agile Manifesto:
“Simplicity — the art of maximizing the amount of work not done — is essential.” — Guiding Principle of the Agile Manfisto.
Agile and Scrum are not the same. Repeat: Agile and Scrum are NOT the same.
However… This statement can be applied to Scrum. Scrum is about maximizing value. It logical to build the functionality that adds the highest value first and doing this incrementally. This allows you to be transparent, to inspect and to adapt. A big departure from having tons of requirements, spending months and months on building software, only to find out that it doesn’t do what the users want.
4 By dividing every task into small items that can theoretically be completed by anyone on the team, Scrum discourages engineers from taking pride in and/or ownership of their work. This lack of ownership results in:
Poor design
Lack of motivation (“It isn’t my thing”, “It was broken when I start working on it”)
Says who? The Scrum Guide certainly doesn’t say this:
“Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.” — SG
I believe Adam Ard confuses cross-functional with ‘anyone in the team should be able to do anything’. Cross-functional means that all the skills required to complete an item are within the team. Scrum also says:
“Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person” — SG
It clearly states that different people can do different types of work.
With that the whole point Adam Ard makes falls flat.
5 Scrum is highly intolerant to modification, and its proponents typically espouse an all or nothing attitude in its implementation. Its attitude of intolerance to self-examination is present in all of its practices. Only processes that operate internally to Scrum’s framework are open for modification — as for Scrum itself, it is seen as sacrosanct.
Scrum is a lightweight framework. There is plenty of room for freedom on Scrum’s canvas. It goes well with numerous other practices and processes and this promotes creativity. Scrum just tells teams to regularly reflect and adapt their way of working. That is not rigid at all. For more on this, see Sjoerd Nijland’s article “Definition of Scrum’.
Definition of Scrum
Road to PSM III — Episode 1medium.com
The Scrum Guide is updated regularly. Anyone is allowed and able to suggest changes:
Make a suggestion to improve ScrumGuides.org.
The Scrum Guide is a community website, created and maintained by Jeff Sutherland and Ken Schwaber. Via this User Voice…scrumguide.uservoice.com
On top of that the quote from the Scrum Guide about Scrum being immutable is totally logical. Scrum is presented as a framework. Everything is intertwined. Sure, you can choose to deviate from Scrum, but you can’t possibly call it Scrum. Scrum already suffers from the numerous bad implementations.
Even the very article that I am now responding to has tons of examples of bad practices and then blames Scrum.
6Scrum is very management heavy. Typical teams have Product Owners, Scrum Masters, and Team Leads. Innovative, motivated teams operate better with less management, not more.
Obviously the Team Lead isn’t part of Scrum. The Product Owner isn’t managing the team. The Scrum Master is a servant leader only. The team self-organizes their work. I fail to see the point.
7Scrum is typically implemented with HORRIBLE task management tools (Jira, tfs, etc…) that enforce very bureaucratic interpretations of Scrum that waste huge amounts of developer time. Additionally, they effectively lock you into one mode of operation, no matter how ineffective.
I quote “Very bureaucratic interpretations of Scrum”. Interpretations. This says it all. This is not Scrum, it is Scrumbut.
Ironically Scrum is very clear no practices and tools should be enforced. This is up to the development team:
“They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality” — SG
With this point Adam Ard even suggests that Scrum is not bureaucratic, but suffers from bureaucratic interpretations. I agree with this!
8Scrum discourages bug fixing, reduction of technical debt, and risk taking, all because of its narrow, exclusive focus on only doing items that Product Owners would interpret as valuable.
According to the Scrum Guide enhancement and fixes are on the Product Backlog:
“The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.” — SG
On top of that: Scrum.org heavily promotes practices like (A)TDD, BDD, CI, SOLID, Clean Code). For this I can refer to the Professional Scrum Developer Glossary.
Adam Ard also ignores that the Scrum Team works together on getting the highest value out of the product. The Product Owner is not sitting on an iron throne. And if the Product Owner would act like this it’s the task of the Scrum Master to spot this and have this discussed/resolved.
9 Scrum is hypocritical
Do managers or Product Owners track and estimate every task they engage in with little or no say in what they work on?
Tracking and estimating are solely for the Development Team’s own use to understand if they are still on track and if not to assess what they can do to get back on track. It’s also important to note that this is not mandatory at all. It’s a choice of the Development Team.
The Development Team a self-organizing team. They have every say in what they work on. They decide what goes into a Sprint AND they decide how they are going to build a working increment.
Are they required to present burn down charts that show that they are on target to finish?
The Development Team is NOT required to present burn-down charts.
Are they required to do bi-weekly sell-off meeting to justify their activities?
Firstly, the Sprint Review isn’t there to justify the team’s activities. It is there to show what was planned, were you stumbled upon, what you learned and which direction you went because of these findings.
“During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.” — SG
It’s all about acknowledging that you are working in a complex environment with complex products and touching base with the stakeholders to see if the team is still on the right track. It is NOT to justify the activities.
The Development Team has everything to say about what they will work on.
“The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.” — SG
The Development Team estimates the work for their own use.
Any projection on the product’s progress can be done, but doesn’t replace empiricism. That is a notion that should be shouted from the rooftops.
Without empiricism there’s no Scrum.
10Scrum makes many faulty assumptions
Only Adam Ard makes these faulty assumptions:
It assumes that engineers do not have task tracking systems that they already use to manage their time and therefore need time-management hand-holding.
Scrum doesn’t mention task tracking systems.
It assumes that engineers are not to be trusted with directing their own work.
Scrum is all about self-organizing teams, as mentioned earlier. This remark falls flat.
It assumes that engineers cannot align themselves with the best interest of the organization, without tight supervision.
Again, the team self-organizes without supervision.
It assumes that engineers cannot conduct a meeting effectively without a facilitator (Scrum Master)
A Scrum Master doesn’t have to attend the Daily Scrum. And regarding the rest of the meeting: there’s a thin line between facilitating and leading a meeting. Plus, the Scrum Guide says:
“Facilitating Scrum events as requested or needed” — SG
The Scrum Master facilitates meeting if requested or needed. It’s not a rule that the Scrum Master always does this,
It assumes that you can plan every facet of a software task by merely talking about it in sprint planning/backlog grooming
It does not. Scrum is founded on empiricism.
“In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.” — SG
It assumes that all engineers work the same way.
This is a repeated claim. It does not. As stated before.
11Scrum story points are supposedly meaningless, yet they are tracked, recorded and presented at many levels in an organization and often are the only metric by which a team’s performance is represented (ie. Velocity)
Scrum doesn’t prescribe Story-points. The argument falls flat. What’s more: if you search for the word ‘story’ in the Scrum Guide you won’t find it!
12Scrum is designed to manage the weakest Engineers and consequently dis-empowers the better ones.
It does not:
“They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality” — SG
13 Scrum is the opposite of many of the points set forth in the original agile manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. These are our values and…www.agilemanifesto.org
Scrum is founded on empiricism (there we go again, sorry for repeating myself). So item 2 and 4 are covered. Item 3 is covered by the Scrum Events. The Sprint Review stands out here. For item 1: Scrum as a framework is created to promote self-organization and interactions. It’s lightweight. This one is covered as well.
The Manifesto for Agile Software Development is written by many authors of different frameworks, including the authors of Scrum.
14 Scrum ignores the fact that any task that has been done before in software does not need to be redone because it can be easily copied and reused. So, by definition, new software tasks are truly new territory and therefore very hard to estimate.
Scrum is founded on…. Ok, ok I will try something else for a change. In complex environments… Oh I used that one too. Hmmmm. OK, here’s a new quote, the very first sentence in the Scrum Guide:
“Scrum is a framework for developing, delivering, and sustaining complex products.” — SG
And:
“Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.” — SG
Yes, sorry. I couldn’t resist. But it’s just that…
The whole concept of Empiricism is so fundamental for Scrum!
Final thought
Here’s an article that got many views and many claps. And there are many articles like that to be found. This only shows how often Scrum is misunderstood. This is worrying because all bad implementations of Scrum -without even knowing what it entails- are bad for Scrum’s reputation.
Adam Ard brings forward many malpractices and anti-patterns that are associated with Scrum. Many people that use Scrum appear to be forgetting the extremely important concept of empiricism: make things transparent, inspect and adapt. And then blame Scrum.
I am truly flabbergasted about this. It’s like blaming a car manufacturer for making a bad product because you can’t fly with it. It’s like going to Greenland for a beach holiday and then complain it’s too cold.
Read the Scrum Guide. Then read it again. Then read about Scrum (I recommend the Pocket Guide to Scrum from Gunther Verheyen). Then try to use Scrum as it is explained in the Scrum Guide.
When you have done this all we talk again.
Did you like the article? Then it would be awesome if you’d clap 👏🏻. I am also very keen to learn what you think about this topic.