Many of us have gone to the gym and, initially, obtained good results. Once your body has adapted, the same routine may help you maintain, but you won’t see any further gains and you might even start going backward.
I feel scrum as a methodology for delivering software projects is suffering from the same problem. The scrum cycle, or the way of practicing scrum, is either taken too literally or adhered to too rigidly.
Scrum should be about defining an achievable sprint goal for two weeks. Scrum should encourage teams to learn through experience, self-organize while working on a problem, and reflect on their wins and losses to improve continuously.
In my experience, scrum has, unfortunately, ended up destroying the central tenet of Agile, which is people over process. A lot of this comes down to bad management and the rise of the certified scrum master.
The daily scrum is supposed to be a 15-minute, time-boxed event for the development team to plan for the next 24 hours. Unfortunately, standups have become a medium to fixate on Jira tickets moving across the board.
Moving tickets across a set of swim lanes is a bit like counting lines of code as a metric of success. A developer can appear productive simply because of how quickly they have moved their tickets. On the flip side, a focus on the board can reduce good developers working on challenging problems to look average.
If done well, scrum encourages teams to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to improve continuously.
In scrums advocated by the infamous scrum master, you need to clear tickets, Moreover, there is no actual check on the quality of the work, which is often determined by a nontechnical project owner. That incentivizes going into a void and focusing on outputting code.
Story points are units of measurement for expressing an estimate of the overall effort required to fully implement a product backlog item. Or, at least, they should be.
In my experience, story points can encourage teams to game the system. After falling short of meeting their targets in several sprints, savvy project managers will become fearful of bringing too much into a sprint.
The fear of failure leads to small story sprints where only minor ticket items are brought into play to ensure their completion. The bigger picture becomes irrelevant, and focusing on small things will eventually take the project off the rails.
I have seen this firsthand on a project where each story had to have an automation test. These tests come with a high maintenance budget, and the automation tests for this project slowed development to an almost standstill. When automation testing becomes the focus, fitting the development and maintenance processes into a two-week window escalated the continuous integration build time to two hours. The pipeline ground to a halt and change was forced.
The converse of bringing too little into the sprint is carrying too much into the sprint. Developers and testers cut corners while accruing technical debt. The debt is never repaid, and the spinning plates will eventually crash to the ground, causing a massive and expensive rethink.
Instead of relying on story points, we should track work completed and not what we estimated. I find this staggering. If I want to know how long a similar piece of work took, I want to know the actual time and not the estimate. If all your stories are small enough, then you don’t need estimates.
The purpose of the retrospective is just that: to reflect. We look at what worked, what didn’t work, and what kinds of experiments we want to try.
Unfortunately, what it boils down to is putting the same Post-its of “good teamwork” and “too many meetings” in the same swim lanes as “what went well,” “what went wrong,” and “what we will do better.”
After the first retro, it is boring. The certified scrum master’s lack of imagination is a massive part of this, but I feel the retro is now a tired and dull waste of time.
Hackathons and practical activities might serve better than a retro for trying out new paradigms. Collaboration is implicit in a hackathon, and the only way to succeed is with good teamwork. Working on a fun problem with an imposed deadline ensures learning.
Retros force people into a room twice weekly with a “let’s be retrospective now” mindset. It becomes repetitive and boring, and there is no dynamism. Teams need new stimuli, not the same redundant two-week groundhog sprints.
Scrum is often the enemy of productivity, and it makes even less sense in the remote, post-COVID world.
The premise of scrum should not be that one cookie cutter fits every development team on the planet. A lot of teams are just doing things by rote and with zero evidence of their effectiveness. An ever-recurring nightmare of standups, sprint grooming, sprint planning and retros can only lead to staleness. Scrum does not promote new and fresh ways of working; instead, it champions repetition.
Let good development teams self-organize to their context. Track what gets shipped to production, add the time it took (in days!) after the fact, and track that.
Focus on reality and not some vaguely intelligible burndown chart. Automate all you can and have an ultra-smooth pipeline. Eradicate all waste. Constantly re-estimate as you know more. The idea that you are estimating and sticking to your mythical story points when you know the least at the start of the work does not hold much water.
Adults playing planning poker is as ridiculous as it sounds. ♣️ ♦️
Install LogRocket via npm or script tag. LogRocket.init() must be called client-side, not
server-side
Learn more →
$ npm i --save logrocket
// Code:
import LogRocket from 'logrocket';
LogRocket.init('app/id');
// Add to your HTML:
<script src="https://cdn.lr-ingest.com/LogRocket.min.js"></script>
<script>window.LogRocket && window.LogRocket.init('app/id');</script>
In this article, we’ll explore CSS cascade layers — and, specifically, the revert-layer keyword — to help you refine your styling strategy.
Nushell is a modern, performant, extensible shell built with Rust. Explore its pros, cons, and how to install and get started with it.
The Zed code editor sets itself apart with its lightning-fast performance and cutting-edge collaborative features.
Infinite scrolling in Next.js no longer requires external libraries — Server Actions let us fetch initial data directly on the server.
32 Replies to "Why scrum has become irrelevant"
This is just an explanation how Scrum can be done wrongly, nothing else. The title is a clickbait, a good one apparently because I read it.
this is not how clickbait. that is a pointless jab. i would not have written it without years of frustration. it is scrum done badly but scrum done badly is the norm
But it’s still done badly so therein lies the issue. Also it’s not a methodology and if treated so it becomes a process without recognising any potential redeeming merits.
The focus however should be on agility and a clear separation once again made between agile development and business agility.
Based on your description it seems that you have a scrum master enforcing the scrum dogma instead of supporting the team in being it’s best
And finally, if the management aren’t on board and prepared to step back a bit then quite simply **** it all, as it’s a **** or get off the pot scenario
The idea of tickets moving across the board is to share the progress and enable the team to spot bottlenecks and replan to assist each other.
When you say that due to not completing a sprint less is brought into the next then that is the point of velocity. If you haven’t got through that amount of work before then you should be doing 2 things, asking why/what improvements can be made to enable you to get through the work in future but also adjusting your next commitment based on how much you did get through. What’s the point in over aiming continuously and wondering why it’s never achieved when it never has been?
In your retros do you create any tangible actions? Do you identify what is in the teams control and what is outside of the team? The teams actions should be based on what’s in their control. If they can’t control it then they should escalate via the Scrum Master to those with influence.
I’m sorry that you’ve had a bad experience with Scrum and it sounds like bad Scrum masters but to say Scrum is irrelevant isn’t fair, a fairer title would be the effects on Scrum when implemented with no thought
The beauty of scrum.. you’re always “doing it wrong”
Yes you are, because you “do agile” and “apply Scrum” rather than being agile and think. Most orgs don’t get it. Too many SM think they get it because they got a certificate after a two day training. To anyone in this situation, read books from Sutherland to understand why Scrum was defined this way. “Applying” without understanding why it is how it is means you LL get stuck in applying it blindly, without understanding what it means.
Also please check talks by other signatories of the manifesto. Will help you.
Oh, and as for the author, if you have a project manager and are doing Scrum, it surely shows you work in an org that completely missed the point 🙂 keeping old roles and org structure and adding new Scrum role to it is adding complexity, more split responsibilities, less clear ownership (who decides, the PO, the PM, I guess you also have delivery lead, maybe QA lead?:()
Better don’t do Scrum then, your org does not understand it and is not ready.
Bit harsh but proper food for thought! Thank you for sharing.
well said. the author expressed his frustration of reason not related to scrum, rather in his specific organization scrum master is unable to shield the team from management interference in scrum ceremony. retros are boring because what they practice is scrum but. team members have no common understanding of estimation..
Excelente texto
This isn’t a case against scrum it’s a case against bad scrum masters.
You could make this argument for any methodology, I’ve had good project managers before agile and Scrum. Manager who focussed on what mattered and we’re good with people and enabled their teams. Does Scrum training make a poor master better?
Yes and no. Ultimately its a problem with the team or with the org not empowering the team. Professionals should not be cowed. They should educate themselves and own how they work. If the org says we’re trying scrum the professionals involved should internalize scrum and own the implementation. If their PO or SM is out of line the team should not stand for it. Professionals shouldn’t enable bad implementations by being passive. If you can’t fix it, walk away.
Reading your article with keen interest in seeing what I can learn and change in the way we do scrum, I was disappointed, in fact it told me that you must be bored at what you do, the fact that you find Retros boring repetitive and lack of dynamism reveals it all; you have nothing of value to offer to your team, since there is a lack of interest on your part. I usually look forward to the retro to offer an opinion on changes, improvements and sometimes to show the weaknesses of the process we are following. This is the best time to agree on action and call for a change. I sympathize with your teammates, they may find you boring too.
thank you. that gave me a great laugh
I’m not the type of person that will defend scrum at all his costs. But damn, this article seems a personal “attack” for a specific team/scrum master.
Actually I can feel the frustration of your team and can empathize with them. Most of the failures have been due to inexperienced scrum master or confused management who cannot understand scrum
Scrum is a framework, sunshine. This information tells appx.90% of your frustrations.
Instead of “Let’s retro scrum” I suggest “Let’s retro your Scrum” 🙂
If you like to walk the Scrum way, your attention should be focus on try to comprehend how to overcome the gap you’re experiencing between “your Scrum” and Scrum. Otherwise, just use your own method and named it as you like: that’s fine too
Scrum challenge common mindset and habits. Scrum invite you to have a change. If you relax the framework to fit your own way, what’s the point?
To me, this post is a nice talking of common difficulties, misunderstandings and resistances that arises in most Scrum adoption.
Great article, Paul. Based on the comments, and all of our varied experiences, this is quite a hot topic. Looking at the technical aspects of framework/methodology parts of the above article, I am rooting for you to find a team that efficiently uses Kanban or maybe even scrumban. I say that, because you’re right; scrum, and its practitioners, (or pushers), are sometimes too rigid. And, the powers that be love it that way. Whereas Kanban or scrumban allows us to find a, well, for lack of a better term, more ‘natural’ velocity for our work. There is the SAFe option, but that feels like an overly complicated, overweight framework created by the old PMP guard, who just want to justify selling certifications to those they’ve fooled into becoming believers in an inefficient, agile-esque format. The operational problems you describe are the result of a 19th to mid-20th century command & control, management mindset that has no place in 21st century technology businesses. But, these bastards just can’t let go of the power they like to wield to rule other people’s lives. Your frustration is palpable, and justified. Until we get to a point where people learn what a lightweight framework like scrum is supposed to be, though, I’m afraid that many of us will continue to encounter the same garbage you so eloquently described. Thank you for having the guts to share your experiences.
Sorry that you have obviously not had the best experience. There are some really inexperienced people out there saying they are scrum masters. Good ones though can use the framework to coach a really meaningful transformation of purpose and value driven development, I hope you find that one day! P.s I have added my two pennies in here of what I can see at first glance has been going quite wrong in your experiences.
https://medium.com/culture-hackers/scrum-doesnt-work-8bffd0fe64cc
nice post. i think a lot of commenters have missed the point that i am not blaming scrum. it could be good, i just see it done badly in a nearly identical way in each contract.
what you wrote about sounds great
Except that your title is scrum is irrelevant… Seems like a direct attack to me.
no direct attack, I have seem the same problems in the UK and the US
I sympathize but at the same time don’t. I’m a software engineer and I have yet to encounter Scrum implemented properly. I’ve only met one SM that really knew Scrum or had the backbone to fight for doing it correctly. He’s the guy that didn’t come back after a week or so of observing how that org imposed scrum in name only.
Where I don’t sympathize is in that IMO professional engineers should strive for good processes. They shouldn’t tolerate the crap you and I have seen. They should push for positive change or move on. Whether its Scrum or any other broken methodology.
The CMMI model still holds and its still the case that 90+% of SW dev orgs are at level 1 or 2. Since you are a contract engineer, my advice is to just try to apply the Boy Scout rule to practices you see wherever you go.
As per the rest of the people commenting on this it very much shows your personal experiences and i do sympathise that clearly you are not working in self managing team and clearly your Scrum Master is obsolete. However it also shows how your understanding of the framework is flawed. Scrum/Agile is about responding to change in order to deliver value for efficiently, why dont you champion it instead of focusing on the negative? I am currently a SM who fully believes in the ‘framework’ however don’t think scrum is ever done as per the scrum guide, i think it’s pretty much impossible. I am just about to go back to a typical Project Manager role, not because i dont believe in scrum or that i dont like it, i just preferred my old job. Maybe you should consider a career change, maybe as a Scrum Master. Sounds like you’d actually be good at it.
Yes agree with most some parts are right while some points against scrum ceremonies are ridiculous. From a developer point of view it is only a working function or feature but sometime team alignment and working discipline is also required before one goes into a totally different direction. And usually across team understanding building is also required such that the team members know how a feature is going to be integrated in big picture. But if these are missing and not being done correctly in PI planning or iteration planning then there is the issue.
Yes some ceremonies can be skipped if we do not feel a need of but not the planning and stand-ups
I totally understood your situation and point of view. The question that comes to my mind is … what are the alternatives to Scrum? To be honest, I’m not convinced by other methodologies. I feel its a bit like democracy. Democracy is far from a perfect solution… but , where are good examples of alternative ways to solve the problem?.
Haha this article sounds personal. I think this mystery scrum master person you are referring to should be the one you have this conversation with so that your team can move forward constructively. Scrum is the best thing we have, most alternatives are not maintainable at scale.
definitely not personal and I’ve seen the same cookie cutter scrum practices in many contracts and on different sides of the atlantic
Thank you for the amazing article! 100% my feelings. Don’t get me started on scrum poker.
And always you get the but, but, but it’s because Scrum is not done right crap.
That’s always the fundamentalist’s answer to everything.
If projects succeed they clearly succeed despite of Scrum not because of it.
Groups of people got massive projects done before Scrum and will do so after Scrum.
Teams of people built cathedrals, split the atom and sent people to the moon before Scrum.
It still comes down to good leadership, work ethics, the will to give people the time and environment they need to do a great job and trust.
I know there are now too many people whose pay check depend on the propagation of this evil but let’s be clear that the infantilisation of grown professionals doing a complex job is nothing else but a desperate measure of management and all the email pushers out there to re-assert control and dominance over work they don’t understand and a work force they deeply mistrust.
Sure. So work in silos (remotely now).
Don’t be together to discuss the work or plan it. Hope that someone is riding a slack channel to see your update or blocking issue and pretend you don’t have to meet a project schedule or manage scope or be accountable for your cowboy non-process. Got it!
Is SCRUM the only means of delivering software? How we deliver software should change to the new world.
Standups and retros might have been relevant but are no longer. Story pointing is silly and insisting everything must fit in 2 week sprints causes fake accounting practices.
There are better ways,