Why Scrum is stressing you out
Rich Hickey put it best.
“What kind of runner can run as fast as they possibly can from the very start of a race? Only someone who runs very short distances. But we’re programmers, we’re smarter than runners. We know how to fix that problem, we just fire the starting pistol every hundred yards, and call it a new sprint!”
I think back to the early 2000's, and there are other factors in play as well. Back then, I worked with a team of engineers that stayed together for over 4 years. In that time, we did not have Project Managers telling us to do daily standups. We met as an engineering team.
We often would go days without having a formal meeting.
But, software was different then as well. Everything is interconnected now. One team dropping the ball affects countless other teams. Deployments were whenever we felt a new one was due or at a multi month cadence. Did this introduce problems, yes, but at the same time, they came in controlled release cycles.
Nothing against CI/CD and continuous delivery, but the hamster wheel has gotten to a point where we have to release all the time. Corners are cut on everything, and testing is given lip service.
At this point, I am a manager, and SCRUM stresses me out. Either let us work from a queue, or give us a project with a deadline. Give me back a stupid gant or pert chart. At least then it was, is this done to allow XYZ, not we are going to accomplish this in the next 2 (arbitrary) weeks.
So much more to say, but I am toast.
I’ve been building software applications for 40 years. No matter how you slice up the work, we all have to demonstrate progress and goal achievement.
Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success.
In a lot of cases there is a client or a customer that requires regular progress reports. Management uses reports to measure team performance.
I’m not sure what planet the OP is from, but this will never change. If you have a small team with a simple codebase, kanban is probably sufficient. In larger teams or complex solutions, the reporting just needs to happen.
Out of the 8 companies I've worked at as a product engineer, the most successful framework to deliver tangible results has been Basecamp's Shape Up approach. Engineering managers always ask "how many days" of effort when the real question they should be asking is "how much appetite"/"how long do we want to spend" on the particular product/feature we want to build? The Shape Up framework was the only time I didn't feel constantly stressed and it actually provided time to cooldown between the six week cycles. And the fact is it actually led to very successful product deliveries consistently. For those interested here's a link to it https://basecamp.com/shapeup/0.3-chapter-01.
What I dislike about SCRUM specifically is that if you're having a rough week at home, recovering from illness or you just have things to do outside of work, you can't really just have an easy week and make up for it later on. It's a kind of constant grind and we always have a way of "filling up" our sprint. If we don't meet our target, it always feels like a fail. I know it shouldn't feel like that but it's human nature.
Maybe having "easy" sprints would work?
There are benefits too, just that constant grind aspect is why I believe it's mostly a temporary endeavor. After 6-12 months most teams seem to just do something else then come back to it once a new manager joins.
We don't do agile, scrum, standups, etc. We meet 1x week to review where we're at and establish/re-establish priorities for the week if needed, use a ticket system for tasks to track progress, a high-level "weekly goals" shared doc, communicate on Slack as needed, and let the devs actually do the f'ing work the way they know best. If someone can't self-manage and produce without a manager over them, or reach out if they've hit a blocker (due to their own limitations or someone else's) they are not the right fit for us.
IMO, if you're a SWE/dev and spending more time doing other stuff (meetings, TPS reports, etc.) than coding (coding includes the time needed to research, experiment and think of good solutions, not just actual coding), then something is wrong.
Back when Scrum was new I already wondered how it could make sense to make developers be constantly sprinting. I mean it's right there in the word choice. You can't sprint all the time! A sprint is short and fast and then you rest. Making everything in work life be only sprints is madness.
As a mechanical engineer I love lurking here because you software folk have a way of classifying and describing a technical workplace that I don't find anywhere else on the web.
I was recently part of a program for ~2 years that was essentially in perpetual sprint mode. We never had time to stop and consider the impact of decisions, because requirements were constantly shifting beneath our feet. All the tasks and sub tasks, and their interrelated nature was haunting my dreams. I would have sudden panicked realizations in that brief window of clarity before bed that I forgot or missed something.
There was always an acknowledgement among all in the (virtual) room during calls that the problem was outside the room, or that "yeah this sucks, but it's the least bad way to run the program" or something like that. The technical problems were interesting to me, but not enough to sustain my motivation through that.
"Sprints, on the other hand, are fake deadlines". Amen. As a result of what I described above, it was hard to take these "deadlines" seriously.
Unfortunately, we aren't understanding the intricacies of high-performance. I've worked with maybe 150 scrum teams. 99% were mediocre. Remaining 1% understood energy usage, how to limit what they took into a sprint backlog, and how to manage their capacity.
When I asked a manager about a particular team, he said "I don't care if they do fight club in the morning, just let them keep doing what they're doing." To reframe, high-performing scrum teams are actually anti-legacy management, they get more done, are happy (low energy state) and stakeholders were satisfied. So their rolling sprint goal was taking a half day each month and going to Top Golf . The key is, everybody on the team was a scrum sme, and understood how to work the process as a team to reinforce certainty and stability. They also didn't need a scrum master.
I've got lots of anecdotes from this couple of teams, what kind of work their managers actually did, and the sneaky ways they made the process work for them. There's a lot more to scrum than a certification. Just the teams approach to sprint planning was in a whole different class from what mediocre teams normally did.
As for the other 99% of teams, they were mostly management tools. Scrum had been co-opted, especially in orgs using the SAFe framework. This has been at F250's in my experience btw.
We have a woman at my company whose job is to update Jira ticket statuses.
Instead of allowing the developers to update the statuses themselves, she will often prematurely update statuses from "In Development" to "Ready for QA" before any code is merged. Or she'll update a ticket that isn't yet being worked on to "In Development". It repeatedly causes a lot of confusion.
I think she feels the need to be so hands on with updating the statuses in order to justify her job, which, in my opinion, shouldn't exist.
I'm at a weird point in my career where every development process stresses me out, no matter what. Guess that's burnout.
> Scrumfall: The Real (and Worse) Picture
This section is very, very accurate. I was at a startup that ran scrum really out of a need to jeep our remote team communicating regularly. Goals were loose and generally defined by each dev doing the work.
That eventually broke down and we had quarterly goals driven by marketing and sprints with rigid, increasingly stressful goals. The difference in developer burnout was plain as day, once scrum ends up overlaid on a quarterly (or similar) waterfall the value of scrum is gone and people burn out fast.
This guy has clearly never worked waterfall, the progress bar doesn't look at all like in the graph. Instead, there are even more milestones throughout the project. Granted, they are usually spread out further than every 2 weeks, there is no such thing as just one final deadline where you can slack the first half of the project.
Month 1: Specifications need to be frozen, because month 2 all the test plans need to written, so that month 3 all the test cases can be implemented. Then month 4 all code should be written and month 5 we put everything together to test it. Hoping that what you wrote down half a year ago is still relevant and the most important thing to work at now. Add a complex web of dependencies to other teams on a gigantic gantt-chart with fixed dates and you will have deliveries regularly anyway.
Usually, by month 2 you are already overdue on the first milestone. The time plan is not going to shift because of it. Meaning you now have even less time to meet the second deadline, obviously it will be missed, repeat throughout the remaining milestones, resulting in constant stress throughout the project.
That's not to say that the graph doesn't exist, its just not called waterfall. It's longer deadlines with more autonomy between.
The forever-sprinting approach indeed is unmanageable long term.
In my prev job we used to have a cycle of 2-3 sprints followed by 1-2 weeks of rest (to handle tech debt etc.)
In other companies it could be named "innovation week" or something similar.
I still didn't love this, precisely due to always wanting tangible deliverables within 1-2 weeks, while sometimes you just need more time to think clearly about some problem.
We partially mitigated it though by explicitly stating whether a giving story is "delivery" or "discovery", the latter being used to better understand the scope of the problem, current status quo, validate assumptions etc.
I refuse to stress about it. If I don’t get the things done in the time allotted by the points, oh well. If I don’t get them done by the end of the sprint, oh well. And, while my manager might bring it up in one-on-ones, I’ve never seen any consequences from not stressing about trying to meet artificial deadlines.
There are several flaws in this article's arguments, but the central one is easily revealed when you ask this question: why is there a big spike in stress for the "waterfall" project?
The answer is that as the deadline nears, the team realizes that they have not made enough progress to meet the deadline. They must work longer hours, start cutting corners, and toss out features at the last minute. All of this is extremely stressful. It's also a cascading problem on bigger projects where this team's product is a subsystem that subsequently has to be integrated into a bigger platform, because they may have broken compatibility at the last minute to make their deadline.
Contrast this with scrum, where the team collaboratively sets goals on a regular basis and regularly monitors the work remaining and the rate at which they are progressing, so that they know early whether they need to start making trade-offs or adding people to the team. As the author notes, this trades peaks of extreme stress for a predictable (and manageable) medium level of stress. But it also ensures a more consistent and panic-free delivery process.
The problem of burnout is a separate issue. Neither scrum nor waterfall offers a solution to burnout---that is up to the team's management. Nothing in scrum prevents a team from taking breaks from sprints, either as a team or individually.
A lot of the criticism here comes from people who had bad experiences with poor managers, leading them to reject the idea of work processes altogether.
The few defending Scrum are doing so based on positive experiences with great teams and strong leadership.
In my view, high-performance teams don’t just appear by "hiring good people and letting them do their thing." Good people naturally communicate, take initiative, prioritize, estimate, provide updates, and mentor less experienced team members. In other words, they often follow a pseudo-process or even suggest routines that resemble a formal process, if one is not already in place.
Alignment, communication, transparency, and prioritization are key to achieving results. Processes should be designed to support these, providing space for creativity and autonomy, including review and constant improvement of the process itself.
One of my soft requirements for engineering roles is "no agile". Usually if a hiring manager tells me that team is an agile one it's a very clear sign that I don't want to work there.
Of course, this pickiness is only if I'm in a situation where I don't need to move. I can think of plenty of cases, for example being laid off, where I'd take a role in a scrum team.
Interesting article and I have observed all of the situation described in it.
I would like to point out that when agile, and even Scrum to some degree, was introduced it was a way for people creating software to take back control of a runaway process that prevented team from doing their best work. It was a grassroots movement championed by people invested in finding better ways to create software that were less stressful and more successful.
Most of the issues in the article were coopted in Scrum to take control of software creating back from the teams. Whatever replaces Scrum, and agile, will need to learn from the mistakes and compromises of Scrum or it will suffer the same fate as Scrum and become a tool to force teams into a delivery model that gives managers and executives more control while reducing their accountability.
We moved from sprints back to work queues for exactly this reason. Output is exactly the same but no one is cutting corners to "finish" the sprint. We still use a kanban and do estimation the same exact way, but rather than arbitrary deadlines, devs are trained and encouraged to communicate on their velocity in a way that is far more effective than a daily standup.
Scrum was an idea that had its time, but after like...15 years the limitations are apparent.
People like to forget a thing: Kanban, which is the scrum "ancestor", was designed for FACTORY MASS PRODUCTION of already designed parts, not for designing new ones, on other words it's a system that works only if what you do is pre-defined, does not demand much intellectual, creative activities and anything it's well known in advance.
Applying it to creative activities is a classic application of a religion to a society blindly believing it's universal. It's not. That's the substantial stress.
The secret purpose of Scrum is to get rid of managers and empower the engineering team. Most "scrum" is simply taught wrong because it was sold to companies as a way to squeeze workers.
One of my favorite moments was when my non-developer friend at a tech company asked me what scrum masters did because she could not figure out what the scrum masters did at her company. I told her the answer which is nothing.
Ive mainly work at startups and as a consultant/sub-contractor and have encountered many implementations of agile and waterfall. One place I consult for, and this is not a defense of agile just an observation of some good in what this shop is trying to do, well this place handles sprints as "multi-week" (defined by the team up front, weighing factors like; are we blocked by client, complexity, etc). The projects are still more or less waterfall with a client deadline at the end (They are mostly fixed scope/budget after all), and the only sprint deadlines are periodic client demos that have no expectations (progress check ins, see what we did, yay). The teams here only seem stressed in the old sense, right before the end. They often joke and call it agilefall, with the agile part intended to force teams to share progress and collect progressive feedback. As well as hold other internal meetings like sprint plannings (really just team checkins, are we blocked? should we start this vs that, have we learned something, etc) and retros (also just checkins, how we feeling? are people butting heads, etc). My biggest gripe with them is that no one takes responsibility for any form of ticket management and it can be chaotic knowing who is actually doing what day to day, requiring too many stand-ups and slack messages. They try to map tickets to scope up front but no one moves them along and they usually just follow the estimate document... since all the subs are global and remote it would be awesome to just check a board each day and dive into work instead of everyone needing and hour at the ass crack of dawn, during dinner, or at bed time, their local time...
Again, not saying this is my recommendation, but its definitely not some feature-mill, even tho we are literally a feature-mill as a fixed scope/fixes budget consulting shop, lol... not the most interesting work, but pays well, low stress, and if I heads down and get it done, I get tons of free time to do my own thing.
What does “sprints are involuntary” mean?
My team chooses the characteristics of the sprint. It’s not like they are randomly assigned. It’s a collaboration between leadership, team members and non-team stakeholders. It’s not like there’s anything mandatory, so we set our release schedule and what a release means based on what makes sense.
What’s the alternative proposed?
I wonder how the author is working if they think that these things are involuntary. It seems like their environment sucks and it’s expressed through saying scrum sucks. Scrum is so generic it can be adapted for many needs. I’d like to see the author explain why their scrum is so rigid. Does he suck at estimating? Suck at communicating? Lacks resources? Leadership is poor at estimating? Who knows, but it seems like blaming scrum is like blaming software development in general and more of a “this job would be great if it wasn’t for the customers” type screaming into the void.
Daily standups are horrendous. I don't know how people put up with that level of time wastage and micromanagement.
Every post about "Scrum sucks" has comments about how you are doing agile wrong. I don't see any yet so as the devil's advocate:
You're supposed to have autonomous teams who put up their own tasks they want to complete in the sprint, and the sprint length can be more than 2 weeks if the team wants. And if it's tight to get the scrum's tasks done, that's supposed to be feedback to you and the team. You have autonomy in setting sprint goals, you can put less stuff on a sprint so you have the slack you're supposed to between sprints. Or spend more effort refining so you don't get surprises so often. (Or otherwise change things up in how you work)
If you don't have the autonomy and the continuous improvement in your work culture, it's not agile. Scrum is for agile and it doesn't work otherwise. If you do have autonomy you can switch to something else from scrum if you want.
Same goes for the "scrumfall" part of course but that's admitted in the text already.
(I do think scrum is overengineered for agile ideals, has failure modes like in the post, and in 95% of cases you should do something lighter than scrum)
When agile first started it was developer centric and brought in the ideas of continuous improvement, inspect and adapt, eliminating waste (handoffs, extra communication etc). One of the core ideas was to look at what was working/not working - if it's not working you drop it. Then we got the scrum cult. Ironically it has led to a huge amount of wasted time and effort, as well as stressed devs. In a lot of cases these extra processes get added by well meaning people who don't look at the whole system of work. If you can't drop what is not working then it's not agile.
Scrum can be stressful but as the graph rightly shows peak stress for Waterfall is way higher. I've been working more than a decade with Scrum. Every time I don't it shows, lower productivity, even higher stress, bogus tasks. If people want to do Waterfall fine, but then please also have proper project management with Gantt charts. Otherwise it's just Cowboy development
Ill say that for me and my team, implementing SCRUM has worked well and overall reduced stress.
We have a lot of control about what we pull in and the issues in out backlog, and if we need to designate prep work, we put it in as a spike.
The only time i really have work stress is when we have to many interrupts, but SCRUM has a process for buffering for that and I find that very effective for telling the story when that happens.
So it sounds like I am a SCRUM fan, and I am, but i would def be open to hear about other systems that teams use who have tried SCRUM and prefer their new solution.
Love this. I’ve had anxiety about agile and how I’ve never seen it work well, and the “before days” was in some of the most enjoyable and productive projects until agile came along
I feel like in a lot places the ultimate purpose of sprints is to let executives think they can see data that represents the amount of work getting done down to a fine level.
nobody has ever done "waterfall", it's a strawman created to explain why traditional project management doesn't work in software development. The fact that the article starts with "in the good old days of waterfall" takes away every expectation that I'll read anything intelligent in the article, I believe this post doesn't deserve your time and definitely doesn't deserve mine.
This article hit really hard. I’m super stressed with my team’s cadence right now. I often think about what’s pathological in modern-corporate-scaled-agile-abominations and this really hits the nail on the head, but I think for me the main complaint is that if you can only see two weeks into the future, planning can become very difficult.
I also often think of how our scrum process makes me feel like I’m back in grade school doing little busywork projects like coloring a hand-outline turkey or whatever. I really kind of think that’s the point. It’s for people who never escaped the schoolchild mindset. No doubt it works wonderfully well for them. It doesn’t work very well for me.
While I think the part about neglecting support became true at my org, I didn't forget how awesome E V E R Y O N E felt about Scrum when we started. It lasted for 1-2 years. All the devs and everyone loved it. So... then why?
Because it brought a kind of order to the game. Story points worked. They became boring so the teams started to twist them.
I think Scrum loses its advantage when people get bored - like with any other "process".
Great description on what happens especially in scaled organizations, where sprints/iterations are supposed to be in-sync across departments (so you can align interdisciplinary tasks etc.).
In most cases I've seen, it basically introduces an additional company-internal clock with tick-tocks for a custom frame of days and weeks.
Everyone acts like this is more consistent and somewhat abstracted from "real-world" time, but in reality it's just two other hands on the same clock, with pressure and tasks still increasing close to "real-world" clock-events (launch-dates, exhibitions, customer-events,...)
I'm not a engineer but I can't believe engineers took the scrum/agile workstyle and adopted it like that. Why didn't they vote with their feet?
It's almost inhumane; sprints are those 10-20 seconds you run in a 100m 200m dash. Marathon is how you run faster. So, forcing people to do repeated sprints is for me, bad for your health, without exaggerating.
This was evident fron the beginning. The mystery to me is why was this adopted as the default way of working?
Normalize 3 week sprints. Enables the team to do what they need to do. Less planning overhead. Enables the product manager to be more forward-looking and spend more time focused on customers/ market research.
Agile/Scrum and all forms of project management is a scam you should work in layers serving layer above, have wbs and tasks assigned out of it in your layer, justifying urgency by impact on business/users, reward people who accept and close most tasks by appreciation and break. And fire anyone who misbehaves.
Kind of off topic, but when articles have a “conclusion” section nowadays it just screams chatgpt to me, even if chatgpt wasn’t involved at all.
I wonder what the tech blog meta will shape up to be in a couple years.
I'm getting performance measured based on number of tickets completed and number of PRs merged per quarter.
There's truth to the ScrumFall design process which is inevitable for most development processes. It's not just that a tool needs to be marketed, but that it needs to be integrated with work from multiple teams and other processes. What ScrumFall does is provide some level of feedback prior to delivery. In the age of Waterfall, devs would develop until they said they were done, we'd get to delivery and UAT only to find that key features work differently than expected and continually extend the release date by months or years until it finally goes out the door more from frustration than actual completion. That stress level would be pegged at 10 for months until it was completed.
I learned scrum back in college and I hated it so much. I remember we had to meet 2-3 times a weak. And for each meeting we had to present something, with slides as well. We spend more time thinking about usercase than writing the code. I guess that's good in its own way but honestly I don't have such superpower to report something new every meeting. In fact most of my meeting back then were "I am still coding X" and that was it, then the scrum master or the leader would talk about big picture over again.
One hill I will utterly die on: Many people (including some in these comments) are fully able and happy to go their entire career mistaking high performing individuals with a high performing work framework.
In my experience, Agile methods give power to non-developers which can be a good thing or bad thing depending on the workplace and the individual behavior or perspective of participants.
> The business side just can’t help itself. ("We have to market things!" "We need to inform customers about what's coming!" "We have to make promises at conventions!" "That's just the reality!")
Then shortly after:
> Treat [developers] as respected peers, not replaceable cogs in a machine.
Yes, it’s hard to know understand the (oft-maligned) “Business Side” doesn’t bow and genuflect when they enter a room full of programmers.
Hmm I think 95% of the conversation in this thread can be summarized as:
Person 1: Scrum sucks at my job because X, Y, Z.
Person 2: That's not the ideal spherical cow! Sorry, it's not "real scrum".
Once upon a time, ivory tower "programmers" met in a cafe or something and grandiosely produced a manifesto called Agile and unleashed merry hell for poor souls who just want to produce something that works. Instead they must listen to managers who haven't written so much as "hello world", tell them how it should be done. I don't care of the intentions, it has been coopted into corporate micromanagement and busy work for deadwood corporate lifers. Enough, the original authors need to get back in that cafe and explain where it went wrong.
I was less stressed when doing scrum. When a new VP came in and tossed it out, he didn’t replace it with anything. The void has been filled with chaos, where our priorities change based on who the last person to speak was. I’ll take scrum over chaos any day.
Every fucking day our boss gives us a motivational talk, every fucking day i have to see his face for over an hour, every day he says over and over we must do 14 points daily of tasks cards or whatever name You use, whats 1 point? 30 minutes. Yes, so all of us are adjusting our work so he's satisfied, i hate my job, i don't want to develop anything,i need the holidays law offers me. Everyone must do a video at the end of the week, every single day i have to write what i did right, wrong and what could i do better. I hope some day this madness stop but i'm not counting on it. Whrn My daighters finish their studies i Will quit this sad madness and do anything else, maybe selling bread, coca cola, fruits, i dont know. I had code review that turns out to be for all of us, do it again the way i like it, so every single tasks had to bee done twice and please don't make me remember clean code, 10 classes 20 functions to iterate an array and send a post request becausr someday it could ve reused... I hate this, wrong carreer. EOL
When challenged why we'd scrum since we were doing better as a whole before (better products, happier devs), mgt replies that they'd need scrum to detail the work we did so that they could write longer bills to the clients.
there has never been a conclusive study about the actual usefulness of those things, the agile, the scrum, etc.
as such, it's more akin to something like litho therapy or astrology, that is what's stressing me out
We all know these problems.
What's the solution?
It seems like HN has gotten one of these posts every month or two for as long as I've been reading it (about 15 years now). They always make me some combination of sad and angry, because they almost always misdiagnose the issue.
Process isn't the enemy. The various named and defined processes are just tools. It's all in how the tool is applied. And while this post wrongly blames a process, it does get one thing right:
> If a development team were to sit down and decide to deliver code every two weeks, based on a process of their own design—one that made sense to them and suited their circumstances—that would be one thing. [...] Autonomy—the ability to direct one’s own work—plays a significant role in how work is experienced.
The development team (which ideally includes design and product as equal members) should be deciding its own process collectively and with a high degree of autonomy. Scrum, Kanban, Scrumban, Waterfall, "no process", these are just the defined and tested tools we select from in deciding our processes. We can mix and match them, draw from them as needed, or throw them out and try something new.
But we as a development team should be deciding, together, what process to adopt in order to achieve the businesses goals with the resources and time as best we can without burning ourselves out.
---
I was a full stack IC for 10 years and an engineering manager for 5 years.
I've done more or less all the processes. I'm currently back to being an IC in an org where Product dictates exactly the sprintless "no-process" this post is advocating and it is every bit as stressful and bad as he's claiming sprints are.
The best team I've been on was one where we had full control of our process. We started with scrum-like month long sprints, of which the first week was planning week where we did deep dives on our stories, wrote them up and ended the week with the scrum planning ceremony and agile pointing. We used an "ideal day" as a point to give our estimates some level of concreteness, but largely stuck to our recorded velocity. And you know what? It worked! We got surprisingly good at estimating and, while we were never perfect, if we overran our sprints it often wasn't by much.
Planning week was definitely rough, and we eventually chose to ditch it in favor of two week sprints with planning stories worked into the sprint as needed. That worked really well too (and I think that's my preferred process).
But the point was, we choose these processes. We ran these processes. Our retros were vibrant and highly critical discussions where we asked ourselves every sprint what was and wasn't working and made changes.
When I became a manager, I carried this forward on my teams. We iterated through the two week sprints with planning SPIKES, to continuous flow kanban, and back to two week sprints with planning SPIKES. When I became a manager of managers each of the teams in my org choose its own process. One stuck with the scrum-link, one adopted kanban, and one (the smallest) decided to throw it all out and go with "no process". Each made their respective process work. Each had different challenges, because no process is perfect. Each continued to iterate on their respective processes. And I worked with the leads - the manager and staff engineer of each team - to form the cross team processes and communication to ensure that each of these autonomous teams could still collaborate.
Process is not the enemy. Process is just the structure of our collaboration.
It becomes bureaucracy only when someone else is dictating that structure and preventing us from structuring our collaborations in the ways that best work for us.
>With sprints, there are no breaks, little autonomy, and insufficient time to prepare.
That's the TLDR and on the dot.
are there places today that don't do some variation of scrum today? Waterfall is pretty much non-existent.
SCRUM is mostly self-serving abomination
Having read Sapolsky’s stuff (firm recommendation for ‘Why Zebras Don’t Get Ulcers’), I’m under the impression that trying to eliminate chronic stress is of paramount importance for one’s health.
Nowadays I’m an entrepreneur which isn’t stress free, but I feel like the bouts are more acute and chronically I feel quite liberated due to having control over everything.
I know this will vary by person. Some would dread having so many moving parts in their life, but I always found being bossed around to be the most draining part of work.
Scrum is useless.
it's just another method of demanding results. Where there isn't anything to tell, you shouldn't be forced to do so. All this imbecility does is to create competition, and weed out the ones that don't comply.
I've worked in teams where we were forced to have something to report even when nothing was to report. This made the team create "things" to match their daily scrums, because the truth might get you fired..
Those that actually do work, have nothing to say in these scrums. It's a fact.
Intellectual work is never measured.
Do Agile without Scrum.
I think what people really want is not agile, not waterfall, just to do it in a way that feels natural. No framework. Pretty case-by-case. How I imagine Lao Tzu would have it. Roll your eyes but it's true though.
Agile/scrum isn't a good model under any circumstance, because, as mentioned many times at this point in many posts:
- It leads to burnout because engineers are incentivized to shorten their estimates as much as possible, so as to not look unproductive, only to eventually run into a roadblock, which is typical in any sort of engineering discipline. And maybe the managers made promises to other people based on these estimates, and that, even if you communicated the estimates weren't very accurate, they still relied on when they discussed things in their meetings, and now there's a whole lot of tension and stress for everyone.
- It pits the team against each other, because Bob wants to shine, which puts pressure on everyone else to shorten their estimates, or a tit for tat where Steve would then try to cast shadow on Bob and ask them why they estimated a ticket that Steve has better domain knowledge on, to be 3 days instead of 1 day, etc. In practice, companies work a lot better when everyone works together, not when colleagues try to pull the rug from under their own teammates. Or the workers secretly collude together to pad their estimates so that they have all this free time, at the expense of the company.
- It leads to managers micromanaging the team, and even if they're aware of the problem and try to avoid it, it'll still inevitably happen because the process and scrum are designed in such a way to lead to that sort of dynamic.
I think the industry can do a whole lot better. I have two alternative models, one that I definitely know works because I worked in that kind of environment, and the other one theoretically should work after tweaking it (I think):
1. The Polite Society Model (aka butts in seats)
- Open office
- Everyone gets assigned a task either by the PM or pulls something out of the backlog of a kanban board
- The manager knows that everyone on the team is working, since the manager can easily see that's the case since it's an open office. So if Bob is slower than Mary but faster than Lucy, and any nuance where any worker might be slower or faster on some task because of their background and individual variation, is just how it is, and is self-evident
- Once someone is done with a task, they report to the PM, and if all is well, they get assigned a new task
- No deadlines and no micromanagement necessary. Things get done when they get done. The PM might ask about a larger project that spans into more weeks or months, but this is polite society and an open office, so it's not going to be about grilling Bob on a task or anything like that, and more about prioritization. Ideally, the manager would have a developer/engineer background, and would split up a larger task into many smaller tasks, and would communicate their own estimate to other managers or investors for how long they think Bob would take to finish it, based on how he's making progress on the smaller tasks and his historical performance, making it so that there's no need to pressure Bob to give an estimate, or to micromanage Bob on progress
2. The Captain's Log (aka blinding for remote teams)
- Each developer adds their own private estimates to tickets in a kanban prioritization board. Estimates are always a range from best-case to worst-case, with a wider range communicating uncertainty. The PM can see these estimates from each dev, and prioritizes the queue periodically, once a week or two, on their own, since they're the ones that are ultimately concerned about what product features the team should work on, not the engineers. Bob might estimate a ticket more or less than Mary does, based on their own perceptions, their own productivity speed, domain knowledge, etc. Blinding also should make it clearer to the PM that there's a wide range of uncertainty in some tickets, if there's a wide range in estimates for it, which would be harder to do under scrum, where time needed would more likely get underestimated. Especially for longer tickets that can't fit in a sprint block. Also nobody knows which tickets they'll end up picking up since everyone just picks up from the top of the backlog and prioritization can theoretically change each week by the PM. Devs also should update their estimates periodically if it changed after they learned more about the problem, keeping a log of the older previous estimates that were made as well to get a better sense of the problem domain
- Each developer periodically privately logs their progress on tickets, blockers, setbacks, etc, like a captain's log, maybe once a week or two, or sooner if issues arise sooner. As soon as there's a blocker, developers need to reach out to whoever they need to for unblocking a ticket. Again, managers and PM can see the captain's log for each dev, and they don't need to "check in", which can feel like micromanagement in a lot of cases, since devs are regularly logging everything. If the log is signaling that a dev is getting bogged down or stuck with something, the manager can reach out and follow up on that, ask more about the situation, etc. Devs can only share a non-timestamped version of their logs to other devs that are working on similar or related tickets, so that the focus is more on challenges that were encountered, rather than the time it took to finish the ticket
- The team can still meet up periodically to informally chat about random stuff, for social cohesion, like a wrap up on friday where everyone asks about what they have planned for the weekend, or monday morning where everyone can ask what people did on the weekend, all non-work related
- Devs don't know other devs estimates, so devs are more focused on working together rather than some sort of pressure where they're pitted against each other when they should be working together. Bob might be the most productive person on the team, but he still needs to get along with everyone else, and Mary might have more domain knowledge and work better for a particular task than Bob, etc.
All you need to create quality software is:
1. A continuously updated priority list. 2. A good team that work on tasks in strict priority order. 3. Automatic tests that stress tests the API of whatever you are developing. 4. No BS.
Every now and then I enjoy the opportunity to build things without planning around them. No ceremony, no tickets - just pure code and building things people are interested in or are looking to solve problems.
This article has Scrum all wrong.
What they're talking about is a process that someone is calling Scrum, but is nothing of the sort.
A real Scrum process can be modified at any time to make it more workable/manageable/realistic. The Sprint Review is FOR modifying the process.
If Sprints seem to be never ending-stress, then you're self-selecting too much work for a Sprint. Yes, self-selecting. In real Scrum, everyone chooses what tasks they agree to get done in the next Sprint. You set your own pace, and it's meant to be sustainable and constant, unlike the pace in Waterfall work.
"Every aspect of a sprint is prescribed: its duration, its meetings, its tasks, and even the roles of its participants" -- yes, and prescribed by who? THE SPRINT TEAM! The people doing the work. You.
"Autonomy—the ability to direct one’s own work—plays a significant role in how work is experienced." -- the article stated this as an argument for NOT using Scrum, but that's exactly what Scrum is meant to provide you with.
"In Scrum, programmers are like those mice subjected to involuntary effort, forced to run on treadmills of our bosses' making" -- In Scrum, you don't have a boss. Your team has members, and everyone who's part of the team does real actual work in the Sprint. Yes, you have a Scrum Master, but their entire job isn't to track your hours, or force you to commit to something -- it's to run the Sprint meetings, solve your problems, and anything preventing you from getting the work you committed to for the Sprint, done by the end of the Sprint. That's it and that's all.
"Sprints Neglect Key Supporting Activities" - Really? That's weird, because the team working in the Sprint can specify what needs to be part of every task in the Sprint.
"There's no time is set aside for proper engineering prep work." -- Scrum is about constantly delivering value to the client. If you need to figure out the best way to do something, and can't manage to produce any working code while you do that (doubtful) then you can at least say you'll provide the client with a Report on your findings, and why you're going to proceed with Route A over Route B. And as I said before, if there's no provision for that, make one! or do it in Sprint Planning. If you're part of the Sprint Team, you're in control of your process, and if it's not working, it's your fault, and your responsibility to help fix it. Maybe if someone normally does 20 points of work per Sprint, but they need to plan a lot this Sprint, then if the Sprint Team is ok with them delivering only 10 points of client-facing working code, but also 10 points of valuable research, then that's ok! You can also do a lot of this planning (at least at a basic level) during Discovery with the Client, even if the Client is internal.
"There’s always a Waterfall-like, big-bang deadline quietly lurking in the background" -- You have been betrayed by all of the companies you've ever worked at who said they were doing Scrum, because they weren't. They were doing "sprint until you die", which isn't an actual process, but is how a lot of places work.
"The business side just can’t help itself" -- your Scrum Master needs to go to bat for you. The Business Side should only be told about features that have been completed, or are about to be completed, not about upcoming features except to say that "It's on our roadmap, but I can't tell you for when".
"With sprints, there are no breaks, little autonomy, and insufficient time to prepare." -- True (but the pace is self-managed to be sustainable), False (Scrum is all about autonomy), & False, as stated above.
"Let developers control both their craft and their process. Treat them as respected peers, not replaceable cogs in a machine." -- Did your Scrum team miss the memo about the people that comprise the team is a crucial aspect of the team? A Scrum team should be 100% self-contained, and be comprised of all the people it needs to be able to get the job done. This means from architecture, to UX/UI, to coding, and design." -- If you don't think the unique individuals on the team matter, you're dead wrong.
"Achieving these conditions will likely require grassroots efforts" -- yes, and that's how Scrum came about! It's literally solving what you're complaining about... except that companies have misused its name and implemented it so incorrectly that you now think it's the problem not the solution. How did this happen? Developers found out that Agile and Scrum were amazing. They were a much better way of working, that was sustainable, and fulfilling, and dare I say fun. They started quitting places that didn't do Agile or Scrum, and only applying to places that did. Shitty companies couldn't hire any good developers, so they started saying they "Do Agile". They started getting applications again. Only problem was, they already had a corporate infrastructure that didn't support Agile or Scrum, so you'd start noticing little things like "Hey, why is my Scrum Master asking me how many hours I've spent on a task instead of asking me what they can do to get barriers out of my way?" -- and this went on until the Agile and Scrum that companies professed to be practicing didn't resemble actual Scrum in the least. It was a bait and switch.
Scrum is a process designed to help you continuously improve your own process, while always delivering value to the Customer along the way. That's it. Dead simple.
Here's Scrum in a Nutshell:
Sprint Planning: Make sure everything in the Product Backlog has estimations attached. If not, estimate them now. Make sure you know your own personal velocity. Then each person answers: What work can each of us realistically commit to have done, for sure, by the end of this Sprint?
Daily Standup: (Each person answers) What did you finish since the last standup? What will you finish before the next one? Is there anything slowing you down?
Sprint Retrospective: (Present to Client) We finished all of the work for the Sprint. We will now demo it for you. [demo it] How do you like it? Any feedback? Do you like the list of tasks we have scheduled for the next Sprint, or would you like to reprioritize it? Thanks, see you at the next Sprint Retrospective meeting.
Sprint Review: (Team Meeting) What do you think went well? What do you think could have gone better? How do we want to change our process to reflect these?
When managing a project scrum I stick to a few things that have worked well for me.
- Make it clear that the name "sprint" is a bad one. This is marathon. Encourage maintaining a steady pace and do not become a party to burn-out.
- Use Agile pointing methodology by the book.
- Standups are for communicating wins and blockers; your overall general status is not useful to the rest of the team and makes the standup go long. Project chit-chat, problem-solving, and talking about wins, is for afterwords or completely different meetings.
- Defend the team from management's attempt to deconstruct points into hours, days, or any other more conventional metric; Agile exists to neuter these anti-patterns, and the points exist only to figure out what gets done in a "sprint" interval. Offer velocity tracking and focus on results instead.
- Defend the plan and the team from all stakeholder asks, and make it clear that adding to an existing plan also means taking other tasks away.
- Carefully triage emergencies, bugs, into the plan with stakeholder consent and involvement.
- In fact, everything for Scrum is just triage, including features. Mark everything with a relative priority, even the normal things.
- Celebrate every single last win, no matter how small. There are no victory ceremonies in the standard Agile Scrum playbook; this is on project leadership to address and absolutely must be done without fail.
If done well, the project says on a relatively even keel for the duration. Using Agile for evil, by instilling a false sense of urgency every two weeks, will burn your team out faster than any Waterfall crunch ever could.
Here's where people get this all screwed up: Agile methodology requires constant communication between the team and stakeholders, leaving the PM/Lead to play goalie for the project's run. That leader must be comfortable saying "no" to anyone/everyone, manage stakeholder expectations at regular intervals, and must have a keen sense of how to break down a project's deliverables into achievable increments. In short: this person must be both technically and socially adept.
If that doesn't sound like your lead or organization, Waterfall may be a better move. It pushes a lot of this communication and negotiation to the planning phase, before any engineering work is done. In the case of contracting, it also escalates project change to a legal process, which can blunt/halt the influence of meddlesome forces. It's also possible to avoid big crunches and burnout, if (and only if) your project management has a clue and is dogged about milestone due dates. Overall, it pushes the bigger social aspects to a preparatory phase which can be executed by different personnel than the team that implements the product.
On a related topic: Why reading discussions about Scrum is stressing me out.
Unlike most people here, I have read the Scrum Guide https://scrumguides.org/scrum-guide.html and I actually worked in a team that did Scrum almost by the textbook. And it was a great experience! But then higher management decided that the entire company needs to switch to "Scrum", so we were told to stop doing what we did, and switch to the corporate version of "Scrum"... which was exactly the kind of experience most of you are complaining about. (Then, gradually, the disappointed developers quit.)
The sad truth is that managers do what managers want to do. They may be happy to adopt a new buzzword, but they will keep doing the same old thing. Anyone who says "agile is great but scrum sucks", please realize that it's merely because managers decided that "scrum" will be their favorite buzzword. If tomorrow they decide that "agile" is their favorite buzzword, soon HN will be full of people saying "agile sucks". You should be happy that "agile" is not a popular buzzword, because it means you still have something to dream about.
In other words, it is not the fault of the Scrum process being somehow incorrectly designed. It is the fact that the design does not matter in practice, because almost no one is going to follow it anyway! It's the same thing as with ISO 9001 -- most companies have the certificate, but when you actually read the standard, you will find out that it does not resemble what actually happens in your company at all. You can't fight against people who decide to use the name of your idea, but ignore the content; which is the standard thing that happens in companies.
If I was a manager, I would probably be happy when people say "Scrum sucks", because it means they are looking in a wrong direction. It's the way how companies are managed that sucks. Scrum or no scrum; agile or no agile; ISO or no ISO; the buzzword or a different buzzword... it's still the same thing, we are just pretending that it is something else than it was yesterday.
Back to the article:
> There is no time to breathe, no time to collect yourself.
First, let me ask you: who decides how much work you should do in a sprint? Because if that person is you, they you only have yourself to blame if as a result you have no time to breathe, and you keep making the same mistake over and over again. Why don't you discuss this at the retrospective?
Ah, let me guess. It's the management who decides how much you should do, and when are the deadlines. But they generously let you choose whether you do A in the first sprint and B in the second one, or the other way round. Or they let you do the cute game of poker planning or whatever, and then say: anyway, you must have all of this ready by the end of the month.
Also, let me guess: you probably have no retrospective, because those are just a waste of time. No one is going to listen to your feedback anyway, so what's the point?
> If a development team were to sit down and decide to deliver code every two weeks, based on a process of their own design
Okay, let me stop you right in the middle of the sentence: it's not supposed to be two weeks! Two weeks are for beginners; for an experienced team, three weeks are generally recommended, but anyway that is a thing that the team should decide during the retrospective! Which you probably don't have, because no one is going to let you decide anything about the way you work.
This may seem like an unimportant detail, but it's a red flag. If the management tells you it has to be two weeks no matter what, you don't really need more evidence that their "Scrum" has very little in common with the Scrum according to the textbook.
> Every aspect of a sprint is prescribed: its duration, its meetings, its tasks, and even the roles of its participants.
Yes. Specifically, the meetings are prescribed to be short. And the managers... wait, there are actually no managers in Scrum. And no, it's not because they were renamed to "Scrum masters" and "Product owners" and whatever. Those are completely different roles. The product owner should actually be someone from the customer's company. And the Scrum master is not supposed to be your boss.
So, yeah. Every aspect is prescribed... and then ignored regardless.
> This happens because no time is set aside for proper engineering prep work. There's far more to a task than simply typing out a solution.
Exactly. So why don't you put the prep work as a task in your sprint?
Ah, let me guess: your manager said no. So much for self-organizing.
> The only remedy is to restore autonomy and professionalism to software development.
Ah yes. If only there was some system that would say "no more managers; the developers decide for themselves how long the tasks are going to take; the meetings should be 5 minutes at most; and every few weeks the developers will reflect on whether they are happy with the rules, and will adjust them if needed". If only.
I am sure your manager would allow you to do so. As opposed to e.g. using the name of your system as a buzzword, and saying "yes, we will do it... but we will do it my way: the managers will stay, you will be told what to do and how long should it take, the meetings will remain long, and the company is not really interested in your feedback. But we really like the name you invented for your system, so from now on our company will be using it officially. If someone later complains on Hacker News, we will tell them it was all your idea."
Ok, hot takes incoming:
* Some of the article and commentary here read to me like Scrum is being equated with bad management, or a bad relationship with management. If the source of stress boils down to unrealistic deadlines and high workloads, then that problem will persist with a kanban process, or extreme programming, or "yolo free for all".
* A relationship is a two-way street. Yes its certainly possible that your manager is a dickhead, or incompetent, or both - but it is also possible that they don't know how unrealistic their expectations are because you have failed to PUSH BACK properly. A healthy relationship includes saying no, and explaining problems - that is part of a developers job.
* So many developers (my younger self included) WILDLY overestimate their ability to communicate effectively with non-tech people. The idea that you are going to go from having a bad management relationship, to talking to the business directly is... lets say "misguided". I'm still pretty bad at it, but at least I know that I'm lacking here - I'm very thankful for the people who are well versed in stakeholder management (which really is a skill).
I've learned to hate software process. If you have team sizes set sanely and empower devs to do what they need to do in order to accomplish the goal, they'll be fine without the management overhead of arbitrarily imposed productivity flow. Agile et al, along with 99% of the features in ticketing systems, exist to make managers feel like they are justifying their paycheck.
If you are a manager and this makes you angry, you're one of the bad ones.