The Top 5  Scrum Criticisms Repeated on LinkedIn (and why they are nonsense)

The Top 5 Scrum Criticisms Repeated on LinkedIn (and why they are nonsense)

If you are on LinkedIn long enough you will see the same Agile content being recycled over and over; the same arguments playing out. Normally these arguments take the form of someone who has progressed beyond the fundamentals feeling empowered to wholly criticise the existing frameworks or patterns.

However, quite often, the OP will either have misunderstood or is purposefully mischaracterising or is selling an alternative, possibly a combination of all three.

So I have produced this short guide to the repeatable criticisms you will see regarding Scrum...and why they are nonsense and should be ignored.

  • Sprints are toxic
  • Scrum does not have the thing I like
  • Scrum has a thing and I don't like it
  • Scrum is immutable and I don't like it
  • My X framework is superior because...reasons


Sprinting is toxic / horrible / pressured / limiting

This is common. You will typically see this arise because the OP is assigning the business pressures to the word sprint. An easy way to test the assumption is to rename Sprint to container or time-box or period and ask would the same criticism still apply?

We don't have enough time to do all of the things in the Sprint therefore sprinting is sub-optimal

becomes

We don't have enough time to do all of the things in the period therefore we should have less things not that 'periods of time are sub-optimal'.

A sprint is merely a container with a fixed start and end point that is repeatable. The name is terrible branding but the substance is fine. Teams and businesses thrive on regularity. Regularity drives sustainability. Time will pass regardless. All we are saying with a time-box is

  • we will start here with a bit of a plan
  • we will finish here with a bit of a review and some lessons learned

Over time a team may be so effective or so aligned plans and reviews can be cancelled or added as needed but initially it makes sense to keep it repeatable and uniform especially since it allows everyone, including the team and stakeholders, know in advance that some time is booked for these activities.

Summary

There is nothing pressured about a sprint. It is a mirror that reflects the company culture. If you fill a time-box with activities or prioritise certain activities you were not busy because of the word sprint, you were busy because you were busy.


Scrum Does Not Have The thing I Want!

This is common. You will see this a lot except it is purposefully an incomplete product framework for a reason.

You can extend it with whatever you need. In any other domain extensibility is seen as a positive attribute but magically, when it comes to Scrum, it used as a criticism.

The Agile world, and the world beyond, is comprised of hundreds and hundreds of patterns and tactics. Pick some and experiment with them. Add them for a period of time and see how they work.

That advice is contained directly within the Scrum Guide

Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value. The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.
Various processes, techniques and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary.

Summary:

Don't criticise a 14 page pamphlet for not giving you every answer. If it had all the answers what would we need you for? Only when it is Scrum do we ever criticise something for not being wholly prescriptive with every method.


Scrum Has a Thing I Don't Like!

The absolute pinnacle of the Scrum criticisms online normally take this form and usually the thing in question is not in Scrum but has become so widespread that people assume it is.

I hate Scrum because of T-shirt sizing or the 3 question format for stand-ups or etc etc etc...

The comments are usually filled with rebuttals saying that's not true. The OP response to any criticism of this kind of post is always the same comment

I am sure the Scrum case studies you have seen have been 'perfect' but in the REAL WORLD organisations add these things to Scrum and I don't like it! This post is raising awareness. Scrum is not PRAGMATIC. Scrum is THEORY only. etc etc etc

Normally at this point I roll my eyes hard enough to see the back of my skull. A prime example of this is contained here in the post Enough of Scrum and the author assigns Mario Kart retrospectives, story points and host of other evils on Scrum and refuses to acknowledge any of the counter-points.

It's really simple; if it is in the Scrum Guide it exists as Scrum, if it is not, someone else added that practice to your team or organisation. Take it up with them.

A few months ago a LinkedInfluencer did a similar post and when Scrum trainers pointed out the flaws the person claimed they were being online bullied and used that as the basis for another Scrum critique.

Ah but Steve, what if the thing I don't like IS in Scrum? What then? Gotcha!

You do have me. Guilty as charged.

So stop using Scrum.

Or use bits of it. But if you have a criticism of a specific practice (Product Owners, Estimating, Backlogs etc) then do a deep dive onto that practice. Don't ascribe failure to the entirety of the framework simply because it has a practice you don't support. Scrum does change over time. Not often, but it does.

However normally picking a part of Scrum leads to the mother of all agile debates which is below.

Summary:

99% of the time the practice being attributed to Scrum is not in the Scrum Guide. The OP is usually aware of this but assigns a nonsense reason for their assertion rather than admit they are posting rage-bait.

Scrum is Immutable, that is Unacceptable!

And here we go...you will see this one slightly rarer but it will be the biggest gathering of Agile practitioners you have ever seen back-slapping each other and revelling in their own sarcastic brilliance.

If you are unaware what this refers to; it is regarding this line in the Scrum Guide

Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

