Does scrum ruin great engineers or are you doing it wrong?
The idea of the scrum framework is to organize a development process to move through the different project cycles faster. But does it always incentivize the right behaviours doing so? Many of the users who joined the debate around the question on Stack Overflow have similar stories of how developers take shortcuts, get distracted by their ticket high score, or even feign productivity for managers. How can one avoid these pitfalls?
That the question has been migrated from our workplace exchange to the software engineering one shows that developers consider concerns about scrum and its effectiveness larger than the standard software development lifecycle; they feel its effect on their workplace as a whole. User Qiulang makes a bold claim in their question: Scrum is turning good developers into average ones.
Could that be true?
Is scrum the cause of bad development practices or just an excuse for it?
A lot of the debate tried to grapple with the impact and limitations of scrum on any given team or individual. While many see scrum as the cause of team failings, others believe that to be an attribution error and say dysfunction in dev teams runs much deeper.
The scrum defenders see poor management as the cause. Llewellyn writes in his closing remarks: “If management is essentially ignoring the developers, there are fixed deadlines to be achieved with a predefined scope, or it’s a dog-eat-dog environment instead of a team focused on achieving the same goal, if planning ahead and thinking out of the box are not appreciated, then yes, eventually you’ll give up and resort to just doing the assigned tasks. I’ve been there. But don’t blame that on scrum.”
User DJClayworth echos the sentiment of many comments by saying “developers who think they are under pressure) will do a crappy job in any development methodology.”
The opposition is best summarized by user Martin Maat, who points out: “The mere fact that so many people feel the need to say something about it is an indicator of the frustration scrum causes.”
Let’s unpack some of the points in the discussion. Regardless of whether you are pro or con, we can take a look at the discussion to see where scrum fails developers and where it helps them excel.
What are typical scrum pitfalls?
Whether people are doing it wrong or if it is a baked-in bug in the scrum framework, a few common developer traps pop up in the comments. Here are ten that stuck out to us:
- Standups are for managers
A first criticism is about how unintended dynamics happen during standups. One argument is that they can degenerate to be just as a show of productivity, especially when managers are present. This is the reason user Matthew Gaiser in his answer relabels standups as “update management.” In his mind, check-in only invites managers to keep tabs on what is being worked on in unhelpful ways. This is even more true for distributed teams that work asynchronously. (Full disclosure: Matthew has written for us before. But we stumbled across the scrum question by chance)
- Prioritising ‘done’
Another point raised is that any process that divides up work and tracks progress leads to a new measurement for progress (deliberate or not). Just by introducing metrics, this influences the behaviour of the people contributing to them.
Many commenters suggest this means developers might cut corners in order to complete what was committed to finish in the current sprint. The problem Gaiser and others point out is that an individual ticket that is being worked on and moved to ‘done’ during a sprint is a black box. It counts the same for the velocity indicator. “A lousy implementation,” Gaiser wirtes “that passes QA and a well-tested, well-architected implementation are equivalent.” It’s a false indicator of productivity.
- Very productive individuals that don’t work as a team
Another thread mulled the discrepancy between great individuals vs. great teams. With everybody following the scrum methodology, you might get some highly efficient developers, but you don’t have a team. Gaiser argues that without the right incentives, self-organisation is an unfulfilled goal:
“Team members are going to do things the way they prefer/are incentivized to do and unless that adds up to a useful team, lots of things do not get done and team members just keep marching on over the mess.”
Furthermore, leaving each developer to choose their method for solving a problem, said Gaiser, creates more work during debugging.
- Complicated tasks get deprioritized
In a similar vein, Gaiser further criticises the illusion of productivity—there is a focus on getting any ticket to ‘done,’ while deep thinking does not look very productive. So developers might pick low-hanging fruit and skip the tough-to-solve problems. Gaiser again: “Scrum encourages picking work that can easily be done and rapidly churned out at a steady pace.” The result: Daily catch-ups and check-ins encourage picking tasks that can be done in one day.
- Features over robust code
The quality, Gaiser believes, will suffer. “Great developers are usually defined by their ability to develop robust code. Unless the product owner is technical, scrum massively devalues that as the product owner isn’t evaluating the code.” To this point he stresses that a ‘done ticket’ is often a feature decision and not a check of the code being written.
- No time for cross pollinating or exchange with peers
When velocity is the only measurement, the team no longer has time to consult, to give a second opinion, to run a concept by someone—all the things that make a team a team. In Gaiser’s words: “Great developers are often sought out for advice and for second opinions. But any time doing that is less time spent churning out tickets, so their velocity falls.”
- New bugs have to wait
Another of the scrum bad behaviours is that “bugs are found after the sprint and therefore counted as new work.” It incentivises behaviour where developers might release flawed code, because that new work can’t be included in the current sprint.
- Ticket-driven architecture
Not only do devs make choices about what to work on based on the ticket system, Gaiser also suggests that scrum unintentionally creates messy architecture, with developers working through tickets sequentially and independently from each other as “the architecture rapidly begins to mirror the tickets.”
- One process to rule them all
Reading through the discussion you will find those arguing that not following the scrum rules properly enough is the root cause of all the problems. However, perhaps Gaiser’s strongest point against the scrum process is about it becoming the process that overrides everything else, and by this might break a winning team: “[Scrum] bends and breaks every other process to it and becomes this overarching process where you do nothing consistently except scrum rituals and making those scrum rituals seem successful.”
That’s a long list of problems, whether or not they are strictly caused or just brought to the surface by scrum. However, equally numerous were the suggestions of how to allow developers to live up to greatness under the scrum rules.
How to get the most out of scrum?
A lot of the responses to Gaiser’s answer—currently the top-voted—were about how his process was not scrum. Stephen Byrne wrote, “I think this is a good answer with some great ideas, but I must agree with most other commentators, the process being described here is definitely not scrum as it was meant to be.” But enough people either loathe scrum or resonated with Gaiser’s answer that something must be broken with how scrum is implemented.
So how can you do scrum right?
Daily standup ≠ new tickets each day
A lot of the debate suggested daily standups create pressure to deliver a closed ticket every day. But prioritization of tasks should still happen As user DJClayworth points out, if this does not happen naturally, it’s the job of the scrum master: “You should prioritize the tasks within the sprint, and you should prioritize the big tasks highest, so someone should pick up the big difficult tasks on day one. In any case, if by day two of the sprint, nobody has picked up the big complex task, then the scrum master should say ‘I see nobody has started the database compression task—that’s a big task and it needs to be started right away if we are going to finish it this sprint.’”
Stop chasing personal bests by not tracking them
Yes, you should break everything in a sprint into small pieces, but scrum does not say you should obsess about the progress—certainly not by pitting devs against each other. Gaiser suggests to stop tracking scores for individuals altogether. He also points out that many managers may need to relearn their process. “Tell management that the second they praise a dev or give them a raise based on ticket volume, they radically change behavior.”
User DJClayworth agrees, actively ignoring individual ticket metrics should be a good scrum master’s job: “The focus should be on whether the team completed its commitments as a team. The scrum master should emphasize this and avoid any discussion or measurement of how many stories each person moved.”
Break down the big goals, but don’t forget about them
Another note on breaking down tasks into chunks: Picking up a small piece of the puzzle does not mean ignoring the puzzle. Llewellyn stresses that the scrum process can be no excuse to forget good software development altogether.
“You should have a good idea of where the project is headed, and you can use this knowledge when you plan the architecture even for the current sprint.” Scrum does not absolve people from doing their job as experienced software developers so Llewellyn’s plea is to their peers among the readers. ”You’ve been in the planning meetings, you can check the backlog, you know what the overall vision is. You’ll want to avoid investing a lot of time into something far ahead in the future, but there’s nothing wrong with laying the foundations for an extensible, modular system that works well for what you need right now and will also support the planned future additions.“
Agree on your ‘definition of done’
One of the things that pops up is the Definition of Done or DoD and how this helps with keeping standards and expectations for the individual clear. The most pressing questions are who creates it and when? As for the ‘when?’: ASAP or during sprint planning seem to be common suggestions.
For the ‘who?’ SpoonerNZ writes as reply for another question on Software Engineering. “The Definition of Done is created by the team, but may require the scrum master to enforce quality constraints if the team doesn’t have clear development standards. For example, a team may not want code reviews or unit tests, but a scrum master may need to enforce them to ensure quality is maintained. In the ideal situation, the team see the benefits and want such quality constraints, but the real world isn’t always ideal.”
Who needs to share the DoD? Well, naturally the (difficult) goal is to have everyone on the same team to agree on it. There are good reasons though to extend it to several teams. Or even an organization. Alan Larimer on this: “Without a common definition of ‘Done’ for a product, quality and its transparency will be negatively impacted. Organizational levels of Definition of Done should be minimal, technical, and sometimes provided by the organization so it can be applied universally. The organization may provide coding standards. The organization may require automated builds while providing the resources to create and maintain it for each product. Any part of the definition of ‘Done’ whether created by the organization or by an individual development team must bring value.”
Managers as silent observers
Even though it is already part of the scrum guidebook, the discussion seemed to suggest that many, sadly, experience daily standups where managers are present. Because of this, they feel that they need to explain why tickets are taking them longer than they would have to in a meeting with just their peers. So to reiterate: A standup is a team meeting. As stated in the original framework guide: “The daily scrum is an internal meeting for the development team. If others are present, the scrum master ensures that they do not disrupt the meeting.”
People over process
If you want a rule about how to apply the set of rules in the scrum framework, Frank Hopkins comments with the classic maxim, “People over processes,” and elaborates, “A good team should define its processes, rigid processes don’t make a good team.”
Another user, meriton, points out that scrum depends on the individuals. “Scrum does not say that developers work independently. It says that the development team organizes itself, meaning the team gets to decide how its members collaborate.”
nvoigt notes that teams in scrum self-organize because they come to a project with a mission already established. “Scrum builds on the fact that you are a team. In a team, it does not matter whether you got ‘a ticket done’ yesterday. In a team, you agree on what your goal is (i.e. Definition of Done) and then strive to reach it. Together.”
Build a team to do scrum, don’t expect scrum to build your team.
User nvoigt goes for the sports metaphor: “Just imagine 11 people being handed a soccer manual and being told practice is every day for fifteen minutes around 10 AM in conference room #5. Do you think that is what makes a good soccer team? But what if those 11 people were really good, professional players? Still no team? No. It’s just not how you build a team. Just as team sports, scrum needs the participants to be a team. If they are just participants that look to boost their own standing by showing off how many story points they did or how many goals they scored, they will always lose the day to a team that works together instead of next to each other or against each other.”
nvoigt is ready to admit that scrum does “not work with every person and it does not work in every constellation” and as the participation around the question showed, the set of rules that is scrum might lead to realities that are very far from the intention.
There are many voices in the thread jumping to scrum’s defense and reiterating it as elevating teams to greatness and empowering a team to grow beyond its individuals.
A parting thought comes from Seth R. He says there is no miracle to be expected from agile rituals in general. And demanding them to magically fix a team is asking too much. Rather, his interpretation is: “It’s all about tightening up the feedback loop so the team can self-examine and figure out for itself how to get better. Scrum won’t help you build a better product, but if you take the self-examination step seriously, it might help you build a better team. That in turn leads to a better product.”
More than one person likened the framework to democracy. So is scrum, perhaps, the worst form of development process, except for all the others?
Or is it, as the Scrum guide states, a framework that is simple to understand but difficult to master?Tags: agile, scrum
Another day, another “Scrum doesn’t work for you because you’re doing it wrong.” 🙄
I don’t understand why it’s so hard to grasp that Scrum doesn’t work for people because Scrum is a completely flawed work process. It incentivizes the wrong behaviors; it wastes extraordinary amounts of time; it encourages quickly produced bug-ridden code. For any software shop, it’s an utter disaster. I have seen it fail in every Scrum-infested workplace I’ve worked at.
Perhaps it works in other industries. But in software it’s a cruel joke and it needs to stop being foisted upon developers. (And it is foisted upon us; I’ve never seen a development team who, themselves, chose Scrum. It always comes down from the PHBs in management.)
“Scrum is hard and disruptive”, said Jeff Sutherland in his article of the same name. Jeff Patton recently said the industry complained about Waterfall and now complains about agile. He’s not wrong! As a certified Professional Scrum Trainer (PST) and agile coach going on 15 yrs I’ve seen all these behaviours over and over again across hundreds of teams and dozens of organisations. If Scrum is good at doing anything it’s making existing problems, particularly with people, culture and management, very transparent.
When any adopted process or framework is implemented poorly people suffer. Misunderstanding Scrum’s roles, artefacts and events is the easiest way to turn teams sour and its dynamics dysfunctional. Mistaking Kanban for simple visual management isn’t the solution either – it’s rules are far stricter and more difficult to implement well than Scrum (if a team can’t set a goal and inspect their progress toward it (aka Daily Scrum) there’s no way they’ll be able to limit their WIP).
State of Agile has highlighted for over a decade that the main risks to agile success are management support, consistency, culture, and experience. If you don’t have these, and you can’t work as a team to achieve a goal together, then maybe that’s why such a simple practice of empiricism isn’t working as intended.
> that the main risks to agile success are management support, consistency, culture, and experience
Management support to ignore Scrum and do the right thing as needed.
Consistency, doing the above consistently.
Culture which prioritizes product needs instead of process needs and it’s product-centric.
Experience, meaning a process can’t do anything without technical experience, not matter how much scrum tries to hide that.
Also Experience tells you that scrum is meaningless, Software milestones (which are releasable), are of arbitrary sizes, 1 day, 3 weeks, 4h, 4 day, 30 min, 4 months based on product evolution, product phase etc. The sprint based planning of scrum contravenes logic, why wait 2 weeks to release a 3 days story, or why release after 2 weeks a broken story that takes 3 weeks to complete, wasting everyone’s time explaining what isn’t working yet?
Grooming – it does not achieve it’s goal. To make a task sufficiently specified to be implementable. Way to often the task needs re-assessment during development because at grooming phase what you imagined and what the team decided to implement are not the same.
Retrospective – A useless forced meeting where each time it’s the same lesson, “We need to estimate better to capture X and Y” and “Doughnuts would be nice from time to time, also fruits Mondays”
Sprint commitment – yeah right. If something don’t fit? back to “We need to estimate better” and “We move it to next sprint”.
Burndown Chart – Inexperienced manager fantasies where he sees a beautiful strait line. Reality the line looks like a cliff, drooping down the last day (And this is a good case)
Basically Scrum fights you instead of helping you.
I’m wondering if ever had the opportunity to know something about Scrum. First of all Grooming is an old term as old as Matusalem, not used anymore. In Scrum you can release as many times as needed within a Sprint. You do not have to wait for until the end of a Sprint. Then, if teams are made up of “sociopaths” that are not able to communicate but only stay in a room and coding like he’ll, we’ll, it’s not a problem of the retrospective if it doesn’t work. Go back please to whom teached you Scrum and ask him /her where did he/she studied Scrum. This is not Scrum what you described
People justifying their jobs, nothing new.
The magic “performance boots” coming from Agile, Agile this magic word
It kills a developer through burn outside.Non technical people as scrum masters are worst.They dont understand howmuchever u explain
Bosses, like scrum because it promises “progress” and “unlimited changes” until they loose sight of what their product was originally intended for.
I concur. I have written an 8 page paper on the problem with this fallacy. I am a senior software engineer who has been unemployed for nearly two years because I can’t find a job where agile scrum is NOT used! And at my last job, I was doing level 3 software support. My employer forced my team to do scrum. How the hell can you apply scrum to a support job when you have no idea of how many tickets will be submitted during the sprint and what severity those tickets will be? Were we supposed to have a crystal ball during out spring planning meeting? As you stated, it was upper management not having a clue on what we did and how we worked most efficiently.
I have had success at every company where I have worked except the ones where I was forced to use scrum. Scrum is an utter joke that has pissed off many senior developers. We’ve lost our autonomy and the opportunity to try different algorithms because the morons insist on a time limit for every menial task. Hello crappy code. Hello technical debt. Hello no systems documentation so the next person has to struggle with code modifications and bug fixes.
That pretty much sums it up Luke, how depressing it is.
I’m really struggling on a scrum team I’m currently on and I think the reason is what you mentioned. No autonomy. No code ownership. Just a list of tasks I have to switch between that I don’t care about.
In my probation period, people in my team make fun of an intern, who created two more issues by working on one issue. Looking at their code base and documents, I can understand why. While I am trying to write more tests and documents to avoid bugs in the future, they assign me a new ticket.
Absolutely. All I see is a blind horse leading.
A person with technical knowledge act as a scrum master and cannot help team in any way
100% agree. Scrum is nothing but a tool by management to micromanage developers.
Indeed! “Agile mindset” as such can work. Many people who have worked with systems development have embraced it. But it was always a mindset, guiding the work -never meant as “process fascism” run by a bunch of “Agile coaches” who know nothing about the business nor systems development! These hippies seem to have infested many organisations and are defending the monsterous industry that SCRUM/ Agile Coaching (or maybe it’s “Agile Ca-chiiiing”)has become! Leave the coaching to the experienced devs. and business area owners and go form pot-smoking circles somewhere on a remote island!
Rigid SCRUM has driven developers and tech people further away from the business, with the “Agile coach”-characters wedging themselves in between – in stead of the oposite, which was always seen as something that should happen to a greater extent!
This “Agile coach” nonsense must die in a fire!
Forget Scrum, it’s bad by design, and it cannot be fixed.
It’s a manufacturing management pattern applied to software development, you can only make it work if you completely ignore it.
The only way to do software right is Kanban with feature based milestones. You estimate and re-prioritize every day at standup, do an automatic release when a milestone is reached (which could be from multiple times per week to even multiple times per day). The backlog gets filled continually and re prioritized, the in progress column reflects current work, the ready to test column reflects work done awaiting deployment, the In testing column reflects what’s being tested, and the Done column what has passed testing. This is the basic structure, you prioritize tasks based on product needs not based on task Tetris between sprints, and the release flow is not forced, you release anytime there’s something to release.
Any statement that starts off with “The only way to do software…” is very likely to be wrong. This one isn’t an exception. While I don’t necessarily disagree with your assessment of Scrum, there is no “one-size-fits-all” software development approach. An approach that works for phone apps, websites, or line-of-business apps isn’t necessarily likely to work well for device drivers, operating system kernels, avionics, etc.
Ross, I would agree with you that there is no “one-size-fits-all”, I once shared that opinion strongly. I was so ussed to tailoring processes, adapting, using the right process for the job, etc etc. However no matter what was the process in the beginning, when adjusting it to make it work, we’ve always ended up with Kanban, plain and simple. It’s the only pattern that truly ever fully worked. With all other patterns you’re fighting the software to fill some random boxes, or tick some check-boxes.
It all depends on implemetation of Scrum.
Some of the pain points: https://link.medium.com/EvFkFKsPI7
Nope! It all depends on if you have workers willing to give up professional ethics and be treated like grade school kids by non technical people who think architecture doesn’t matter and are willing to turn out cheap features at the cost of software that will fail.
If you have that then SCRUM works. The software doesn’t but no one cares. We need to kick out all of the non technical people just like every other technical profession. Can you imagine SCRUM at a hospital where a kids with a 2 day certification is harassing doctors to estimate how long each patient will take and track them in a burn down chart? How about a building architect? Scientist? NOPE!!! We would have buildings collapsing, dead patients and we could only solve the problems that the scientists could complete in a 2 week sprint.
Iam facing this right now. Iam being forced to do things I dont agree with by the scrum master
Stop it! If a methodology fails so badly because it is “implemented wrong” *everywhere*, then there’s deffo something inherently rong with the methodology itself and it’s practicallity is reasonably questioned!
This is a difficult subject for me having lived both sides of scrum culture. Just waned to add a little to the author’s assertions and the previous comments:
On the positive side, holding developers to hard due dates is beneficial: missed delivery dates makes life, and profitable business that pays for this life, stressful and difficult for those outside the developer group. When new product introductions keep slipping, those at the pointy end of the stick ( sales) are not given relief on their revenue deliverables, which have these new products baked in. This directly decreases their pay no matter how hard they work, and through no fault of their own.
On the other side is the application of closed-loop control systems to creative work. Daily stand ups increase stress by requiring new additions to the progress discussions every day. Sometimes (often?) break-throughs pop up better in an environment of slack, where people have time to think. Facing a daily standup can cause a stressful sort of tunnel vision and promote group-think.
“Sprints” can also be a misnomer. A Kaisen sprint culture burns people out with sequential sprints in what is really a marathon. The company can keep burning and turning people, but loses a sustainable intellectual base to survive long term.
BINGO! Serving the process is a succinct definition of how Scrum tends to end and it warps everything you do because it is the only thing anyone seems to care about.
It is almost like an absurd religion.
Instead of doing good deeds and helping the sick you are worried about regularly being seen attending church, ensuring that you are bowing deeply enough, being worried about donating enough as the tax receipts and donation totals are public, using a pipe to shove food down a homeless guy’s mouth so you can say that he was well fed before good deeds standup, beating the sick person out of the hospital bed so you can claim they were healed and complete your assigned healing ticket quota and report that more people were healed this sprint than last sprint, etc.
That would be considered an horrible religion. Yet corporate management seems perfectly happy to get that.
Scrum is the belief that devs are factory widget creators and that software is just about piling up enough code to get a working product. Eventually it falls over on itself.
” they will always lose the day to a team that works together instead of next to each other or against each other”
This misses that in a soccer game the goal is quite objective, as are the rewards. As an engineer I generally get nothing if the product itself succeeds. I need management to believe that in the best case I was the cause of it succeeding or if it is failing, that I am not to blame.
Imagine if the soccer game was refereed by a guy who only showed up for 5 minutes out of 90, could arbitrarily declare a goal worth 5 points, and could re-assign your points to someone else. That is called the workplace and the ref is your boss.
My goal as an employee is to maintain my standing with management as that is where all the rewards come from.
Now, I would prefer to win the day, but given the choice between winning the day or defending my standing with management I am going to defend my standing as that is my livelihood.
I have to ask everyone who replies with “that is not Scrum” how is it that everyone can get it so wrong then?
We wouldn’t consider a professor who was brilliant but mistaught 90% of his students due to his inability to explain concepts to be effective. How can Scrum be effective if the majority opinion of those who work in Scrum environments is that it sucks? Isnt the fact that this is consistently done badly (the existence and popularity of this article prove that) evidence of a problem?
Something is going very wrong somewhere and while management can be crappy, it is crappy in many different ways. Yet the complaints about Scrum are fairly consistent.
Posted a full comment below, but as an experienced scrummaster, I firmly believe this is the fault of an industry that creates “certified” scrum masters in a day or two of training. Scrum is actually very difficult to do correctly, and like anything complex, requires serious time and practice before it will be done properly. This means most people really are not doing it correctly. Further, due to scrum’s ability to reveal organizational inefficiencies, the correct implementation is often terminated by management decisions as soon as these appear. And once the process is changed to support management’s goals instead of the software team’s goals, it’s broken.
If SpaceX has this process for launching the rockets and find that 1) the process is very hard to follow and 2) most of time, most of team fail to follow the process.
Shouldn’t SpaceX change the process?
In my experience as a developer over ten years at various organizations, Scrum leads to projects that fail completely in three years. That’s because with Scrum the projects collapse under their technical debt. With Kanban this is slower.
To put it a different way, projects have a debt quota that cannot be exceeded before they collapse. With Scrum this quota is used up very fast. The more control and less pressure the developers have, the more they can institute quality control, refactoring, and rearchitecture, leading to a sustainable project that doesn’t collapse.
For me, coding is a creative process like writing or painting. I need “space” to get into the “flow”.
By having a long list of tasks I have to complete, knowing I’ll be measured by arbritary values that are completely meaningless to me as a developer, I don’t get invigorated or motivated by completing as many checkpoints as possible. I’m not a sales person, I don’t really get motivated by money. I just want to create something beautiful, stable and useful.
Give me a bone to chew, let me chew it, take the code I produce. You get better quality that way, with thought being spent on all the ways it could fail and trying to fix that, limit that, and trying to make it future proof.
Give me checkboxes and you get working code, but hell it will break 19 out of 20 times in the future because some implementation wants to use it but can’t.
Coding isn’t a factory process, where you can just expect production. Coding is a creative process and you need to nurture the creative minds. Because then you get the innovative ideas, the new money makers.
The moment you try to manage coders with targets, achievements and punish them for not meeting them, you get mediocre code. That’s my opinion at least.
Too bad managers don’t understand how context switching is disruptive. And how story points are nonsense.
“3 Elephants In the (Scrum) Room (Part 1)” by Andreja Dulović https://link.medium.com/AG05a4E9z7
Because it is the job of managers to sit around telling others what to do. They have to look busy.
Thanks Michael. This is the one idea I’ve been pushing for years. It is a creative process. Scrum as typically implemented works against this. It does not allow a developer to run with something. It’s like trying to get a bunch of people to paint a Mona Lisa. Never going to happen. Scrum and its originators never understood the artistic, creative side of software development. It de-motivates truly creative individuals, trying to turn them into factory workers.
I’ve been waiting for years for people to wake up to this, and move onto a new development framework. So far Kanban is the best we have.
I agree with Ryan and Catalin.
First of all, I’d like to deny the notation that you can’t have teamwork unless you’re scrum (or Agile in general). My team was working and collaborating just fine before we went Agile. Afterwards, we did not see an increase in productivity. It just introduced more useless meetings. We regularly waste an exorbitant amount of time on this silly meetings, when we could’ve been doing *actual* work.
On top of all that, in case of my company, we hired Agile enforcers, none of which came from a tech background. My scrummaster didn’t even know how to give a presentation on Power Point. The worst was our Agile Coach, which is as dumb as it sounds. Her brain is probably as empty as her schedule is. And she makes 6 figures for just yelling at people who are not following Agile.
All in all, scrum (and Agile in general) is a complete waste of time and money.
As an experienced scrummaster, reading through the comments above makes it clear that most of the people who are saying scrum doesn’t work have never actually been involved in a working scrum implementation lead by someone who actually knows how to work the process. Having to hit targets, having to make deadlines, having managers involved, pitting developers against each other, using velocity as a goal to hit instead of an empirical measurement made post-sprint… these are all signs of bad scrum implementations.
Scrum is not a management tool. Scrum is a process that – if done correctly (and make no mistake it is very hard to do correctly) – creates a fast-moving, experienced team that is able to successfully make good software estimations, deliver working software at every stage of the game, and pivot rapidly in response to business decisions. Nothing else.
It is not a roadmap with inch and milestones. It is not designed to let management keep tabs on workers. If it is used for anything other than helping the team get better at their jobs of building software, it’s not a real scrum implementation.
If done correctly, as a commenter above points out, it actually reveals organizational roadblocks and inefficiencies. This is why it is critical to have buy-in at the highest levels. Because as soon as a higher-up stands in the way and part of the process can’t be followed, or is changed, it almost always destroys the process and makes everyone involved have a really bad time.
Having led many successful (and a couple bad) scrum implementations at universities, financial companies, and software houses, it is my experienced opinion that most scrum implementations are subverted by bad scrum masters or by management that won’t allow the full process. And most people who complain about how scrum is terrible have never actually worked inside the real scrum process. That’s not their fault, it’s the fault of an industry that churns out certified scrum masters with a couple days of training, and a process that seems simple only because so much complexity is hidden within it. And/or the fault of companies that implement scrum as a project management tool for reporting, instead of for creating great software engineering teams.
SCRUM is almost always done wrong. I like the comparison with socialism vs capitalism. Socialism or command economics have killed over 100 million people in the last 100 years. Capitalism has caused a work wide economic boom that raised the quality of life and brought more people out of extreme poverty than anything in the history of the world but it is NOT perfect.
Theoretically, it would be possible to determine the absolute best means of production to meet the exact demands of the people but it is nearly impossible because there are literally billions of variables but if you could even be 90% accurate you could do better than capitalism assuming every single person in t he system is 100% on board.
Much the same way, You expect 100% full adoption by the business who is following a cargo cult and does not even care what a scrum meeting is. You assume completely equal skills in a perfectly balanced professional team that is willing to work under constant pressure when they could work anywhere else and be left alone to code. You expect everyone in this entire chain to agree to quality over quantity. Next you have to account for the loss of paying a SCRUM master and PO and make up for it in productivity.
While in the multiverse theory, it is possible, the “You’re no doing it right” argument has nothing to do with the devs. Since like socialism, it always fails,( and has likely caused a few people to off themselves when it ended their careers ), the argument is worthless unless you are talking to someone that actually controls every one of the variables.
This might be why just about every AG Manifesto author except the ones that sell SCRUM to corporations, hate what it has become and many call it the death of Agile. For starters Some of the biggest names in development like Martin Fowler and Robert “Uncle Bob” Martin.
You assume a lot…One onders if you we’re only one thinking everything ent swell, and by hat measure? Number of collected “scrum points”, perhaps? Listen! I,ve been in all kinds of SCRUM-varieties. The “correct ones” were hugelly WRONG as well… Not doing SCRUM is becoming an attraction and competitive advantage when hiring the best tach. people. It’s time for SCRUM-masters to practice their corn-picking skills, or make sure I get my fast-food fast enough. You can follow THAT up on a “burn down chart” if you like!
What you guys don’t understand (obviously defending their job, especially people who had a 2 day training) is that even if it works for 2% of companies, you still have 98% where it completely sucks. Also you try to push people into a framework or environment most devs don’t want to be in, no matter who you ask. Do you think this is healthy or productive? What about mental load and all that? While all the flaws about scrum have been mentioned over and over and over saying “this isn’t scrum” or “you don’t do it right” or just completely ignoring what people want, what pro’s actually tell you it’s obviously selfish for scrum masters and management.
It isn’t good nor productive. On paper, maybe. The architecture will suffer for sure. No one can see the great picture. Greater complex work is split into pieces, while the truth in code shows otherwise, but this fact is still ignored. There is no creative process anymore, no deep thinking about the complete thing. The most fun thin is also, you as a Scrum Master, tell people what is best and how to do these things while you’re not THE DEVELOPER. You won’t ask the Mortuary Assistant to do architect work for your house do you? If you have teeth pain, do you go to the bakery? What are you guys thinking, seriously?
1-2 days scrum, some months of training it doesn’t matter. You’ll never understand how all this work is done, what process and how it works in the devs head if you’re just a scrum master and not fully into the devs job working on this. It’s simple logic!
In a business environment, business rules supreme. You’re ultimately being paid to develop products with features by a business leader. Most of your points seem to be decrying this as “muh business people don’t understand programming artistry”, yet at the end of the day they’re paying for features to be done, and the quality of the features (bugs, speed, etc) is something that is secondary in most cases. You can argue this doesn’t give the developer to write the “perfect code”, but the business doesn’t want to pay the developer to develop (and learn how to develop) his Citizen Kane. The idea of “features over robust code” is because the BUSINESS is prioritizing features over robust code.
Furthermore the idea of things like “productive individuals who don’t work as a team” is simply a way of saying “people who are good at their job but terrible at communicating”. Scrum is targeted exactly at these individuals. It gives them an interface of expectations for communication, and lets them do whatever they want otherwise. Frameworks like scrum exist because for the most part, engineers are not great at communicating and problem solving. Businesses can’t have their entire digital production as this mystifying black box forever.
OMG, do we work at the same company? 🙂
The company I contracted at went Agile about 3 years ago. And guess what, 90% of the developers have quit mainly because of this.
I think Scrum is a back door, it is a back door for people who cannot code “Hello World” into IT field as “Scrum Masters”, or “Agile Coach”, or whatever title they use.
Sums it up perfectly. My sister in law just took some training and joined as a Product Owner in a company. She never wrote a line of code in her life and is running scrum team.
There are many good points made against SCRUM and I agree with a lot of them. The comment about a developer being looked at like a factory line worker is spot on. To build a new factory line for a new product can take months to build with countless re-engineering work to make it work like the well oiled machine it needs to be to stamp out the same thing over and over. Software development is not that unless you are using cookie cutter technologies like WordPress and other off the shelf CRMs that just require configuration. The work a developer does is equivalent to the workers putting the factory line together and taking specs from the source X ( fill in who is in charge) and generate a finish product, the factory line. No one knows if all of the desired components will work together, how much customization they might need or if the desired result will be achieved until it’s “done”.
In my opinion SCRUM is nothing more than a tool for the bean counters to use to try and find a way to equate percentage of beans paid to the same percentage to work completed/delivered.
One of my many other points against it relates to the concept of point assignment that is used to judge if the work is too large to fit within the defined span of the sprints or needs to be broken down. Who cares, if the customer or management is asking for it you have to assume an ROI has been done on the project and features prior to the start of work and the cost required to implement is known to all parties. You waste more time trying to break things into smaller chunks so the burn down tracks then just doing it as a whole regardless of the time it will take or if the bean counters will be able to account for all of the beans they have paid. And with the concept of breaking things down so you can deliver deployable components is complete hogwash. You are either going to deliver the final feature or you are going to shelve/trash it and move on. You are not going to release the database schema pieces then come back to finish the rest of the feature after another X unrelated features in the same project, it just doesn’t happen. If the points of a requested feature convinces the people in charge to not implement it after a product and feature work has begun signals to me that someone didn’t think it through and will probably results in a complete failure of the product or many of the components will have little or no value to the end consumer.
Well said. Especially the point of splitting big things into small pieces. In which you loose the big picture and context/architecture for the full feature. But you as a dev have to do it that way, and it’s bad.
I’m a little bit surprised by the one-sided comments here. Although I also see many disadvantages of Scrum, I still value the advantages higher compared to other methodologies. Scrum projects are always a little bit shaky at the start, but they improve quickly if you have a good Scrum Master.
The waterfall projects (or V-model (in practiced nobody cared about the difference)) I worked in were all a complete mess. After 6 months of “careful” planning you’ll get contradicting specifications which cannot be implemented in the given technology and you’re not allowed to get the necessary tools (because of budget obviously). So you are told to call up the experts to clarify it. Then you implemented it according to your interpretation of the specifications and people will notice that the specified solution is crap and must be modified. So a change request will flow through the waterfall, and weeks later arrives back at your desk. All the changes and inconsistencies will end in huge technical debt that cannot be fixed, because the development tasks are bulked at the end of the project and there is no more time buffer.
To me Scrum isn’t revolutionary, it’s just a straightforward consequence of the dysfunctional waterfall process. It’s more honest, because it acknowledges people don’t know what they want. Yes, that makes the software developer life less convenient, but on the other side you’re not wasting your time implementing the same feature 5 times (as I did, no kidding) until they made up their mind.
My question to all the haters: What is the alternative? And why do you think that will work in real life?
The alternative is to get non technical people out of the process. Software development was a natural process. Then came the iterative Waterfall process. Wait!!! What !!! iterative? Yep. The author of the waterfall process used an iterative loop but companies did not know it because they simply went off the the first chart of the process. Still it was not a great process. I mean the author came out an clearly said it was not a great process, it was too front loaded and it was very much incomplete but no one listened.
This is what is happening now. The “You’re not doing it right” crowd are the same cargo cult morons who used page 1 of waterfall to STOP and already iterative process.
Robert Martin explains that a lot of the AG Manifesto were techniques that programmers used in the beginning. The agile manifesto was written to help devs get on the same page as what was already working prior to waterfall in hopes they could use an iterative process while communicating it to the business through a common language. Instead, the business side picked it up like they did waterfall and used it like a whip track beat developers down to turn them in to line workers.
Agile is the natural state of coding. It is not a technique or a framework. It is only wisdom and professionalism. SCRUM in is’s best form is anti- agile and in its worst is the fastest way to destroy a company.
“The alternative is to get non technical people out of the process.”
I don’t get your point. How does the development team align with the business needs if they are on their own? Are you working in a startup or a middle- to big-sized company?
At my current project, before we introduced Scrum, people were calling the developers every hour with new tasks and priorities. Now we managed to separate them, so that they can focus on coding. Isn’t is better to have 9 days to focus and 1 day of meetings to avoid context switching?
To me it sounds like you had bad luck with your project managers, that were only focusing on business stakeholders instead of supporting the development team. Just another methodology won’t help you with that.
P.S. I’m happy to switch to any other project management style that solves the practical challenges in a less time-consuming way.
This Orwell quote explains why there is no alternative:
“Orthodoxy means not thinking–not needing to think. Orthodoxy is unconsciousness.”
— And why do you think that will work in real life? —
Because software existed before 1995.
As a product owner who is also a developer, I can say confidently that developers (good ones and poor ones) will complain about ANY process that requires them to be transparent and accurately estimate time. “Scrum” and “Agile” are red herrings here. The name of the process doesn’t matter.
There is this sort of fantasy on the part of the developer that they should be able to just lock themself in a room, put on headphones, and code for 6 months without anyone actually tracking their progress or demonstrating value to stakeholders. All of this, of course, while they are being paid VERY well by the business.
I’ve seen businesses compromise quite a lot over the years with developers in terms of allowing them space and time to do their thing. I think Scrum is a great example of this type of compromise because it gives developers space to collaborate among themselves, and even the ability to CHOOSE which items from the backlog they want to work on! The other side of that compromise, of course, is that the developer has to agree to a timeframe (timebox/sprint) within which to complete the work. It’s a compromise-based system where both the dev and the business must give a little.
Of course, there are businesses who won’t give at all– And they will lose quality developers. On the other hand, there are developers who won’t give at all– And those are the developers who complain about processes that require transparency, accountability, and deadlines for features.
Look… If you want to develop software on your schedule without having to answer to anyone, go start your own business and see if clients will put up with you. Otherwise, grow up and realize that there are ZERO professions on the face of the earth that will pay you well without expecting you to deliver tangible value to a business.
Most places I’ve worked want estimates, but they don’t want anyone to do the work to create real estimates. I’ve worked (once) at a place I needed to produce genuinely accurate estimates. It’s real work that takes up real time, and a business has to be willing to pay for that time for estimates to be worth anything.
You can read more here:
Most businesses want that level of detail and accuracy, but they want such incredibly accurate estimates tossed off in ten seconds each. That doesn’t work.
“I can say confidently that developers (good ones and poor ones) will complain about ANY process that requires them to be transparent and accurately estimate time.”
I will concede this point. Developers working on client projects often forget they are supposed to be working as software engineers, not software scientists so to speak. The traditional labelling of a “computer science degree” is also misleading on this point.
What I question is whether the brittle and substantive overhead involved in scrum is usually the best way to go about tracking and extracting optimal value from an already-expensive team. For a long-term product where the objectives are known, a day and a half lobbed off of substantial work for “ceremonies” and bit-by-bit transfers every fifteen man-days doesn’t add much obvious value, and seems to assume an interchangeability of the personalities involved. Add this to the infantilizing “cutesie” colors and buzz phrases of the sprint reviews and you can understand why so many people just want to “get back to work.”
A good compromies? Oh my.
Think about (ask each other about) why you want estimates in YOUR context (advanced team, simple website, commercial solution, high-risk military/health etc etc)….Do you really want Predictability, or do you crave faster Speed, or initial VALUE earlier, or do you want the team glued better by planning together. Context is King as is Continuou Improvement. I say don’t blame your method/tool/framework/thing! Lean started in 1950s and gave much to Scrum (Agile) especially CI (plan do check act) and on mindset/culture.
Memebers are important, a single “bad” member can ruin everything, no matter what method you use.
Again, we are not factory workers. We are individuals and developing is a creative process. It doesn’t work to push everyone into this religion.
That is a really interesting especially for bringing the different point of views.
I still feel the “Scrum pitfalls” are actually not really Scrum pitfalls… it feels most of the time we blame the tool rather than questioning our environment or our ways of working.
I wrote a post responding to each of the “Scrum pitfalls” mentioned above.
Please let me know what you think about this, always happy to debate in a respectuous way 🙂
Just read your comment then you may want to check my other question about scrum (I am the one who posted this question).
Thank you for such an amazing fact about scrum learning. Actually, I was searching like this post because I am now continuing the scrum coaching from tryScrum & this is really going good. I hope this course can be helpful to build a successful career for me.
My team is struggling with Agile/JIRA/Scrum mandated at my company. My software development peers, under the stress of having everything driven via JIRA, now resort to every request of product owners, users, partners to “engage my scrum master and have him open a story for me and I will look at you question in one of the upcoming trains”. That is what we have had to resort to, because we now no longer have time to do as much research and analysis anymore because we spend so much time in JIRA. And guess what? In our attempt to follow the process, now the scrum master is overwhelmed with the incredible number of request of our users and lines of business. The scum master continues to invite more and more product owners and a number of his peers to our daily scrum calls, even though we have been told there is no room in the budget to fund any more developers. I find my development peers much less approachable by their users and the entire moral of my team is VERY VERY LOW. The scrum master, I am guessing in his effort to just survive, continues on with his own agenda and is not even close to comprehending how disruptive this Agile/JIRA/Scum process is to our development progress. I have shared my concern with my manager but my manager seems to imply that the Scrum manager is now my manager. If I still haven’t convinced you that this isn’t working for my development team consider this: the objective no longer is to build resilient/re-usable/maintainably code and processes…the objective is making sure JIRA is up to date and reflects what each individual is working on, daily. I fear all of our projects are evolving into Boeing 737 Max projects (which ending up being a disaster yet Boeing still claimed that their development process was sound and compliant).
Exactly, a blind horse leading with no technical knowledge. My scrum master doesnt understand our impediments
Whenever I say that agile scrum is garbage, the scrum lovers always say that I was doing it wrong. Whether my former employers were doing it right or wrong, it makes no difference. Simply stated, scrum, or any agile methodology for that matter, cuts corners and omits some of the things that you are supposed to do in order to develop software PROPERLY. Lack of certain documentation is #1 on the list. Massive technical debt and garbage code are also major issues.
Engineers like me want to be given our marching orders, given the project due date, and let loose to do what we do best. None of these daily standup meetings that interrupt us when we’re in the middle of writing a complex algorithm. We are adults, not 12 year old children who can’t be trusted to do the work. Scrum puts the kibosh on our creativity when we have to develop algorithms in specific amounts of time. You would never tell a sculptor that he/she has to produce their work in a certain amount of time, or say that they have up to 1 day to finish the head, two days for the legs, a day for the torso, and two days for the arms. Software engineers are artists. Those of us that were schooled correctly know what comprises properly developed software. Scrum does not facilitate that.
Well said, couldn’t sum it up better than you did. It’s like telling a professional he does his work wrong, while not having any knowledge about that job or work. With this logic, you could also go to your dentist and try to tell him in which and what time he has to finish x and y, while having no clue about it. And in this example, it would be easier than software development…
This scrum stuff is a pure religion, and the people using it will defend it no matter what. Because it’s a good paying job. It doesn’t matter if other things suffer for it…
It kills a developer through burn outside.Non technical people as scrum masters are worst.They dont understand howmuchever u explain
Might be offensive but, most people are not that clever so they “can’t” understand it looks like. Or they don’t WANT to. They created themselves a job, all the time blubbing over “Elon Musk” does it too and earning good money with it, without the hard work of a dev.
As a scrum master, I’d comment on DJClayworth’s comment about scrum master duties “You should prioritize the tasks within the sprint” . The Developers own the work in the sprint, not a scrum master, it’s up to them to reprioritize it on daily basis, for example, during the daily meeting. Thanks for putting this article together!
NOTHING substitutes knowing your collegues and employee with their strengths and weaknesses. There is no shortcut to success. Only to dazzling. NOTHING subsititutes having personal contact and empathy. Tool like scrum blindfold planners, giving them a wrong idea about work. They distract them from realizing that its all about knowing people, honestly documenting what happens, and empathic communication.
Like everything, scrum has a placebo effect. The change of routine and the loaded language (ur not “sprint”ing ur working) will initially spark people to wake up a little and work harder. Overtime old habits whill come back and instead of a the speed up you will have a massive slow down, because instead of working, people will now be busy with discussing the work process and making up tasks.
The placebo effect in business consulting is why naive people keep believing stuff like agil or scrum works. It doesn’t. you might as well give people sugar pills and say they’re speed.
What needs to be done:
Planning by spliting tasks up into subtasks together with developers – writing them down – documenting what is done – trying to evaluate what can be done at what point and what takes how much effort.
All those things are good. You dont need scrum for them. NOT AT ALL.
However no planning of it will ever be completly accurate. Scrum and Agil provide people with that illusion… Its a lie. Things just aren’t plannable unless you know both the task and your team very well. Agil fools ppl. It does so by overloading them with so much extra effort and neologisms, that through confusion and cognitive dissonance people will start WANTING it to work. After all, its hard to admit that u’ve done a lot of effort for nothing.
You don’t need ideologiccal nonsense like scrum or agil for planning. Save time and money and get to know your people instead.
This is fascinating! I’ve never thought about Scrum from this perspective, but some of the issues mentioned here can be really bad for sure. One of my colleagues talked about how Scrum can sometimes go wrong, but he had a different approach. What he had to say was so interesting, it got turned into an article. If you’re curious about this, I think you may enjoy that read, too: https://www.stxnext.com/blog/how-scrum-can-go-wrong-in-large-organizations
This is a textbook case of estrangement. C’mon ya’ll we took the vow of Agile Marriage a couple decades ago, for better or for worse, rrriiiight? It’s a holy matrimony, it’s not like we slept with somebody else’s partner under their own roof with their kids in the next room… or is it? We are all still doing Agile Scrum because we never had the decency to not do it. To even understand what status was or progress was in order to say something about it to the hapless managers. Think about it that way, this is our bed we chose it.
I’m just here to rant because today’s standup sucked. Even the best standups are WORTHLESS.
Everyone’s sharing links, so I might as well too: https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
The title slug pretty much says it all. The author goes into depth on why Agile (and especially Scrum) cause so much trouble for teams that adop^H^H^H^H have it foisted upon them, why Scrum destroys productivity, why it destroys morale, etc. Definitely worth reading for anyone interested in the subject.
And of course, the apologists will always come back and predictably say “this isn’t True Scrum™! You’re just not doing it right. All of you who are complaining are Doing It Wrong™,” just like apologists for any extremist ideology always do. To which the natural response is, if everyone does it wrong, where does the problem truly lie? With everyone who’s ever tried to work within the system, or with the system itself? Because like communism, unit testing, and C++, Scrum really does seem to be universally impossible for people in the real world to consistently do properly, no matter how much effort they put into it.
Easy, YOU ARE DOING IT WRONG!!!!
Software engineers, i mean good sw engineers are results based thinkers. Basically we are problem solvers that just happen to use code to solve problems. Scrum does not work for the simple reason that its all about politics and nano-management It has very little do with actual problem solving if anything it impedes problem solving with all these unnecessary meetings, which are all about optics. Optics are great until the stakeholder wants to actually take a look at the product, that never got done because the engineers were to busy preparing for or being in a whole mess of unnecessary meetings. I hear this a lot- ‘scrum
really works if it’s done properly’, but truth be told if it really works then there should be no need for such a disclaimer. If the process being described is so open to misinterpretation as one might allege, then essentially its broke and needs no defense because that train already left the station…Anyway, if
you have money and time to burn you can become certified ‘scrum master’.
I would like to add that I asked another question about scrum [How do I make agile process more comfortable for introverts?](https://workplace.stackexchange.com/questions/189958/how-do-i-make-agile-process-more-comfortable-for-introverts)