What the authors are really doing here is protecting themselves and their intellectual property. Scrum is licensed under the under the Attribution Share-Alike license of Creative Commons, accessible at CC Legal Code .

Saying Scrum is immutable is saying you can do whatever you like, just please don't call it Scrum if you change it.

That's not unreasonable and we have the same mentality in nearly all other forms of business. If we switch the domain we can see how reasonable it is.

A front-end developer may aim for the Accessibility Standards of the W3 Consortium. If they do not meet some of the AAA standard we do not let the organisation proclaim AAA-compliant. It's not a buffet that you pick and choose from. It's binary. You are either AAA or you are not. You are either doing Scrum or you are not.

You are free to say you are aiming towards accessibility and as accessible as possible but you cannot claim AAA standard if you don't meet all the criteria.

This is the premise of the Ron Jeffries post We Tried Baseball and it didn't work for us. Written in 2006 the article is arguably more relevant today than it has ever been.

The immutability part means to the implementer not that the framework itself is immutable. The framework can and does iterate. However the immutability of the framework is as it pertains to the implementer not to the authors. You are not the one allowed to iterate it because you are not the author. It is immutable to you.

And that is the real crime that drives Agilists to apoplectic rage. They hate that someone locked them out of the process and did it via a legal means as well.

Again, we can draw technological comparisons. We can be provided immutable containers or immutable AWS instances; that does not mean that the technology itself is immutable; just merely immutable to the end-user in that instance.

And that, dear people, is not unreasonable when protecting your Intellectual Property.

Remember that the next time you see the fallacious argument being raised.

My X Framework is Superior

Maybe it is. Good for you. Maybe I will try it. Maybe I will love it.

So sell it to us for the features, advantages and benefits not by criticising another product or service. You can say flow is really effective without saying timeboxes are toxic.

It's the first thing I normally tell new Agile Delivery Managers.

Do not define yourself by criticising waterfall. Look out of the window; find a crane in the skyline. That building will be finished before your IT service is. That's a fact.

We build things all over the city, all over the country, all over the world, using the waterfall technique. Everything from skyscrapers to battleships. So stop defining yourself via criticism of other things. Define your value by the positive aspects.

Coca Cola don't sell products based on it not being Pepsi. Pepsi tried to and that is why they were never the market leader and never will be.

CR7 Ronaldo was not one of the greatest athletes in the world by criticising Lionel Messi. He was Ronaldo because he was busy being Ronaldo and pioneering his brand of effective athleticism.


In summary, I am not a massive advocate of Scrum. I let my one and only Scrum certifications lapse years ago and will not pay any money into the certification ecosystem but I also hate that people, supposed Agile practicioners, love to pile onto a public trial when the evidence against the framework is fabricated and false. Most of their criticisms actually reveal a staggering lack of understanding or, more commonly, the same capitalistic tendencies which they are criticising in the Scrum authors.

Next time you see one of these posts refer back to this list. I can near-guarantee the content will be one of these 5 things or a combination of them all.

It's lazy, it's click-bait and it's not worth your time.


If this was helpful, feel free to give me a follow. Infrequent (and sometimes controversial) articles about Agile, Acting and Business.

No spam.


Tom Whittam

Head of Delivery. Enthusiastic about minimising risk and maximising ROI.

7 个月

Love point 1 on the name of sprints causing stress. Reminds me of James Farley talking about the word ready accidentally creating a gate to starting work. Words matter!

回复
Kata Polgar

The Agile Cat Lady

7 个月

My all-time, personal favorite is 'Scrum is not an agile framework, as it does not mandate story points'.

Adrian May

Polyglot coder, data scientist and leader

7 个月

Those top 5 are all paper tigers. Try these: 1. Has digital (rather than stochastic) targets. 2. Usurps prioritisation criteria. 3. Turns real goals into a reconstituted ham of goal bits. 4. Makes people behave differently near sprint start and end. (Both can't be right.) 5. Mangles data at source that would have been useful for competent estimation techniques. 6. Encourages people to close tickets prematurely (to be seen to hit the sprint goal) and file other tickets for the incomplete bits. 7. Has the most primitive requirements gating and product management ever proposed. 8. Assumes all devs in a team have the same skills. 9. Nobody ever discovered a good way of figuring out how much could be achieved in a sprint. 10. Provides an excuse to procrastinate small favours for other teams. 11. Can't deal with genuine deadlines. 12. Has no constraints to its famous adaptability. 13. Considers all management to be micromanagement. 14. Fails to map (and hence defang) sequential dependencies. 15. Won't scale. 16. Exacerbates the Conway effect. 17. Completely misses the point of why software development is challenging.

回复
Philip Ledgerwood

I take the risk out of your software development projects and make them valuable, efficient, and predictable.

7 个月

As someone who doesn't care much for Scrum, I support this article.

要查看或添加评论,请登录

社区洞察