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.
All of these methodologies (and most formal software architectures as well) have as a their main sales pitch the idea that you can hire average/entry-level developers and build good software with reduced defects and on a defined schedule if you only follow these magic guidelines.
It refuses to learn from The Mythical Man-Month and recognize that building software has an essential complexity that cannot be avoided. You need smart people to implement and manage it, and you'll have to pay them what the market says they are worth.
Building software that's more complicated than a standalone CRUD system is hard, it will always be hard, and unpredictable, and to some degree stressful. No methodology will ever make it anything else because the methodology used doesn't change the nature of the problem.
Just keep in mind that a lot of people equate Agile with Scrum, which is incorrect. Agile is about exactly what you said: empowering devs to get shit done. None of the extra “keep managers happy” crap that Scrum introduces is in any way covered by the Agile manifesto.
From experience i haven’t come across any “agile” organization that runs true to the manifesto.
There’s been plenty of discussions why the “what could have been” got buried in certain people jumping in, creating weird layers and interpretations of some process for their own profit and ego.
My team works in an agile fashion. I simply stay out of their way and every week they finish what they promised to finish. The team is high-quality and hasn't missed targets or estimates. Most of our "ceremonies" are purely for socialization, as decided by the team.
But this is extremely fragile, because it takes a lot of energy to fight external people (often product people) who want to remove the self-management aspect.
Unless this is in the DNA of the company, you can't have agile or real Scrum, because it threatens those kinds of power-grabs. For this to work, you literally need someone threatening to fire people who attempt to micromanage others.
I worked at a small startup that actually handled that distinction well for a while.
We did 2 week sprints, but that really was more to keep a remote team regularly in touch and updated. Sprint work was very much up to each dev, and at the end of the sprint anything that changed or slipped was just chalked up to lessons for future work.
That did change eventually, both as the team grew a bit more and funding started to run low. Eventually we had the worst of both worlds mentioned in the article, sprints with more rigid goals leading to a quarterly goal driven more by marketing goals than anything else. Throw in the fact that the still rather small company ended up with one person making product, marketing, and even technical decisions and we devolved into glorified code monkeys pretty quickly.
We use Agile at our company and let me tell you, it sucks. Maybe straight up scrum would be worse, but honestly agile is invasive and just feels like you’re being babysat and forcing people to give BS updates at standups because they’re afraid of sounding unproductive.
It's common in corporate implementations of Agile (tm) but it isn't actually some commandment or prescribed feature of Agile itself. It's actually prescribed by Scrum:
There isn’t anything in the agile manifesto on how to do anything. It’s a statement of preferences and values.
Business demands process for people in functions to follow. Scrum outlines meetings for programmers to attend, and specific process outputs like user stories to produce and close. Scrum is agile in business because business cannot do agile.
Right, so when someone says they are doing Agile instead of Scrum but don't like it because of the invasive status meetings, they're probably actually doing some form of Scrum whether or not they realize it.
Agreed. But Kanban also often incorporates some of the processes from Scrum like daily standups that aren't prescribed anywhere in Agile.
Personally I find it more useful to organize things around useful product milestones that are actually usable and demo-able. Those might take a week, or three weeks, but probably not two months because that's a long time to go without a demo and getting feedback. Sticking to a rigid 2-week sprint with an expectation of demo-able progress after each sprint doesn't feel particularly realistic or useful to me.
The business has a need for a regular status update from everyone. You can call it a standup or not. You can call it not agile, but in the end the business has needs and you cannot ignore those needs.
The business needs to know when something will be done as they need to make promises to customers. The business also needs to know when things will be done as that is a proxy for cost - they need to make sure they are not spending more creating a thing than it will deliver (this is a hard problem as some sales will not happen until it is done and there is typically a competitor customers could go with). That is nearly impossible to say how long engineering will take doesn't mean we don't need to know how long it will take!
Agile is meant to be a collaborative process with a user or customer to discover the truly desired objective. Baked into agile is the notion of changing courses. A business that wants a deliverable by a certain date wants a contract - not Agile. How can a route be predictable look with a process that explicitly seeks to regularly change course.
We could also get into the theory of whether it is actually possible to say how long software will take at all. Business might bevroutineky asking for the impossible using the wrong methodology for what they think they want
Software with business utility is never "finished" unless the business is finished.
Trying to estimate when software is finished is tantamount to asking when the last light will be turned off forever in the warehouse.
I keep trying to tell PMs that around the release date is when developers are the most busy, including afterwards. It's not some magic deadline after which developers are no longer needed.
Sure. I'm not saying there shouldn't be status updates. I'm just saying that those status updates aren't because they are "doing Agile."
There isn't really any such thing as "doing Agile", it isn't a prescribed process to follow.
And saying that you use Agile instead of Scrum but dislike the invasive status meetings isn't actually congruent with the actual definitions of Agile or Scrum.
It's been a long time since I last read it, and it's interesting how times changed.
On daily standups, from he manifesto:
> Business people and developers must work
together daily throughout the project.
> The most efficient and effective method of
conveying information to and within a development team is face-to-face conversation.
The "standup" theatrical part isn't in it, but that begs for daily meetings in the same physical place really.
Also...no. Verbal communication isn't effective or efficient. It's fast and natural, and perhaps comfortable to many.
In our current corporate environment, effectiveness (providing the right info in the right form) and efficiency (minimizing back and forth) will probably be better achieved with documents and open chat with all the parties involved, even if (in particular if?) it means slower throughput and more deliberate communication.
The stand-up is an opportunity to call out things that are blocking you, not for giving status updates. I got Scrum certified for resume padding, and thought it was gonna be easy, but I was blown away by the things I "knew had to be part of Scrum" that actually weren't.
It’s an opportunity to call out things four business hours after they happened. We have Slack now. Or Teams. If you’re stuck, tell people. Don’t wait until tomorrow morning.
> The stand-up is an opportunity to call out things that are blocking you, not for giving status updates.
I find it very useful for allowing everyone on the team to have a general idea what everyone else is working on. You can call out to ask for help at any time [1]. But having a 15 minute meeting each day to make sure everyone has a view of all the pieces in movement is handy.
[1] Though the standup does give a place for people that aren't comfortable calling out when they're having issues.. to do so because it's expected there.
> Though the standup does give a place for people that aren't comfortable calling out when they're having issues
In my experience, standups are the worst places for such people. If they aren't comfortable calling out when they're having issues, they're even less comfortable calling out that they're having issues in front of the entire class.
I find Agile is like democracy. It does suck, but it’s better than everything else.
What would you prefer besides agile?
I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate. Everyone should just work on things until they are done. He argued this earnestly and didn’t recognize that there are opportunity costs and conflicting priorities and the need to choose what to do. He earnestly argued that every single user story should be worked on in order of entry until it was completed. It would have been precious how clueless this suggestion was if he didn’t spent 20-40 minutes a week arguing this as an explanation for why his items weren’t done and why he was civil disobediencing to refuse to estimate or report time on tasks.
> I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate.
Plenty of learned people have made defenses for having no estimates. If you want to make the opposite claim, you don't need to use a junior dev as a strawman.
You need to break work up into tasks that take less than two weeks.
Beyond that, you’re metagaming and that is going to end up either not being worth the energy invested or a net negative. I say energy not time because there are only so many niggling arguments you can have with coworkers before they push you into traffic. Each petty little argument that could have been about something more important just runs down the clock.
I disagree as when you have a team of 8 people understanding whether something is one day of work or 10 is a big difference.
I don’t think you need precise estimation down to the hour, but knowing if someone can do 4 things in a sprint or just 1 is really important because people have interdependencies.
I don’t think I’ve ever had arguments about estimates and it’s usually a really quick exercise of “I think this is a couple days” and others saying “ok.”
For any tasks that depend on it. If I need you to do something and I can’t start until you’re done, it’s useful to know if you think you’ll be done tomorrow or next week. That lets me plan my upcoming days.
Would you feel it fair, when you require an estimate, to have to say what decision you'll make with it?
Usually, when someone insists on getting estimates, that's my way to make sure that they really need it. besides, it also helps making an estimate that won't be useless in the context of the decision to be made.
The lesson I learned from asking that is 1) many people ask for estimates without a clue about what they'll do with the info, and 2) when a decision actually needs to be made, the actual question is never "will it take 1 or 10 days", but rather "will that project be done by regulatory limit", or "will it cost 50k or 5 millions". And for the 2nd point, sizing every small task and adding up usually compounds uncertainty in unpredictable ways.
I’m talking about particular user stories, not the overall estimate.
For projects it’s almost always a budget issue “how much money and time does it need?” And that’s important because, like money is hard to get and $1 is different than $2M. I think the time is usually related to money due to revenue and costs and whatnot.
My example was about estimating “how long to add a revert button to 5 pages” and that requires “db crud to revert stuff” so how long the latter takes affects when the former can start and if they can both make it into the same sprint. Etc etc
I've never been in a situation where adding db crud was its own user story. Usually, we group this and the button (and the metrics necessary to trask feature use) in a single item, and pair people so it can be shipped in one go.
I've been encountering fewer and fewer small point stories of late. There's a certain amount of overhead for one story, both on the creation side and the deployment side, and that bookkeeping starts to overshadow.
And on a larger team, a lot of these little things that need to be done could just be tasks rolled up into a maintenance story.
Of course when I was on a team doing Kanban none of this bullshit mattered. You just put it at the top of the backlog and it got done. Quick win, instant gratification, next story please.
And that right there is one of the biggest reasons Scrum is showing its age. It came into a world where quarterly milestones were the only time you found out how fucked the project is, and only then if you had a good bullshit detector. Otherwise it would be next quarter when you figured it out. It pushed that world down to two week resolution, one month to see past the BS. But it struggles to make good on reducing past 2 weeks. One week has more overhead, and forget about anything shorter than that.
Also I've never encountered anyone who followed Ken's advice to run sprints from Wednesday to Wednesday, so we always get the worst version of Scrum.
I never understood this point of view. It's impossible to predict the future, and it's impossible to predict the complexity of something you've never done before. Given that, estimates can not be useful, other than as a tool for political post hoc justification.
I have personally only ever had success with estimates that were "is this a project, or is this a task that belongs to a project". Perhaps stretching to t-shirt sizing of S, M and L. Anything beyond that, say, comparing two projects to be able to prioritize and see the opportunity cost etc etc is a fool's errand.
From The Black Swan by Nassim Taleb:
[Critics say that] the maps we had were better than having no maps. [...] This is the strangest of errors.
I know few people who would board a plane heading for La Guardia airport in New York City with a pilot who was using a map of Atlanta’s airport “because there is nothing else.”
S/M/L is about as good as it gets. I’ve tried using story points but I think the point isn’t to have exact estimates but to figure out if 1) it’s too big for the spring and if so break it down into smaller; 2) is this someone a single person can do or it takes multiple; 3) can I do a couple of these in a single sprint (M) or it’s the only thing (L) or it’s just “5 minutes” (S and usually a day or two because nothing is 5 minutes).
I’m a fan of Taleb, but also a fan of using good maps. Note that Taleb isn’t advocating no maps at all, just that it’s stupid to use the wrong map just because it exists.
I agree that I’d rather have no estimate than a bad estimate, but it’s not like those are the only two options. I want a good estimate or at least a useful estimate over nothing or bad.
> It's impossible to predict the future, and it's impossible to predict the complexity of something you've never done before. Given that, estimates can not be useful, other than as a tool for political post hoc justification.
It is, however, possible to provide more information than "whatever" about how long it will take to achieve a goal. I have had goals I've worked on that were summarized with things like
- Could take anywhere between 2 days and 2 weeks, depending on factors
- Has an external dependency on X, and we don't have any insight into when X will be available
- May have other external dependencies, but we won't know until we're a few days into the work
- Not sure yet what the complexity of using <this API we need> is, so we'll need to check back in with more information once we have some time to experiment with it
- Expectation is about 5 days, on this, but it could be as short as 1.5, and could be as long as 3 weeks, depending on some factors
All of those things are more information than you had before, and allow the people that make decisions (which may be you and your team, or may be someone higher up the chain) to make _better_ decisions (or at least, better informed decisions)
And if you're working on something that you literally have no information on what's required for it, what the complexities might be, what the unknowns might be, etc... then perhaps the task you should be working on is "Identifying the work required to achieve <goal>", not "<goal>".
There is very little chance that what you are working on has never been done before. Most likely, you are writing simple code to do simple things. These things can be broken down into simple tasks, and these simple tasks can be estimated.
Unless you are working on ChatGPT-6, i assure you, you can definitely estimate how long things will take. your estimates will not be perfect, but they will be good approximations for guiding development.
Even OpenAI by now probably is pretty good at estimating how long the next ChatGPT version will take to develop, since they've done it 4-5 times already.
Alway always distrust someone who says "we are doing things that have never been done before". At the very bleeding edge (OpenAI, SpaceX), you are iterating on something that has been done many times before, but with a small innovation.
Code is infinitely copyable. If it has been done before it can just be copied, hence the time it takes is 0. If it takes more than 0 then what you are doing is actually something else entirely, like gluing said code to something else for the first time.
If it is not the first time, then you already have the code and hence the time it takes is 0.
There are cases where code is similar to code you've written before or you cannot just copy the old one due to licensing constraints. In this case estimation is easy, somewhere between an hour to a day or two.
Anything larger can be broken down to hour to day or two chunks since it has been done before.
All great, except this last case simply doesn't exist for the type of work that I do. And that is true for many people, software is extremely unpredictable because the stuff you need to build on top of might as well be quicksand.
I don't think the folks that say this usually mean "never done before" in the way that you are saying.
"never done before" in my experience usually translates to "this combination of things doesn't have precedence internally [to the team or company], so I have to figure out how to glue all of these parts I don't understand together".
And by "devs having to be agile" you mean "devs having to be interruptible during managers hours and flexible in doing their work after all the bs office hours are over".
it's not poor, it's clever. that marketing is what made agile the dominant paradigm nowadays. remember agile was adopted in entreprise despite IBM pushing RUP
"Keep managers happy" isn't part of Scrum, either. If you read any of the Scrum books by the creators of Scrum, you'll find that the way 95% of companies implement Scrum is nothing like what Scrum was intended to be. They mess it up, essentially in the name of marketing, and not wanting to truly change their ways.
> Agile is about exactly what you said: empowering devs to get shit done.
Sure, that's the goal. In reality, though, that's very nearly never what it does in practice. That's why I have come to view "agile" shops with an extremely skeptical eye.
Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. Sprints themselves which promise that a certain amount of work will always get done, without any free time being wasted.
A lot of the ceremonies in general are mostly helpful to the EM/PM. How many things that you're doing are actually improving how you get work done? Especially when you consider how much time is spent on these ceremonies (sprint planning 1 hr, sprint retro 1 hour, daily standup 15-30 minutes. Plus whatever prep is needed and the interruption time.) For many companies this is a 20% or more overhead that's mainly busywork because you still need the additional meetings to understand what you're working on.
This may sound like a no true Scotsman argument, when our company was trained by one of the scrum founders about 18 years ago, they were very clear that the daily standup was only for the team members, and the scrum master. (The scrum master could be a team member, and rotate btw). Managers were not allowed or invited to these. The only thing product managers and engineering managers would participate in and give feedback was in Sprint demos, and the beginning of planning meetings to answer any questions on upcoming stories.
At the time it was incredibly freeing and fixed a pretty awful and behind waterfall project. I was (briefly) at a startup a couple years ago that said they "did Scrum" and what a clusterfuck that was - all the managers meeting daily with devs to see if they were behind and scold them if they were. See ya.
But Managers as the center of the scrum is how many, many tech companies the outside world wouldn't call crappy run things. They also use Jira, mostly because they want reports that let people two or three levels up think they have any control over anything.
One of my least favorite standups was even worse than a ceremony for the manager: The manager and the Product representative were there in every single one, but they didn't actually pay any attention: Another 20+ minutes of "parking lot" would be added after the 5-10 minute process as they asked the team all the random questions they thought they needed, in which they also proved that they weren't actually paying attention to the actual updates, or the tickets, or anything. In practice, a sequence of 1:1 meetings where everyone was stuck watching, because after inquisition to one person, it'd come after another.
In practice, I don't think I've seen scrum run without a manager in standup, ever.
> Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status.
The scrum guide fairly explicitly states that managers should not attend or be part of stand-ups unless they're actively involved in the work as part of the development team.
I said in another post that I hated all the ceremonies, including standup. And it goes without saying that means long standups.
But, one team I was one, we had long ass standup and it was perfect. It was very dev-driven, we were facing hard problems, and that was our time of the day to really nerd out. The PM would get bored after about 15-20 minutes and then we'd be working out how to deal with the issues that faced us. Sure, it could have happened at any point of the day, but that was our designated time where we were all in the office (this was pre-pandemic)
That seems unproductive. You end up having a room full of people discussing problems that should be solved by one or two people outside of the standup. That's contrary to what a stand up meeting should be. Don't do that.
That's the issue where the PM has so much power. In our company the engineering team dictates their process. They can do however they like as long as they ship the products on time.
Because in real world people play with the hand they are dealt with. Team hasn't quit because there are no better jobs with empowered developers are waiting.
The real question is why is the team putting up with this? They should be complaining about the PM and wasted time every chance they get, at the "retro", team meetings, and 1:1's... Complain, complain, complain.
> It may be explicitly stated, but I’ve never had a scrum meeting without all managers and project managers.
This, this, this and a thousand times this.
It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong".
It's like when discussing communism with some diehard fans - when you point out the flaws, the response is always "well that wasn't real communism that's why it failed".
Well to both of those camps I say: if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?
I have seen teams actually do the Scrum-according-to-the-textbook, but those are rare. Most companies are just doing whatever their managers think is a good idea, and they call it "Scrum".
Ironically, the last time my team was doing Scrum-according-to-the-textbook, it was a decision of the developers... and then the higher management told us to stop, because the entire company decided to switch to "Scrum" (as in: endless meetings with managers present, no retrospective, but we call it "Scrum" because it sounds like we know what we are doing), so basically we had to abandon Scrum in the name of "Scrum".
My conclusion from this experience is that Scrum-according-to-the-textbook never happens as a top-down decision. The managers have strong ideas about how things are supposed to work, and they are unwilling to change their ideas, although they may agree to rename them to "Scrum".
I actually get the real-communism-has-never-been-tried vibe from people who say "scrum sucks, agile is the good idea". Scrum is simply what happens when Agile meets corporate reality. Make "agile" a popular buzzword among the managers... and soon you will see people complaining that agile in practice means endless meetings etc.
> Well to both of those camps I say: if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?
If your process to trim the hedges is much faster than normal, but also involves juggling chainsaws at the same time; it's possible your process is bad, because most people will fail to do it the way you've laid out.
(I'm agreeing with you, if that wasn't obvious... it's a pretty bad analogy, to be fair)
> It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong".
Scrum is a victim of semantic drift. The vast majority of people "doing scrum" have never read the guide and are just doing things that other people have told them is Scrum.
It's not Scrum's fault that people have hijacked its name for something completely different. It happens often.
What people call Scrum isn't really Scrum. What people call REST isn't really REST. What people call DevOps isn't really DevOps.
People using the wrong word for something doesn't mean the original definition of the word is invalid.
It's fairly different from the Communism situation in that people discussing Communism are generally talking about the same concepts and the debate is whether or not they're feasible. With the other terms I used above, people are using the same words to talk about completely different concepts with different definitions.
> It's not Scrum's fault that people have hijacked its name for something completely different. It happens often.
Scrum contains so many pitfalls that it's inevitable to get it wrong. Oh, the Sprint Review is NOT a report to management? Please do tell me where this then happens instead. If a manager can attend a 1 hour meeting to summarize the 2-3 weeks that the sprint was about, it will be abused.
> People using the wrong word for something doesn't mean the original definition of the word is invalid.
It doesn't make the original definition invalid, but words mean what society uses them to mean, which changes over time.
So agile & scrum do in fact today mean constant status meetings, treating professional developers as mindless cogs and keep everyone in line with a constant stream of tickets chosen by someone else.
Perhaps it's not what it meant in some idealistic manifesto lost to history, but it is what it means to developers employed in the industry today.
Scrum (or agile) done wrong is a unimaginable nightmare (I actually do have first-hand experience with that). But, overwhelmingly, my experience with scrum has been nothing but sweetness and light. When it is done right, all the stress melts away. Seriously. Just an absolute joy.
Are those who have toxic experiences with scrum actually a majority, or are they just a vocal minority? I'm curious if there's any data on that.
> Scrum (or agile) done wrong is a unimaginable nightmare
I agree. The issue is that I have literally never seen it done "right". It doesn't practically matter what agile is theoretically supposed to be, it matters what it actually is.
> People using the wrong word for something doesn't mean the original definition of the word is invalid.
Yeah, it's literally the worse thing you can do. I mean, not for the original definition of literally, but the new definition of literally, which is literally not literally, and actually literally in the dictionary with the definition of "not literally".
Just saying, at some point, the definition everyone uses becomes _the_ definition. And yes, I'm not a fan either.
That similarity is superficial. It is observing that no ideology perfectly survives implementation - which is true, but there is no alternative option so it isn't a useful observation.
We don't have any successful countries that use communist ideologies because central planning is destructive and the abolishment of private property is catastrophic. Calling for communism is tantamount to wishing for death and destruction. The path to success through communism is something like China where they eventually learned to do the opposite of communism and got great results.
We do have lots of successful companies using Scrum. They hire Scrum masters. They see Scrum as adding value. The scrum ideal is generally a bit of a compass towards higher value add. So scrum as an ideology seems to be net-successful even if implemented wrong.
>So scrum as an ideology seems to be net-successful even if implemented wrong.
How do you get to this conclusion? I haven't seen any implementation of scrum that didn't slow down development speed, due to unnecessary meetings and micromanagement.
This might be that I've only seen 8 or so "implementations". If there's any evidence that scrum is a key net positive I'd like to see it at this point.
Kanban IME can work well if the manager understood the core principle: Limit amount of concurrent work, use daily standup to prioritize work and unblock people hitting the multitasking limit.
Sadly this concept which is the core tenet of Kanban and can be explained in one sentence was still too much to grasp for some managers, but I've at least seen most Kanban implementations be either a net positive, or neutral.
I might be biased by my own experience, but I still need to see a Scrum implementation that doesn't grind productivity to a halt.
The company isn't optimising for fastest development speed. They typically optimise for low variance, consistent value in support of existing processes.
Interestingly, if you want highest value then for software it is best to use a high-variance strategy. But that is never going to come out of a company large enough to need professional management because it is pointless to manage large numbers of people to a high variance strategy. Google is an interesting case study where they tried that and, by and large, flopped. It makes more sense to spin out separate companies VC-style. I assume programmers occasionally quit companies, build something and sell it back to the company at extortionate prices which would be the right way to do fast development.
That isn't to say professional management is bad - large companies need it. It is just a fact that large companies aren't good at development and something like scrum elevates them from total failure to unproductive but fumbling in a good direction.
>scrum elevates them from total failure to unproductive but fumbling in a good direction.
Where's the evidence for this? I kind of agree on big corporate not being able to achieve great development speed. But they had a system before scrum, and I've yet to see scrum not completely destroying every metric of development achievement, whether it's throughput, latency or iteration speed.
The evidence is in the company choosing scrum then sticking with it. They believe it helped.
> I've yet to see scrum not completely destroying every metric of development achievement, whether it's throughput, latency or iteration speed.
It is too hard to argue from vague anecdotes, so I am resisting the urge to try. However, I will say that if that is a demonstrable thing and there was no upside then it would be surprising that scrum sticks as well as it does.
>scrum then sticking with it. They believe it helped.
Not necessarily. It's well known that there are many psychological biases in favor of keeping the status quo. Whether it's the sunk cost fallacy, the escalation of commitment or the endowment effect.
Humans tend to stick with bad decisions way longer than rational.
I think the problem here is we've had a huge trend in switching to scrum, but then people stick with failed scrum because it's the new status quo. Switching back to waterfall can't be sold by consultants. Even if it would help.
I'd go on a sarcastic rant here, but it's hard to stop myself. Don't read further if exaggerations upset you.
Sure, there are upsides, but they are hardly benefitting software engineering speed, quality, stability and developer happiness. The biggest upsides are for management:
- keeping the engineers under tight control by one of their business types (PO)
- making sure long-term thinking (like "what am I doing in this company") is suppressed by having a horizon of only 2 weeks in which you are supposed to give all you have to hit an arbitrary deadline. And then you start again! /s
- scrum has the beautiful effect of making engineers feeling either like kindergartners:
1. what did you do yesterday, Timmy? (standup)
2. Let's play with some cards, kids (planning poker)
3. Let's review what we learned last two weeks, children, and let's see what progress you made on your bean drawings (retros and demos)
How can you want a salary increase or question big man POs decisions, when you've just been acting like a kid for the last two weeks? Don't get me wrong, I do see the benefit of retros, demos, and some kind of planning and sync, but the way scrum just dumps it on you and prescribes you how to do it is just humiliating. Adults can sync, plan, retrospect and demonstrate what they did on their own volition and don't need some framework to tell them when and how, and two parental figures (the PO and Scrum master) to tell them what to do and when.
> The evidence is in the company choosing scrum then sticking with it. They believe it helped.
Many people also believe the Earth is flat and are sticking with that belief.
We absolutely learned something since the 90s that was beneficial. Corporative software projects now have about a two times higher chance of success than they had back then.
Also, we almost certainly learned that thing from Agile. There is no other credible source.
But the article has a clear point that places where people say they are practicing Agile has an even lower success rate than the overall one from the 90s. So it seems that the actual lesson from the Agile manifest was only learned by the people who don't claim to practice it.
> We absolutely learned something since the 90s that was beneficial.
Yes, software engineering has evolved, but to attribute its successes to the methodology used is like attributing higher cancer survival rates to better hospital management. In reality, it's due to the availability of better drugs, more understanding, and a lot of R&D, and it has 0 to do with management. Same with software engineering: we use better tooling, libraries, hardware is more commodified, and a lot of things we don't have to do ourselves. All things that have nothing to do with the methodology.
> So it seems that the actual lesson from the Agile manifest was only learned by the people who don't claim to practice it.
No methodology/manifest and no amount of management can compete with smart, qualified adult people being invested in their craft, and having autonomy and ownership on what they are building. The projects that succeeded are projects having those people, regardless of the methodology. In a way, people succeeded despite Agile, not because of it.
Could it possible be that.... you're not doing it right. lol
It is another great point. But it is another great point about how the process in your organization could be improved. Nothing says you have to have two parental figures.
And why on earth would you have a dedicated scrum master?! It's just not a job that should be requiring that much labor. Just have one part-time scrum master in the entire company who periodically audits and coaches teams who aren't doing the process right. Or coaches teams through the initial learning curve, as required.
In scrum and non-scrum processes that I have worked with, the PO comes from the marketing/sales team. On the theory that, if anyone has the pulse of what customers in aggregate actually want, it's going to be them. Also a part time job. But essential for injecting some realistic sense of "value" into the development planning equation. The direct contribution of a good PO is to make sure that the team is contributing work output to features that customers actually want. A good PO contributes enormously to team productivity.
Compared to what, exactly? I can't imagine you could say anything like that if you had experience with any of the heavy development processes that preceded scrum/agile methodologies.
The funny thing is that "communism" is a highly overloaded term, with several very precise definitions, one of what is so successful that about every country currently implements and people that dismiss it are ignored and considered radical. (But then, nobody calls that one "communism" nowadays, the the people pushing the others will really hate you if you talk about it.)
While "scrum" is a proper name with a single definition that anybody can look that is absolutely not precise enough for anybody to follow. By definition you can't really do scrum right.
>It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong".
Yeah, that would be the correct response. If we were discussing communism, and you started complaining that under communism everyone has to stand on one leg and hop up and down, a communist would correctly point out that hopping on one leg is not communism.
>Well to both of those camps I say: if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?
This is like saying that exercise isn't useful because most people who attempt it don't stick with it. Doing actual scrum is hard (particularly for managers), so a lot of teams can't stick with it. That doesn't mean it isn't useful.
>It's like when discussing communism with some diehard fans - when you point out the flaws, the response is always "well that wasn't real communism that's why it failed".
Nitpicking, but the Soviet Union, for example, never claimed they were already a communist state. They were the "Union of Soviet Socialist Republics", not "Communist Republics". Their idea was that, to have communism, you must have a transitional form of government first, "socialist government". The USSR even once had a motto, "we will build communism by 1980".
It's like if someone said they were following some other development process which would eventually lead them to Scrum. But no one does that and just calls it Scrum :)
> It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong".
Well, you are.
Give this shitty process you’re being forced to follow some other name and stop blaming Scrum.
Do Scrum properly and you’ll see why it’s actually fairly good.
> if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?
You can’t say that as you’ve not actually done the thing.
The main problem is that most managers and senior company people feel like they want more control that scrum allows them to have, and their use their power to overrule it. That’s their problem and not the fault of the Scrum system.
You may be onto something with communism. It’s definitely not resiliant to the kinds of paychopaths that end up dictators for life. I wish I knew why. Probably something to do with threats of violence.
As someone who works in a hard-tech startup, where daily standups in production manufacturing teams are part of the daily culture.
1) Anything longer than 15 minutes is insane
2) What do you even talk about for an hour?
3) Why do you even do standups for design work? What "blockers" could you possibly have that require daily, 15 minute tagups with the entire crew?
On #2, nothing. People stay an hour trying to look busy because somebody on the meeting expect them to be busy and the meeting to be important. So they spend an hour talking about nothing.
On #3, blockers exist more on design than on operation. But the idea of a daily meeting to solve blockers is crazy-stupid. Imagine if operations did this, every time somebody's work get a wrong input, you'd stop their line until the next morning. That's why operations dailies aren't about blockers, and instead about information sharing. But design work doesn't have separate teams that need to share information, so they invent a bullshit reason to still have the meeting.
We once had 1 hour long standups. The reasons were:
1) large team
2) many devs loved to go into detail about their work, and no one stopped them
3) the expectation was that a standup must be about describing what you did yesterday, in detail
What we did:
1) split the team into subteams where each team has their own standup (down to 5-15 min)
2) the standup's facilitator now stops devs from going into too much detail, "you guys can discuss it further after the standup"
3) now the expectation is that a standup should be about checking the project status and if there are any blockers, and that's it, you don't have to recount your whole yesterday in great detail
> 2) the standup's facilitator now stops devs from going into too much detail, "you guys can discuss it further after the standup"
I said this in another comment, but a standup I'm part of tables these until the end of the call; and then anyone not involved in that conversation can drop off. It seems like a reasonable compromise to balance the need to get people together to discuss something against the need to not keep people tied up. It helps mitigate the issue of people not wanting to plan a meeting to just "talk about" something (when that's actually what is needed).
So I think one thing that seems to pop up in people’s anecdotes is “well someone wanted to just talk about what they did yesterday.”
Which I suspect comes from the manager/PM going “so what’d you do yesterday?”
I’ve been taught, and I teach others, that in the standup you drive the questions. Usually along this framework:
1) I assigned you Task A yesterday. Did you finish Task A?
2) If yes, awesome. I have Task B for you. Or, go help Bob with Task C.
3) If no, cool. Why? What happened? Is there anyone in this circle that can help you? How can I help you.
4) Open Ended Questions/Comments that we need to circle up on later
5) General Announcements
15 - 30 minutes depending on the size of the team, scope complexity, etc. No one should be talking for more than two minutes. If whatever they need takes longer than 2 minutes, that’s taken offline and a flag something is wrong.
If you’re going to treat the software development like a factory, you must assign and manage work like a factory.
If you’re going to treat it like magazine publishing, you must assign and manage work like a publication.
Pick one. And stop having hour long standups y’all are crazy.
> If you’re going to treat the software development like a factory, you must assign and manage work like a factory.
What you described above is more like kindergarten, which is why any sufficiently seasoned developer hates Scrum with all the passion they have. It is mostly belittling, humiliating, and not even very productive at the end.
Interestingly, Scrum almost always ends up like being in the kindergarten, instead of addressing the real pain points, as it should be (eg. involve the business in the development process). But that takes real effort, which is hard, and therefore no PM or manager is interested in.
>What you described above is more like kindergarten
You ever try organizing and managing the work of multiple skilled tradesmen that feed into a single integrated product on tight deadlines? Do you know what works really well in that kind of environment?
Telling people what to do and then checking in on them to see if they’re doing well.
Is this kindergarten? I don’t remember being a skilled tradesmen working on building components for complex assemblies on tight deadlines in Kindergarten.
I concede that I am unfamiliar with what a normal “scrum” session looks like outside of what is said in the Agile manifesto and the many anecdotes floating around. I do know that Scrum took a lot of cues from TPS/Lean of the 80s and tried to feed it to Software.
And as far as I can see, it’s not working because the profession and the products do not fit this factory model.
What everyone seems to yearn for seems to match more closely to the model followed by magazines and other such publications. Product Management the profession mirrors more the Editor than the Production Manager, SWEs mirror writers/editors-at-large, etc.
Self respecting writers in any newsroom would balk at being subjected to daily scrums that take away from precious research/writing time. And to put some kind of regular pace on progress, metrics, etc. to what really is very bursty, deep focus work is also ridiculous. Whether it takes you 5 hours or 5 days to write the piece, so long as it is of quality and meets the deadline what does it matter. And even if you miss the deadline, you could alway be slotted into the next issue unless the piece was a cornerstone piece to the issue, in which case a good editor would have assigned it with ample time or given it to the best writer on the roster.
Hell I like this analogy. Might spend more time thinking about it and talking to SWE friends about it. Feel free to expand. Maybe this will free everyone from the shackles of Scrum.
One of the projects I'm on has a standup every day, and it generally lasts less than 15 minutes. Sometimes, a topic comes up that needs more discuss and it's tabled until the end of the call. At the end, anyone that doesn't need (or want, sometimes it's useful to just listen in) to be part of the additional discussion drops off and it turns from standup to technical discussion. It works pretty well.
Our PM quit a month ago and now we have stand-ups without any managers. I think it made the developers more responsible and involved: every stand-up a new dev gets the role of a facilitator. Previously, it was a one-man show. The stand-ups have become slightly shorter, too.
2 years ago we had 1 hour long dailies because the team was too large. We split into 3 subteams, each has their own stand-up. Now it's down to 15 minutes max.
In my experience, if the PM isn't part of it, the standup doesn't happen, because no one else cares that much. If someone gets stuck on something or needs help we just send a slack message, no need to wait for a fixed meeting.
That's hard to imagine. In big tech it's the team manager who decides that standups should happen and when (maybe this is an expectation from higher-ups). He always joins unless running late.
To be fair, it probably also works in practice, but by very definition post-scarcity is a necessary precondition. And that is still an ongoing effort that has never been realized. Granted, the UN has declared food to have achieved post-scarcity status so clear progress is being made, but we still have more work to do.
I've lived the first 14 years of my life under the Romanian communist dictatorship so no.
Let's put it this way. If it's the property of the people it's not everyone's in practice, it's no one's. So you're free to slack, cheat and steal from your "property of the people", you're cheating "no one".
> post-scarcity is a necessary precondition
There is no post scarcity. The goalposts for scarcity just move up.
> I've lived the first 14 years of my life under the Romanian communist dictatorship so no.
That doesn't make any sense. Communism's defining feature is that there is no longer a state. How can you recognize Romania, and especially a Romanian dictatorship, without there being a state?
Perhaps you're confusing communism with rule by the Communist Party?
- Communism is a work of science fiction that imagines what life is like in a post-scarcity world – indeed, science fiction that some people would like to see become reality. Star Trek is a more modern adaptation on the same basic idea, which you may be more familiar with.
- The Communist Party is a political group that, at least on paper, is focused on achieving post-scarcity through capturing the means of production. It was once theorized in a certain Manifesto about Communism that post-scarcity would not be achievable through capitalism as the capitalists would set up barriers to seeing it through, and that the way to protect against that was the bring the means of production into social hands. Hence why the Communist Party is so-named.
But that would be like saying that democracy doesn't work because you don't like what the political party known as the Democrats are doing in the USA. Or that workers don't work because you don't like what the National Socialist German Workers' Party (Nazi) did.
> There is no post scarcity. The goalposts for scarcity just move up.
Perhaps. But it remains that communism cannot exist without having achieved post-scarcity. How could it?
Yes. Communism's key attributes are that it is classless, stateless, and moneyless.
> Who takes all the resources and allocates them "according to each person's need" then?
We'd need to know more about how post-scarcity is achieved in order to answer that question. Star Trek says the replicator is responsible, although that seems unlikely outside of the imagined Star Trek universe. Based on what we can see today, I'd guess robots. But this is all speculative as we don't really know what post-scarcity truly looks like, or if it is achievable at all.
> Communism predates the idea of post scarcity by a hundred years or more AFAIK.
Are you referring to what is oft referred to as primitive communism?
Although I find it hard to believe that humans have ever not thought about post-scarcity. It seems like the first thought/dream anyone would have when first faced with scarcity constraints.
> Did communist utopians realize it doesn't work so now they're adding "post scarcity" to it to make it work?
Did TV fanatics realize that Star Trek doesn't work? What does this even mean? Communism isn't something real, it is a work of science fiction that details an imagined world after post-scarcity. Always has been, probably always will be.
Hell, even if we actually do reach post-scarcity some day, the chances of going the communism route are about as likely as us going the Star Trek route. Reality has a way of turning out quite different to what you envision. There is effectively no chance of communism becoming more than science fiction.
Is that what you mean by "doesn't work"? That it will never be more than science fiction? In the same way aliens, time travel, etc. "don't work"? Fair, I suppose, but that makes your communism obsession rather bizarre.
> "Based on what we can see today, I'd guess robots." Oh yea, "AI" is next.
How do you foresee AI being useful? Robotics is by and large how we've achieved post-scarcity in food production. If we were to achieve full-on post-scarcity, chances are we would do so by finding additional robot applications. We're not that creative as species. But who knows.
Are you struggling to say that Cuba will blame AI for allowing the USA to beat them to their post-scarcity goals? Perhaps. American innovation is unquestionably leading the way to communism right now.
If communism ever is realized as more than science fiction, it will almost certainly be because of the USA's efforts. There is no chance Cuba will get us there. Of course, their official claim of seeking post-scarcity is only for pretend to keep up political appearances. The USA, in contrast, is actually trying. You might say ironically, but I'd say that Marx just got it wrong and that capitalism, not socialism, is the most likely path to communism.
Be that as it may, if the scrum guide explicitly says they shouldn't then it isn't really fair to blame scrum for that.
Honestly, the recurring complaints with scrum, agile, etc basically boil down to this: shitty organizations can make any system miserable. People generally are blaming the intermediate cause (how we do scrum sucks) rather than the root cause (our company sucks and nothing would work).
Man, I agree with your specific criticism of the "No True Scotsman" refrain and with the larger criticisms of scrum, but this is an example of scrum prescribing X and companies doing !X, the literal opposite.
How could scrum, the product, possibly be to blame for that even if it sucks? Or, at what point is it reasonable to blame the PM/leader for actively and knowingly practicing !$scrum while pretending it's $scrum?
Companies try prescribing X, but as developers have no reason to care X doesn't happen without strict oversight by management, thus leading to !X to keep them in line.
Is the gun with a 180º bend in the barrel, with a caution label that says "WARNING: Don't shoot yourself in the face", that sees everyone who tries using it shoot themselves in the face the user's fault, or could we say that the product is faulty?
If a product relies on weasel words to try and pass its flaws off as being the user's fault, at what point is the product to blame? If one person uses it wrong, perhaps you can say that one person was doing something out of the ordinary, but when every person uses it wrong...?
Right. So in one team I worked in, the team leader had to take notes during stand-ups of what everyone is doing to deliver them to managers so they can browse at their leisure.
There are a lot of things better than scrum, but mostly these are all wrong ways to implement it.
Daily: should average at 10 min, 15 min is really the maximum. Including prep. So 5-15 min. No status updates! The daily is about getting people unstuck with their current tasks and quickly aligning on what to do next. If it is not useful for the team, the implementation is wrong. Doesn't mean it always has to be useful and interesting to you, there's a difference. Management stays out of the daily.
Sprint planning: the sprints are the compromise to management so we can have some sense of progress, so this is of course the one meeting that is useless to the team getting work done and can hamper productivity. Just make it quick.
Retro: you should do a retro about if you think the retro is useful and why/why not. If the team doesn't think it is, either change it until it works or make this the very last one. Management stays out of the retro. ("But are you then not doing scrum anymore?" "So what, save the pedantry for writing out the functional and technical requirements please")
Thing is, you do need to understand what you are working on, and it needs to be more or less the same as what your team members think they are working on. If you are 100% efficient at building the wrong thing, your 0% overhead amounts to exactly nothing, and the 80% efficient scrum team is infinitely more efficient. Though these extreme cases are usually a problem from higher up, without any way to align your work you will usually not be efficient. And if you are, then good for you, don't follow scrum like its some cult. But most teams need a little coordination.
Basically if anybody feels a meeting (or anything, really) is a waste of time, there is a problem that needs addressing. And the problem is not the feeling, but what is causing that sense of waste. Take it seriously, it is almost always signaling a flaw in the process. Learn how to talk about this in the retro and get to the bottom of it.
The retro is about debugging anything that isn't working optimal in the team. If you cannot find any bugs and fix them, then you are either perfect or just not good at debugging, and I know which one to bet one to be the most likely. One sure sign a team isn't very capable is when there is a lot of blaming involved. Usually external factors or tools get the blame, but in very dysfunctional teams people blame each other.
If you work in a team that doesn't adequately address these problems and you have no power to change it, then it may be time to look for another job.
But people DO do the thing right. As a loose guideline, I think you can reasonably infer that anyone who is telling "you are doing Agile wrong" has first-hand experience with an agile process that is working reasonably well. So take that as a starting point.
And the reason they are telling you that: because an agile process that is working well is like night and day to all the crazy processes that preceded it. When it works, it is amazing!
If I build a manual transmission car, and you insist on driving it like an automatic, it's not going to work for you, even though it's an amazing car. There are steps and processes that you must follow in order for the thing to work for you. If you don't, it won't. Simple as that.
Put another way, if you enter the olympics for breakdancing, and then just move your body around in a floppy way, you will not win the gold medal.
> The daily is about getting people unstuck with their current tasks
This I don't understand. Why do people need a daily to "get unstuck"? Are they not talking to each other? If I have a problem, I can proactively work on it, and contact whoever necessary. Unless you are very junior, this should not be a problem.
> If you work in a team that doesn't adequately address these problems and you have no power to change it, then it may be time to look for another job.
Huh, this is same for all employers I have known or worked at. Maybe on some distant planet it is done right.
I interviewed at a place whose sprint planning took a full week and was reportedly incredibly stressful. Customers participated. Their product was a website that agile teams used to track their process.
Perhaps these things are not necessarily meant to make managers happy, though managers do seem to like this stuff.
As a dev, I prefer a more fluid approach without all the rituals. In the start-up I joined a couple of months ago, we don’t deal with any of the above shit. Which of course is sure to change as the company grows, as that seems to happen often.
Our current way of working (remote company, 4 people):
- 2 calls a week, which tend to last about an hour.
- We discuss work for upcoming week or future stuff.
- We try to deliver every week on whatever was agreed upon at start of week.
Actually, previous company I worked at, was a bit bigger (35 people), but also very little rituals, at least for devs. There was a support department that did the JIRA related stuff. And we had like 2 day-long meetings every year to discuss personal goals/work for next half year. But afterwards just a short weekly meeting for team (sometimes lasting only 10 minutes), no stand-ups and such.
When I started at my current job, I naively looked at the bugs and tasks assigned to me, and started picking and fixing the highest priority tickets.
Then I was informed, "Oh no, that's not how we do things here. Don't look at the priority, just work on what is assigned to you in the current sprint."
I had never heard of sprints before.
More recently, I had a conversation with my manager and asked, "Do we really need sprints? I've been in this business a long time. 10, 20, 30 years ago we didn't have sprints and somehow still managed to produce great software."
The reply was "But if we didn't have sprints, how could we possibly measure the team's productivity and individual productivity?"
I knew I wouldn't win this debate, so I politely let it drop. I just wanted to sow some seeds of doubt.
In all fairness, my manager is a very reasonable person. But when this devotion to sprints is ingrained in the entire company, it is hard to question it or get away from it.
That's normal nowadays, even in the most ridiculous of situations.
I once found that a system was getting a little expensive. As, AWS was billing us a million a month expensive. I figured this out, and came up with a plan that would cut it down to 80 thousand by spending 4 days: You know, a mild, 11 million a year of savings. Management insisted that the work had to go through scheduling, and intake, a process that would involve zero developers looking at anything, but would delay doing the task a month and a half.
And no, nothing the team was working on came even remotely close to that ROI. Following the process just cost an extra 1.5 million dollars.
The only thing on that list I've ever liked is the velocity charts. And the only reason I liked them is that it helped me give a slightly less made up date to my own bosses to explain when something might ship.
Over the years I've found that devs have been the one who like retros. Or at least a certain subset of them. When I've been an EM I would try to get rid of them, only to have them requested by my teams. Who knew.
Retros all too often focus on the last thing that happened and risk turning into a complaint session.
I've told my team anyone is welcome to ask for a retro whenever for any reason, but we don't make them recurring meetings because there is too much of a temptation to find something wrong to fill the time.
Best retro I ever had, on a small team of seniors: we all sat down, looked at each other, agreed that a sprint happened and we couldn't think of anything that was good or bad about it. Then we called in our manager, who also acted as scrum master, so we could do planning for our next sprint. I thought this was reasonable enough - ostensibly we'd do retro and then planning back to back, and none of us minded the chance to take a few minutes and reflect if we had anything we should discuss.
By contrast, I've worked with scrum masters who were strict about the process and insisted _every_ retro needed to have at least one improvmenet or action item out of it, preferably more. I found this pointless and I've rarely seen them actually followed up on.
This is exactly why I hate retros. It's just a venting session. We're going to whine about some things, of which we have absolutely no power to change, and somehow that changes the future.
But people seem to love them.
I'd prefer to spend that time putting my head down and grinding through whatever sucky thing people were otherwise whining about.
As a developer, I find retros most useful when EMs (and probably PMs, depends on how things are configured organizationally) aren't present, as it should give a chance to talk freely about challenges you or the team face, which often are organizational in nature and may involve one's management chain. My current role doesn't adhere to this, and it makes retro often really painful.
I would agree with you. I never want my manager there. As an EM, I never want to be there. And yet, as the years go by, when I have an EM role I find my presence is requested. Again, who knew?
I don't know, at least for my current team a lot of the stuff we complain about in the retro is beyond the team level: coordination between teams, infrastructure issues, ... The intra team issues are usually talked about before (e.g. during standup, or just asynchronously).
If the EM is not there, those are not actionable. What we try to do is: do the retro by ourselves, and invite the EM at the end of there is stuff for them. Usually they are not available though...
You need some coarse odometer to know where the finish line is. Burn-up charts are a reasonable input to that and can be very low effort. Just knowing where you hit the inflection point between new-issues added to a milestone vs. issues resolved is useful. If you can replace a burn up chart with tangible test results matrix or similar - even better.
> retrospectives
I have never found per-sprint retros useful, either. I guide teams to do a retro when the issues raised in the previous retro are resolved. WIP control FTW.
> poker sessions
In my experience, planning sessions are one of the most impactful parts of the stereotypical scrum process for three reasons: (a) Planning creates a consensus within the team about what the story actually means; (b) Planning often leads to someone proposing a good 80/20 trade-off or raising an important point that avoids future re-work or unexpected tech debt. (c) Breaking big tasks into actionable, independently useful, small tasks is one of the hardest things for junior developers to learn. A lot of mentorship and teaching happens in good planning meetings. I encourage teams to try planning for the benefits of the process and not worry at all about fine grained points - "trivial", "medium", "unknown" is typically enough. Lots of mature teams will plan ad-hoc as they are ready for new work. This is my personal preference. But teaching teams how to plan effectively in a weekly planning meeting is often a good starting point.
> daily stand-ups
Standups that are control points for managers and expensive status gathering shortcuts are horrible. standups that are self-organizing, especially for teams that have ops + dev responsibilities, can be really useful. Nothing wrong with making a plan for the day - it should just take 10m.
> user stories and related tickets (eg in JIRA)
You should write down what you want to do somewhere and a few checklists go a long ways towards improving quality management.
I have never found scrum to be a good process (like the article, I find it very grinding) and I strongly agree with the posted article. But a good dev process likely includes all of these elements in some shape.
Good points, and eye-rolling stuff for teams thaqt don't understand the intricacies. For instance:
- burn-down / velocity charts: Teams use this at standups to make sure their sprint isn't drifting. That's why a burn-down should be tracked in hours and not points. With points, the data isn't actionable in a reasonable amount of time. The the team sees a problem, they might make use of a pre-determined emergency procedure to address it.
- retrospectives: Yeah most retrospectives are horrible. Retros should be like post rocket test - examine your telemetry deltas to see what changed (edge cases, governance,compliance, desgn, etc.) These conversations are not forced, but good teams always repeat the same data analysis unless they intentionally change it.
- poker sessions: Yeah this is totally misunderstood. Pointing stories is about snap reactions to comparing difficulties and complexity, and that's it, move on. Teams will tighten up estimates when they do an implementation plan in sprint planning. So they don't sweat estimates.
- daily stand-ups: The whole team is responsible for the sprint backlog, nothing is assigned, everything is volunteered. So if you're working on something that is going south, or you have some extra capacity, let your team know about it. The team will work together to scale capacity to get things done, which is how they can disappear on Friday afternoons.
- user stories and related tickets (eg in JIRA): Well yeah, Jira sucks. So do all the other major backlog tools. Jira gets addins, but the fundamental approach to backlog development hasn't changed in a decade. (I'm working on a soln from scratch, btw).
Also, user stories are meant to be work-items with enough signal so they can be executed with certainty in a sprint. So that means a lot of refinement to the left of the story must occur to get rid of the noise (epics to features to stories to tasks). Once a team says a story meets their definition of ready, that story can be scheduled for a (timely) sprint. Team members may be doing hard-core story refinement because of some technical hurdles, so their time outside of development during sprint can be pinned down with the team's capacity plan. BTW, capacity plans and implementation plans belong solely to the team. They're nobody else's business, including managers to CEOs.
Sure, comes from a prevailing view that estimating is bad. But it's only because estimating is treated like the answer, then we just go with that answer.
The best scrum teams I've worked with maintain a very important survival notion: We don't know the full minimum survivable solution today, but that's ok because we do know enough to get to tomorrow at least. We survived another day. Point is, estimating was never meant to be an answer. It was just meant to kick off discovery. And that's a great way to start because humans tend to be exceptionally good at quickly comparing things for difficulty and complexity. It's an instinctive survival skill.
Ultimately, well after estimating this scrum team will do an implementation (tasking) plan in hours if needed during sprint planning. They will compare that plan against their team capacity plan in hours. If the implementation plan blows out the cap plan by say, 30% then that's a warning sign and they'll tell the PO they need to drop a story for the upcoming sprint. If the cap plan compared against the imp plan shows a 30% surplus, then they will pull in a stretch story and bump their velocity, or won't tell the PO and maybe go play golf at the end of the sprint.
So the story pointing exercise just gets the team some data that helps them get to the next day (survival speak). There's still a lot of story refinement to be done, before they will tell their PO a story is ready to be pulled into one of their sprints.
When teams pull in stories to their sprint backlog, the team is committing to get that story done, so they need immediately actionable data on what's going on at every standup. If the burndown was done in points, the graph ends up looking like a straight line for days with sudden dropoffs toward the end of the sprint - that hides problems. So a sharp team will use task hours instead. Makes the plot a lot more actionable from day to day.
No, the prevailing view is estimating in hours is bad, hence the push for estimating in t-shirt sizes or other stand-ins for task complexity.
The survival terminology is really off-putting. And what’s the obsession with golf? This doesn’t sound like any scrum team I’ve worked with or would want to be a part of.
Well, a rather xor response, but that's ok. Let's go a different route: Someone is using a diet change (fixed), and the elliptical machine to lose weight. This person has no exercise background. The elliptical routine is basic - same program, one hour a day, 8 weeks. BF test is done at the end of each week. Graph the results. What do you think the plot will look like? Why did the subject's weight loss stall out?
Estimations are meant to be exactly that, estimations. Don't try to make them anything else. They offer a grey answer, so use the best tools you have to deliver that grey answer. In this case, it's simply comparing challenges for size, complexity, etc. Don't try to do estimations in a different way just because you want an immediate answer. Estimations are meant to be a starting point to get to a minimum survivable solution. That's how humans use instinctive tools that use the least amount of energy to get to a point that they can survive a challenge. Think about the elliptical example.
In scrum, estimations are the conscious way to get this discovery kicked off; they aren't meant to be an answer, because you don't have enough data yet for a solution. They are meant to be a starting point. Iterate to the solution. When you think you have enough signal for a solution (the sprint), do your final check and balance, which is a tasking plan in hours, during sprint planning.
Another example: The year is 1929, and you're asked to guess the weight of the Empire State Bldg before construction has even begun (1931). What answer delivers more survival information? 180,000 tons, or this: "Well, we know each floor is going to have x concrete, y steel, but not sure about the other construction materials. So it will be something like (x+y+?)*#floors. If your life depended on it, which answer would you go with?
You are looking for a number, and that's why people don't understand what estimating is about. The incorrect approach is like, "Well these estimations are crap, so let's change the estimation methodology." Yeah but it's still and estimation, and you already have a great instinctive tool to make those estimations via relative size comparison, which can be done so quickly, it could literally save your life. Instinctively, we accept that, conscoiusly we don't, so we turn into ill tempered Veruca Salt.
Regarding the golf reference, I'm from Florida. Sorry if the attempt at levity was weak.
I don't know if this is properly part of scrum, but it is how I've seen it implemented on every team I've been on where scrum was implemented.
Sprints end with some kind of demo, retrospective, and sprint planning designed almost entirely to keep PMs and managers in the loop and happy. Reports are generated, spreadsheets with a few quarters worth of tasks are updated, and PMs or managers get to run that further up the chain, presumably to make it clear that great progress is being made under their supervision and well run scrum methodology.
There are no PMs in actual Scrum. Scrum Teams are self-managing, so there's no need for a PM.
There's a direct relationship between the Client and the Scrum Team. Where most companies screw up is in their business model. You can't charge a flat fee for fixed project description and call it Scrum. Scrum is iterative, by design. It's supposed to evolve with the CLient's needs and desires. They want to be able to change the scope, the price, and the timeline on a whim. If you aren't billing per-Sprint, then you're going to have a constant "charge the Client for a change request" mentality, which makes them feel like they're being Nickel and Dime. It's much better to say "We welcome your changes at any time for any reason. It may not fit in the next Sprint, but we can always put them in the one after that."
In Sprint-based projects the Client has to be free to terminate the agreement at any time, if they feel they're not getting enough value in exchange for their money. This is why constantly delivering value to the Client is key.
When they charge a flat fee, they feel they need a PM to make sure they don't lose money. And how can you know if you're losing money? You force people to track their hours back. It all gets toxic.
When the Client pays per Sprint, as long as each Sprint is profitable and delivering value, it can be a huge profit center that has no end date. Often times, Clients will just keep adding features forever instead of stopping at the flat fee end date.
I could have been more clear there, "PM" has many different meanings these days.
I've never been on a team using scrum that didn't have a project manager or product manager as part of scrum (or both). Most often they have been my scrum leader.
Scrum is supposed to be self-guided, but I have never seen it implemented on a team of any scale.
I also wouldn't expect a team without PMs, whether that's project managers or product managers, to be very effective. Someone needs to be focused on keeping the project moving, and often the skills needed for a scrum leader/master overlap greatly with project managers. Someone also needs to be focused on the product and how the team's efforts fit into the longer term product goals. If that isn't anyone with a PM title it will be someone else playing that role with everything but the title.
Without a lot of the project reports, the manager would honestly just have no idea what's going on. I recently moved into management, and one of the challenges I'm trying to balance is how to be aware of my team's progress without wasting their time or being a bottleneck for them. It's a legitimate problem which is often tackled poorly.
At least in the case of software development, which seems to be what Scrum is targeted at, you get the project reports for free by way of the commit log.
That said, the 12 Principles of the Agile Manifesto offers another solution: Get rid of management entirely. It states that developers are best to work with the rest of the business collaboratively. Which is the irony of Scrum claiming to be Agile: Only management wants to use it, defying Agile to its fundamental core.
regardless of "process", work items should be tracked (in the problem solving record for our future selves sense, not time keeping sense), so you can follow those. If you're a non-technical manager, then either a) the implementation goes super smoothly and the estimate the dev team initially gave you is all the progress update you need, or b) it doesn't go super-smoothly and you should be involved in any discussions that arise. If you find yourself asking "when is it ready?" you've likely gone astray.
Burn down charts, team velocity, and story points.
They all exist to give software development the illusion of predictability, but saying that a project should take “x sprints” is just setting a deadline with extra steps.
There is nothing wrong with burndown charts but story points and team velocity are poison.
The way you get good at estimating is looking at your database of experience. “I did a task similar to this in 8 days”. Calendar time is real and punchclock time is real, either can be measured. Story points are not real and not measurable and they leave you lost at sea thinking that estimation is impossible, a scam, etc.
Agreed. Team velocity is a poison number. But entirely necessary in order to provide a data-driven approach to converting story points into time predictions (with appropriate disclaimer of risk) that people outside the team need. Data driven! How could that possibly be a bad thing?
Maybe best to just treat it as a classified secret that nobody actually needs to know. People inside the team just need to know that their stories are arranged in correct order of priority. People outside the team actually do need time axes on their burndown chart. But they don't need to actually know the toxic voodoo that was performed to produce the conversion.
:-P
But actually seriously. Nobody needs to know that number.
Right. So you don't do that. No development process ever has provided bulletproof predictability. Your job as a project manager is not to provide bullet-proof predictions; it's to manage risk, and expectations, and make sure that development work is correctly prioritized. And of course to keep your development team protected from external insanity, because happy, stress free development teams are productive development teams. (But that's a separate issue).
Here's the feature list; here is where on the list we'll definitely get to, here's where on the list we definitely won't get to, and everything else is some shade of inbetween. Now, would you like to adjust the priorities of any of those features, or would you like to change the deadline?
But what does it mean to "empower devs". Do you give them requirements and say I'll check in on deadline day in 6 months?
Presumably you would still use iterations to track progress, Epics/Features to break down requirements, some kind of estimation to track if you're ahead/behind schedule?
I certainly wouldn't go back to Waterfall days, but I suspect many current devs never experienced that.
- One on Ones to discuss roadblocks and thoughts every week.
- Issue tracking as a common place to describe what needs to be done and thoughts / details on how it is solved. Something lightweight like Trello is ideal
- A Kanban board so people have an organised way to pick up new issues when low on work
- A weekly showoff meeting where there are few 5 minute presentations and a 30 minute "I did something really cool or learned something really cool"
- 6 month task split into 1 month ish deliverables, with a flexible deadline for each. Presentation of finished work each deliverable.
This is basically how my team does it. I love it. My manager spends much of her time figuring out how to help remove our roadblocks and planning the 6 month to 1 year horizon (with our input). I lead the weekly meeting where we do the showing off, PSAs, or light brainstorming on issues with broad relevance.
Two scheduled meetings per week = tons of dev time and freedom to explore / innovate! (Ok, three weekly meetings if you count the product-wide meeting, which is usually a waste of N-5 people's time, and I usually have it on the background while I continue working.)
We are remote, so ideally there's also one in person gathering per year to do the big vision casting and major high level brainstorming.
We still have room to improve, especially in the area of ad-hoc dev-dev communication. Always interested to hear how others do it!
There’s a world of difference between checking back in 6 months and daily standup meetings + a host of weekly meetings.
If you don’t trust your team to be productive for 2 weeks without communication something is deeply wrong. Individuals should be in constant communication, but few things need to be said to everyone. Scrum style management may be useful for highly dysfunctional teams, but it frequently adds a great deal of unnecessary overhead.
That’s no easy feat and often oversimplifies the challenge of building competent teams. I think it’s achievable if you have a large budget to hire only senior/experienced devs and a mature hiring process/team. Plus, if your company has strong tech branding, it becomes easier to attract top talent too.
But if you’re at a startup with limited funding and possibly no branding at all, you’ll likely face this situation:
- Hire inexperienced but honest, motivated people with the potential to grow, and invest in mentoring them.
I do not disagree with anything you said at all! Though chances of success diminish here.
If you have to introduce some "process" - whatever that "process" is - because you do not have competent people and you feel like "process" will fix it, your chance of succeeding are a lot smaller IMO...
It seems we go astray when we start defining and evangelizing things that may have worked for some group of people to push them on others.
Somewhere in all this process stuff, I see maybe what some teams were doing but I doubt it was as rigid and I doubt they indulged in it when it made no sense. Once these teams or people are asked what they're doing right - it eventually gets defined into rules and then evangelized to people made to feel they can't deviate or improvise when the framework makes no sense. "Trust the process."
So people start wasting their time going through the process rather than using the process as a framework/tool for getting things done, they 'do' the process.
Their job is standup, their job is scrum, tickets, and points, and as a result their job is only marginally to do the things that need doing.
Company's might take more issue with this inefficiency if the workforce didn't double as something to manipulate pre and post head/tailwind to make the stock rise.
Pizza sized teams that can directly interact with customers don't need management. Management is playing telephone with someone in the middle with their own interpretation of everything which is 99% wrong.
It sounds like you've had bad management (like we all have). Good EMs will unblock you, deal with conflicting priorities from stakeholders, provide you with air cover to have focus time, and help manage your career growth (among other things). If your EM isn't doing that, find another one.
> Good EMs will unblock you, deal with conflicting priorities from stakeholders, provide you with air cover to have focus time, and help manage your career growth (among other things).
Those don't really seem like things you'd want to outsource, no matter how good the outsourcee is.
Sounds like you mix up management with product people.
Product people are not management at least not where I worked.
I see how it might be a problem if your manager is talking to the customers.
Product people are or should be equal to dev, engineering. They should indicate priorities but should not in any way evaluate engineers especially if they have no technical expertise.
The reality is even good devs tend to work hard on the wrong thing. Accountability comes from your peers as much as your manager. If this makes you angry you are one of the bad ones.
Everyone tends to work hard on the wrong thing if it what they like to do most currently. Everyone. A conversation is all that is needed to remind them of the team priority, non need to create a creativity carcan with processes.
Give good devs a direct line to the customer and they're apt to always work on the right thing, but will spend a lot more time dealing with the customer and a lot less time in development in order to do so.
Leave good devs to play telephone through a middle-man, what we call the manager, and they almost certainly will work on the wrong things, but will have a lot more time to do it.
I wonder which is actually more productive? Agile (of the Manifesto kind) posits that the former is most productive, but Agile (of the fake kind) seems to always want to revolve around the latter. The general sentiment is that fake Agile is the one that gets it wrong, so presumably cutting out the manager is what is most productive, but more data is welcome.
Disagree. The customer often has tunnel-vision on their needs, and doesn't know what's possible, and might have trouble even describing it except that their manager told them that their foo task was a problem.
The devs have the opposite problem, they can imagine all sorts of new technology that would be fun to use (for them) in helping the customer solve their problems with doing foo, and even if they understand foo from the customer's business perspective they they may not have a great understanding of how big a problem it is in the grand scheme of things and what commitment of resources and expenses are justifed in solving it.
Managers talking to managers can (in theory) draw some boxes around scope and priorities and get the right development problems solved at the right time. They may talk and realize that doing foo isn't even really a great idea and they should be doing bar intstead. Line-level employees working directly with developers will not be as likely to realize that.
Developers can fall into the trap of thinking that because they are smart (mostly) at building software they are automatically smart about all the business processes and problems and goals of the company. They should certainly be informed about those things, but they are not experts in everything.
If we were talking about developers in general, perhaps, but we're specifically talking about good developers. They exist at the intersection of understanding the business, what customers are actually saying, and understanding the technology. Without that, what would make them good?
Very very few of these people exist. They like to think that because they are very good at writing and understanding code and technology that they are automatically the smartest person in the room with every other aspect of the business. And I'm not talking exclusively about software developers, you'll find the same issues with anyone who is deeply smart and experienced at any one thing, thinking they must be smart about everything else too.
There are a few polymaths out there, yes. But only a few.
Well, yeah, that's why they're considered good. Why they get a special title not given to everyone else. It would be nonsensical for "good dev" to refer to everyone who touches software development. "dev" would already communicate everything you need to know. The addition of “good” implies being set apart from what is typical.
> You generally don't want to act on customer feedback directly.
Obviously not literally. What they want hasn't been invented yet, which means the words to accurately describe what they want also haven't been invented yet. But ultimately you do want to act on what they really, truly are trying to tell you. Indeed, figuring them out is a hard job all on its own.
> is a full time job.
Sure. That's the tradeoff. You can spend most of your time figuring them out, and then the small few remaining units of time you have for development will be on point. Or you can play telephone and have all kinds of time for development, but will more often than not go down the wrong path.
It's not really clear which is more productive at the end of the day. But we do know that Agile (of the Manifesto kind) pushes the former, while Agile (of the fake kind) pushes the latter. People seem to hate fake Agile more than they hate Manifesto Agile, so that does suggest that not playing telephone is more productive.
I've heard a lot of push back against all kinds of process on this forum, and it always surprises me.
But reading the article made something click: it is not about the specific process, the (lack of) autonomy is what really matters. I guess I got lucky to work a lot in teams where we largely controlled our own process, so even if we used bits and pieces of scrum, kanban or other methodologies, it was always of our collective choosing and when it didn't work, we changed it.
I did like to have rules, principles and process. A simple playbook for a daily meeting that made us not forget important things and sped up the meeting. Making things in small increments meant that I didn't have to review thousands of lines of code. Having a visual overview of work neatly spelled out means I don't have to re-think every time I pick up a new item to work on. This also prevents useless work because one of your teammates decides to work on the same thing as you without telling it. All these things make me happier and more productive working together on some big thing.
The key is that the team should be in control of the process, not some manager who isn't part of the team and affected by the process. You need to have a stake in it. The only other factor that undermines this is 'process for the sake of process'. Every part of the process needs to earn the inevitable cost its implementation is bringing. Some people seem to be happy paying the pricing without getting the value.
My first and second experiences with Scrum couldn't be more different. And they were successive. Actually, they happened on the same team, same people, same project.
Before: the team had internally decided to use Scrum. Other teams were not using it, and inter-team coordination used traditional project management methods. It was fantastic; the team worked like a well-oiled machine and I really did feel more productive. We never had crunch time. I did not feel the "end-of-sprint mini crunch" that this post describes; instead the norm was that, by the last couple days of the sprint, people were starting to finish up whatever tickets they had taken and pivoting to helping teammates get the rest of the work done. Oftentimes we'd close out all the user stories a day or so before the end of the sprint, and have all that time for tidying up the codebase, fixing small technical debt items, experimenting with new tools, or planning ahead for the next sprint. So, if anything, it was the opposite of what the article describes: the last few days of every sprint were downright relaxing.
After: The executives got wind of Scrum, and decided to standardize the whole company on it. We stopped work for a week so that we could have a famous Agile coach do an all-hands Scrum workshop. Which was fun, but the middle and senior managers were conspicuously absent. And then, after that, things kind of went to heck. The way our team did Scrum rapidly started to change as our team manager started getting explicit instructions on how to do things. We also started experiencing pressure to keep or maintain velocity. We started getting questions about why our velocity was so much different from other teams'. We could explain that the story point scale is team-specific and you can't compare story points across teams, but that didn't go anywhere. As I said, the middle and upper managers skipped the Scrum training. They weren't interested in being lectured about what I'm sure they perceived as pedantic little bullshit details.
I left that company and went to another where leadership didn't mandate any Agile methodology. My team did a homegrown Kanban-like thing. A team I collaborated closely with used Scrum. It also seemed to work pretty great. Again, possibly because we chose it for ourselves. I don't think the other team would have done as well on Kanban. Scrum wouldn't have worked so well for our team. I didn't see a problem with that. We each had different business domains that warranted very different "rules of engagement" with our stakeholders and ways of organizing the work.
Since then it's been a couple more companies where "Agile" was mandated from the top, and, apologies to Tolstoy, but they were both miserable in the same way that the first one was after the Scrum mandate got handed down from above.
“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!”
The Scrum Master is supposed to be part of the team, constantly helping with the Sprint, whether that's getting clarification for you, or pushing back on unrealistic expectations, or getting more resources, or whatever. Sprint was a bad choice of terms. It shouldn't have been related to races at all. If anything, it should be more like walking. It's about figuring out what pace is sustainable for your particular team, and sticking to that pace. Not driving anyone too hard, but delivering value (i.e. working software features and updates) at regular intervals. If a feature is too big to deliver in a single increment of time (Sprint), then it should be broken down into multiple features that build upon one another to eventually be the whole thing.
Yes, sure, all of that. But also, my boss's boss and my boss's boss's boss are looking at velocity and continually asking for more. They've got dashboards for it. Managers have to answer for why their team's velocity is different from another manager's team. Et cetera.
You can say "don't do that that's not how it works" until you're blue in the face, and it will still happen.
That's the critical failure of Scrum: it's one giant managerial dark pattern that's full of enticements to abuse it. Those enticements are constant. The exhortations to not do it that way are buried in the fine print somewhere, and the only reminders about them are coming from disgruntled individual contributors, probably from lower-performing teams, whose opinion is therefore suspect. The managerial opinion is probably that they should stop whining and make the deadline already.
I keep wishing we could instead have an agile framework that works with human nature instead of fighting against it.
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.
> 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.
Just to call it out: Having CI/CD doesn't mean you have to do all these things, or do scrum. It's imho just good engineering practice. I have it in my side projects, and I've had it at work on a Kanban-driven team (as well as on scrum).
It removes disputes over build process (eg, nobody can ever say "well, it complies on my machine"). It is a form of build/deploy documentation. It removes bottlenecks ("only Tom knows how to deploy that service, but he's on vacation") and stupid mistakes ("whoever deployed this last did it wrong and left a bunch of old files around").
I also have found deploying regularly is stress-reducing. For one, with CD the development environment is running the same steps, and we know it works because we do it dozens of times a week. The longer it's been since last prod deploy, the less confident we can be it'll go smoothly, whereas when it gets deployed every few days it becomes a non-event.
When something breaks, having only 1 or 3 changes makes it really easy to figure out why. Recovering after a big release with 40 PRs in it is absolutely painful.
None of this means you have to release everything on a regular schedule (like a sprint). You can still do long running branches or feature-flag things off, Just try not to go too long without deploying something.
> When something breaks, having only 1 or 3 changes makes it really easy to figure out why. Recovering after a big release with 40 PRs in it is absolutely painful.
This is, by far, the most important reason to practice continuous deployment. I've been part of enough of these fire fighting sessions following big releases to see that it's not a sustainable way to deploy software. And yet, I've never been able to convince any boss I've ever had to adopt CD because they're worried it'll introduce more regressions into production.
The way I’ve explained this before is “would you rather small issues that we can fix one by one until anyone really notices or would you rather we hit all those issues in one big go?” Your mileage may vary.
In the nearly 30 years of doing this, I’ve had more success delivering good quality software that meets business requirements under waterfall than any of the SCRUM implementations I’ve worked with, and I am saying that without disagreeing that waterfall has its problems. In the agile space, kanban is the only one I’ve felt is productive, but it has trouble scaling to multiple teams.
In my experience, waterfall forces business to think more about the project and plan accordingly. They have to think about how this feature interacts with this other feature. Business also usually has a better understanding of how the software will work because of the planning phase.
In my experience, with 2 week sprints, the business doesn't really have to think about anything outside of bite sized chunks or even how those bite sized chunks affect later bite sized chunks. They can make a snap decision without thinking about it because it can be rectified in the next sprint. Almost no-one has a "big picture," view of the software.
Before agile, we essentially did 4 releases a month (this was back on the burn a CD days), 2 major releases and 2 minor patch releases. It worked really well and we didn't get the burnout as much by sprinting a marathon. With sprints, I always feel burned out. No sense of accomplishment, no letup, working hard just gets you more work. It's like laying bricks one at a time on a wall with unlimited length.
Waterfall forces management to get it's act together. These processes are all about giving management more power and less accountability.
Product Management has fallen a tremendous distance from where it used to be. PMs who have come up completely under Scrum seem to think stories and epics barely require more than 1-2 sentences and the developers should have to figure everything out from there.
Even senior people in their early 40s have completely forgotten how to specify or document anything well.
It makes me wish I worked on something that involved physical products. The whole thing with agile/scrum is that management can change their mind at any time for any reason and the process gives them justification. It works in pure software, it doesn't work in anything physical because they had to sign the POs to buy materials and parts.
> No sense of accomplishment, no letup, working hard just gets you more work. It's like laying bricks one at a time on a wall with unlimited length.
Also feeling bad every 2 weeks because planning was really bad and now you need to say you're sorry the task has to roll over the next sprint and your manager has to explain to their manager, etc, etc.
It's one reason I'm really thankful to work in a certified/regulated industry. It's mandated to effectively prove your work to get the sign off. And since you can't really sell too well in the area without that cert, it's a big part of development.
But holy hell is it still hard to get specific people to test their work. They just don't even think about it.
ex manager here. managers are in an even worse wheel. biz demands managers show up to even _dumber_, less organized meetings than devs think they have to deal with. eng to eng meetings tend to be fine, but the rest of company culture at BigCorp weren’t trained in structured problem solving. it’s negotiating with goldfish half of the time (generally friendly goldfish), and no one actually practices any formalisms or larger cohesive pjm. “just give me a gantt” like the author says would be an absolutely monumental improvement from how i see things get done
With software you have a situation with two problems.
First is the "gap" between those doing the work, and those writing the checks. (When it's the same person, this problem disappears.)
The guy editing the checks likes to understand progress is being made, and that the project both has an end and will be successfully completed.
The second problem is that by it's nature software "never ends" and many (dare I say most?) projects fail and are simply abandoned.
The moment the check writer is not the direct manager of the development you have an intractable problem. The person in-between (quite literally middle management), is often not technical. But he has to convince the bean-counters that this project is "on time and on budget".
He can't help but feel sometimes that he's herding cats. He's an irritant to those who are "doing the work" so they treat interactions with him as a waste of time. Inevitably he starts trying to measure things. (And we all know what that means.)
His job is hard. He's stuck between developers who don't want anything to do with him and higher-ups who want reassurance, bit don't really trust what he's saying.
The miracle is not that this process sometimes fails. The miracle is that it ever works at all.
And sure, you may not like your meetings, but at least understanding the game might help you understand why his job is the crappiest of all of them.
It's beyond software: any domain that requires oversight of non-trivial work should really have leadership from the ranks so they are able to ground their observations.
Managers with no domain knowledge are just an extra layer of indirection and overhead without any of the benefits. Would any IC want their career gated by someone who has zero insight into the team's day to day duties, doubly so if it's at a supposed "tech" company?
> at least understanding the game might help you understand why his job is the crappiest of all of them.
Well, sure, but that's what the daily standup is for. So that the problem solvers on the team can understand the process, the problems it faces, and, importantly, find ways to optimize it.
But it seems, for how crappy you claim it to be, those in that position don't want to talk about it in fear that it will get optimized away. Job protectionism trumps all, I suppose.
Trust and rapport are gained in time, often in short order. Small artifacts of evidence should generally prove to the bean counter that they are cutting checks for something!
No, alas no material to refer to, other than my own experiences at several places in the food chain.
At the moment I'm having fun developing again, but I have had experience of management as well.
Obviously my experience does not speak to all cases, and I'm fortunate that most middle managers I've dealt with are competant.
I am in the fortunate position of being able to "speak truth to power" though, and generally been able to dispassionate translate technobabble into managerspeak, and help all the layers understand each other better.
I've found that when both sides understand (as much as they able) the complex demands being encountered, more realistic expectations and demands are made (and usually achieved.)
But I've been lucky. I've had good dev teams, good middle management, and good product owners. Who have all been pulling together to make projects successful. When one group is pulling the other way, things get tougher.
The meetings between engineers are rather unstructured. I hadn't really thought about what meetings between business types would be like. Decisions get made in those that affect whether the company is a viable going concern. That makes for a very uncomfortable line of reasoning.
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.
The post is fundamentally about all the performance of making stories, assigning points, allocating work and doing standups all the time. None of that is required to actually create software.
If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.
>> None of that is required to actually create software.
Agreed. (Assuming you mean "create" as in write, as distinct from create as in get funded.)
>> If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.
Clearly no stress is better. But these things create stress in the other direction too. Slower than expected progress, the existence of "intractable problems", work going unfinished creates significant stress up the ladder.
In a perfect world the dev team is given a perfect spec, and a reasonable time to do it in, and after being "left alone" they deliver the finished product on time.
Given that that world doesn't exist, given that the "money we're spending" may turn out to be completely wasted (because the spec was wrong, or because the problem us much harder than anticipated), the ideal case seems unlikely to happen.
I say this not as a defense of crappy management processes, or even less as a defense of crappy managers, but rather in the spirit that understanding the problem goes a long way to solving it.
And yes, many places have bad processes and bad middle managers. I don't envy you that. But finding a way to better solve the manager's problem typically improves the relationship.
I think ones that are against scrum are loud about it on the internet.
When it comes to have their salary paid out they will not speak up for themselves to push back against shitty management.
Like accepting ever increasing velocity until they burn out or accepting bad requirements because business is sayin “it needs to be done now” and working blind only to be scolded they did bad but requirements were bad in the first place.
> Improvement is finding efficient ways to remove stress from higher-ups. Because stress rolls downhill.
The stress at the bottom is there by design. If you start meeting the deadlines too reliably, the higher-ups will probably conclude that there are needlessly many people in the team, and will try to remove one and see what happens. Repeat until things start cracking apart.
In one of my previous jobs, I worked on a software project that frequently got the following two kinds of comments from the managers:
"Wow, this is the only project in our company that works reliably. There are no major bugs ever; and all the small bugs are fixed within a day or two. I wish other projects worked like that."
"You have five developers working on one project? Isn't that too much?"
Seemingly none of them was able to connect the dots and conclude that maaaaaybe these two things are somehow related. That maybe the fact that we are not understaffed somehow allows us to write automated tests, refactor when necessary, etc., so we can keep adding new features as required and the project keeps working ok.
So they started removing the developers one by one, moving them to other projects. The last guy left on the project felt overloaded and quit.
The project still worked okay for a few years without new updates, and was gradually replaced by several new projects (because it had a lot of functionality). But the new projects only had two developers each on average, so at least the managers didn't feel like they were wasting money.
Hmm, while I get what you are saying, I feel like dealing with that is _literally_ their job.
It'd be nice if we could remove stress from leadership, but I don't think that's a thing that should be my responsibility as a dev. Of course it'd actually improve the life of everyone if did, so it feel like something you should do regardless.
But then I'm taking the managers job in addition to being the developer, and then what's the point of the manager in the first place?
> Improvement is finding efficient ways to remove stress from higher-ups. Because stress rolls downhill.
Good luck with that because higher-ups have even-higher-ups until you reach the top. The bigger the pay packet, the more inflated the lifestyle and the associated stress of missing on the ever ballooning target. It is self-inflicted and never-ending; sacrifices of the lowly soldier will never quench that thirst.
Scrum/Agile is basically an answer for things that went wrong in the past. Building software has a long history of delays, running over time, running out of budgets, etc. As a stakeholder/customer, you need certainties up front: how long is it going to take, what is it going to cost? And if you think this isn't reasonable, just consider, would you hire a contractor to work on your house that can't tell you up front cost and duration?
Anybody doing work needs to be able to estimate duration, progress, risk of delays, etc. Other people's work depends on your deadlines. Go/no go of a project depends on cost and duration.
Insight and tracking is required. None of this was done any better before agile.
What is required is frank conversation with the stakeholder/customer, because there are so many trade offs decision to make. Devs don’t like to estimate tasks because there’s an exploration phase (which cost time an energy) to have the solution and the cost of time and energy for the implementation. And it’s recursive. Agile was basically saying, let the devs do their thing, but have a conversation every once in a while to discuss new directions to the projects based on new evidence found. And unless the team have already built the same project (with the same people involved), it will always be a bet. No amount of tracking or insight will remedy that.
Agile recognizes that software development is a design process with uncertainties and not a repeated tested manufacturing process (product development versus product manufacturing). With the uncertainty of a design process in mind, and the need for estimates, it suggests comparing similar tasks to get an empirical estimate. But since it's just an estimate, you regularly need to validate that the estimate is still considered correct.
Assigning Points = Roughly estimating how long it takes you to implement it
Allocating Work = Well... allocating work
Standups = Talking with your colleagues about the current work and clearing problems
Reviews = Showing your results
None of that seems unreasonable. The only thing that kinda sucks are the rigid sprints, because they just cause artificial stress by setting unnecessary deadlines.
They’re not unreasonable in themselves. What sucks is the process around them, because it impedes progress. Why because each tasks varies, and often it morphs while you’re working on it. So whenever a metric is fixed or something interrupts you repeatedly, it just sucks.
Or worse than impeding progress, everyone adjusts their expectations to only that which can comfortably fit into a sprint. Big gnarly bugs, meaty technical problems, or innovative solutions - too risky. Better just take a few random tickets off the board and keep plodding along.
The direct effect is organizations start systematically ignoring the forest and start obsessing over the trees, simply because trees are easier to measure. And then inevitably wondering aloud "why is velocity AND quality tanking?". Anyone with half a brain can see why - disincentivizing innovation destroys innovation.
I don't feel anything you've said is logical. The deliverable is, in the best case, what communicates progress and success. Short of that, tickets can do that, which is also not what the article is complaining about. The article also specifically attacks Agile/Scrum; Kanban is different and quite explicitly sidesteps a lot of the stress problems the article outlines.
> Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success.
In the agile teams I've been on it's been to produce success. Getting good and useful software fast.
Of course, just like there are hundreds of wildly different Christian sub-religions, there are now any number of "agile" interpretations. In the end belief systems can be pushed to do most anything you want.
Yeah, I totally agree in theory, it doesn't really matter what methodology you use, at the end of the day dev management is just a means to an end.
The real issue comes from middle management folks who conjure up buzzwords whenever they need to justify whatever they think the team should do. Don't know how to structure tasks but want to look like you're in control to the boss's boss? Just throw up a Kanban board with tiny tickets and a burndown chart trending down. Sprinkle in some Agile keywords in the management reports and call it a day. And let's not forget that by 'sprint' they often mean moving unfinished tickets from the last iteration to the current one, plus tacking on surprise urgent tasks that were not planned before because the product owner never shows up to share their vision and priorities.
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.
> The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
If what you are doing doesn't match that, then it's not a Scrum stand-up.
It doesn't matter what is written on a random website (even _the_ scrum website) if nobody actually follows what's written there and still calls it scrum. The de-facto definition of scrum is what people make of it.
> If what you are doing doesn't match that, then it's not a Scrum stand-up.
You must have stopped reading too soon.
"The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work."
I just find American corporate culture to be 90% about participation, not really results, but being there, being a "team player" and being really nice to everyone. Not necessarily bad things, but compared to Australian work culture (for example), America is really about "the teaaarrrmm".
Yeah, I worked with a bunch of people in the US a while ago, and I had the impression that they were playing house or something. I'm all for treating each other with respect, but that means something different to me than the constant. virtue signalling going on there.
US people tend to say that Dutch people are very blunt, but it feels like that should just be normal? If you do a bad job I'm not going to tell you that it was nice you tried so hard.
> 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.
It definitely is human nature, and beyond that we're so trained to focus on goals and take them seriously that the "sprint goals" actually feel weaponized to me in order to get people to self-motivate/drive themselves. In the Scrum world engineers are fungible, so if one burns up or stops performing, you just replace them with a new one.
Also that "rough week at home" is going to show up on metrics for a very long time. A good manager understands the ebb and flow, but many do not. It also doesn't help that the Certified ScrumMaster® people will put so much emphasis on smoothness and consistency, and when it doesn't happen there's always someone/something to blame. When you remove the context (like team lead who knows what happened) and put it in a quarterly chart for upper management, you get a lot of bad and counter-productive conclusions.
The sprint goal is a team target. If you're sick that shouldn't endanger the sprint goal because anyone in the team can pick up any work. Of course in mediocre or low-performing teams that's almost never the case but still not the fault of a product framework
What you say works 100% for trivial CRUD applications. Which is also, where SCRUM is still a bad framework, but at least SCRUM works on this trivial level of software development.
When a project is about non trivial projects, people, especially developers can not be easily replaced, because no one can replace a specialist with several years of experience on the spot. What I can archive in one day and what somebody else can archive on a day highly depends on what it is. Write a field to the database? Works. Write a rule engine? I'll probably be a factor of 10x more productive than an average developer. Write some GUI/CSS? A frontend developer is 10x more productive than me.
This seems like a disingenuous answer to me - the rest of the team will take up the slack? And if they can't they must be a low-performing team?
The OP may have some things wrong, but the 'constant grind' aspect of scrum sprints is spot on, there is no slack.
Add to that the 'radical transparency' aspect of scrum. That works great among a tight-knit team, but it can be insidious and actually self-defeating when certain types of manager get involved and weaponize it.
I'm sure there are many people who love programming, but hate being a programmer as a job, and to some extent that has always been true, but scrum seems in many cases to make it much, much worse, IMHO. The attitude displayed here is exactly the problem.
This doesn't apply for pod-based systems though, does it? They were everywhere for years there and are still very common. Basically by definition there's only one or two people that can do each task.
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.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
It's kinda nuts how many capital-A Agile processes (and consultants!) produce situations that are diametrically opposed to the original ideas. Notably, Scrum is often processes and tools over individuals and interactions.
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.
Heh, I say the same thing nearly every time a meta-discussion on Scrum/sprints is had. As a former sprint-runner, it irritates me to no end that nobody sees a problem with sprinting all the time...
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.
I wonder if this team could have choosen any framework and it would have worked, they just happened to use scrum. With the founder mode discussions recently there was this saying akin to "a successful process is a result of talented people" and not the other way around. It stuck in my head and I feel this is an instance of that. Although you definitely can force a process on a talented team and have their productivity diminish.
Agree. It's just that well understood scrum is a great process for delivering certainty and stability, as proven by lots of teams (provided they did scrum correctly).Just saves energy to thoroughly vet the process before tossing it.
But first principle, this is a physics issue: Whatever way a team comes up with to maximize the amount of work not done to deliver the same or better outcomes, I'm all for it.
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.
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.
My actual job was to make sure the tickets were clear, relevant and ready to work on (as opposed to a stream-of-consciousness wishlist from managers). I gathered requirements, represented the devs in planning meetings, cleared their hurdles and QA'd their work. I was basically a prep cook for the devs.
I work with someone who has that job. The stream of consciousness is much preferable. I need to know the big picture, not some distilled set of requirements. Give requirements and I will spend half my time trying to "reverse engineer" the big picture from them, which is a big waste. And an even bigger waste if I get it wrong. Not sure why our industry is so obsessed with obscuring information.
Although I appreciate having someone to move boxes around for me. I cry a little every time I have to go near that horrid UX.
"We have a non-binary, genderqueer, genderfluid, agender, bigender, demiboy, demigirl, two-spirit, androgynous, neutrois, third gender, polygender, maverique, hijra, kathoey, fa'afafine, man, or woman at my company whose job is to update Jira ticket statuses."
Sorry to hear that, and please have it attended to sooner rather than later. The recovery times can be worlds apart depending on how far burnout is allowed to progress.
I imagine it's still not that every development process stresses you out equally though, so it's still worthwhile considering how much stress the environment adds and why.
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.
> 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.
You are misreading the graph and then taking your own bad reading and projecting uncharitably on the author. Nowhere did he say that you can slack the first half of the project. Also, I know the author and I know that he has worked waterfall, so your conclusion isn't even accidentally correct.
Look at the Y-axis. It's measuring stress, not effort/work/slack/etc.
Also, the graph itself refutes your conclusion that it is representing only one single "milestone." Notice the graph falls after achieving the milestone, and then begins again. It's a continuous cycle.
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.
Same here. I have become stressed about deadlines that were actual deadlines imposed by external dependencies (e.g. API deprecation) or stakeholders (e.g. launch of feature needs to be coordinated with efforts in other departments), but never about "deadlines" I've just had a hand in making up out of thin air myself during sprint planning.
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.
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.
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.
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.
Why do you assume that its devs who are slacking in waterfall? Devs enjoy deving, usually there are either discoveries during execution or change of mind of client or pms figure out that their guestimation for year ahead was not exact. Surprise, surprise and who is going to have crunch time? Devs of course.
I didn't say they were slacking, but they may be working on the wrong things, or prematurely optimizing things at the expense of other priorities. Ironically, it's the author who suggests implicitly that devs can slack more in waterfall ("Sprints never stop").
Since the client is involved in every sprint, any change of mind they have during the development process (and keep in mind that changes of mind are a virtual certainty in either case)is at least better informed than if the touchpoints were much less frequent (or as is too often the case in waterfall) all back-loaded towards the end of the project.
Does scrum eliminate crunch time? Of course not. But if it's done well, the impact is minimized because there has been so much more opportunity for course correction throughout the project.
It’s that culture of fear that I don’t understand: devs working on the wrong thing. More often than not, it usually means: Is the dev spending more time than me (who is not doing the work) is willing to give him? Every professional understands priority and expectations. And communication is all that is required. But PM usually don’t understand the nature of software development and fear of losing control (the bad ones). The good ones just let people work after they made it clear what should be worked on.
>Every professional understands priority and expectations. And communication is all that is required.
Sure--the kind of communication that is ensured by a brief daily standup (communication within the team) and a regular progress review with the stakeholders, like say, a sprint review every few weeks (external communication).
While it's true that every professional understands the idea of priority, the global priorities of a project may be very different from the individual priorities of a developer. A diligent, conscientious developer can still get caught up in a narrow problem that doesn't really move the project forward, even after the PM has "made it clear what should be worked on." Fire-and-forget is not a strategy for project success. Continuous communication and regular reviews/resets are a better way.
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.
The main value of stressing about sprint goals and what's "in" a sprint and finishing it is the very specific situation of there being a bunch of people who want to feed in a large amount of work to a team (usually bugs/support requests/operational work) and it results in constant prioritization issues.
If you don't have that situation, you probably don't need to be really careful about what's in a sprint.
Kanban lets you prioritize exactly the same way, except it doesn't have to fit into a sprint schedule. You also have to make good stories, which are independent, have a meaningful thing that gets delivered and are of a reasonable size. Then important bugs can get moved to the top of the to-do column, and get done quickly as possible without interrupting any in-progress work.
Problems with Scrum: It's nice that you did your planning poker, but all these tasks need to be ready by the end of the month regardless.
Problems with Kanban: It's nice that you set priorities to the tasks, but all of them need to be ready by the end of the month regardless.
Conclusion: If there is more work than people can realistically do, and it all needs to be done no matter what, it doesn't matter what process you use; people will be stressed and burned out.
> do estimation the same exact way, but rather than arbitrary deadlines,
The core problem with that is that effort - consciously or not - gets immediately turned into (start day + estimate) => deadline which only works when you consider spherical cows, not accounting for the hard true practical fact that reality is messy.
And it is quite messy, by the very nature of the work which is to do something that has not been done before (otherwise by the very nature of software you'd just reuse it) and thus carries unknown unknowns. Everyone has experienced this "one-line fix, should be done tomorrow" that turns into a bind-mending multi-week hunt down the rabbit hole; replace "fix" with "feature" at your discretion; replace rabbit hole with "that very urgent task preempting anything else".
The second-order problem is that deadlines are used to schedule higher level dependencies between teams, all the way up to product, and possibly customers, and then it becomes the coupling interface and everything falls apart when there's a delay that inevitably trickles up with rippling consequences, because the system is not designed to handle such a failure mode, having this deadline dependency as its core interface between all the parts.
If you're not convinced of that, "follow the money": the consistent metric across the software industry to evaluate an employee's performance boils down to "deliver on time". Three months down the road, the rational explanation to delays of mandatory rabbit holes and very legit preempting tasks is forgotten, even when acknowledged by management. You're told to factor all that in, but estimating unknown unknowns is by definition impossible (best case you go statistical, with deadly outliers around the corner, which amounts to say it's a bet). Experience reduces these unknowns but they're still around, everywhere. Overall, you tried telling the hard truth with absolute candor were left helpless when it backfired.
Ultimately, whatever the process, the stark reality is that to get shit done you have to take part in the make-believe dance and lie - white lies, because soon enough one realises that the other kind of lies also backfires very quickly - in a way that still communicates some form of deeper truth: "progress is being made, it'll be done (when it's done)". Inflate some numbers, tune wording when reporting, steal time by bleeding some for task X (reported or skunkworks) into task Y. All the reporting meetings and documents entirely become smoke and mirrors, but are somehow important as they're oil to the whole machinery. Two parallel universes emerge and graciously evolve in parallel.
This sleigh of hand is the missing buffer catering for the lack of acknowledgment that producing software is entirely different in nature than producing hardware in a factory. It is in essence more of a creative act, albeit a strangely misleading one because of its technical component. Lots would be amazed as to how much closer it is to advanced drawing or musical composition than it is to more "material world" engineering (although the rigorous process of the latter certainly helps for technical aspects), and taking classes of the former would probably do a lot of good.
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.
I think the issue with formal processes is that, while they are created to serve a goal, they very quickly become the goal.
When everybody in a room agrees that deviating from the process will improve the chances of success, but nobody in the room is empowered to approve the deviation, morale will drop quickly.
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.
Well, it's worth pointing out that the only thing factory kanban has in common with software development kanban is the existence of some artifact called "kanban". What was probably a publicity stunt to use the hype of the other kind, kinda like Java and JavaScript.
If a factory is producing N widgets, every widget is the same. If a software teams are producing deliverables, each is different.
Kanban (originally) is an method of sending purchase orders (ie requests to make widgets of specific type in some quantity) from the team(s) who need them to the teams who make them.
In software, quantity is always 1 and while the “widgets” have notionally been designed (specced out in the ticket), they have never been built before, unlike in the factory where every widget at least had a test run before.
That is, Kanban in software development is a cargo cult from Toyota in which an essential difference (time to reconfigure the assembly line for another widget, vs time to design, prototype and test the widget) has been lost.
Kanban was invented for Just-In-Time factories, where each product item is customized to meet demand, so fewer things can be predicted in advance, thus making Waterfall unsuitable. Kanban allows to achieve both the flexibility of customization and cost effectiveness of mass production.
In software development, incoming requests are broken down into small manageable tasks, which are familiar enough for developers to estimate reliably. Then this continuous stream of small tickets is executed continuously (Kanban) or in sprints (SCRUM).
For example, request to add feature X can be broken down into «Make UI for feature X» and «Make backend for feature X». If they are still large, they can be broken further, for example «Make a CRUD for feature X.y», «Make a SQL table for X.y with migration script», and so on.
No, each product run is customized. Products are already known and fixed (they have been built before, with the same specs), the demand is unknown (in advance). There is a subtle difference between this and your “make CRUD for xyz”, where XYZ is always something different (if it wasn’t, we’d just reuse the thing we wrote the last time).
I would encourage everyone to read a book about TPS (The Toyota Way is a good one), and compare/contrast that with Kanban as an agile software methodology.
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.
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.
Evolution of a manager and scrum team achieving high-performance together:
Team: "We are having trouble with Bob."
Manager: "Ok I'll talk to him."
Team:"We are having trouble with Bob."
Manager: "Don't come to me, you guys need to deal with that in your retro."
Team: "We voted Bob off the island."
Manager: 'Ok, I'll forward to HR."
Autonomous teams get more done because they have eliminated management as a wait state and will proactively scale with other autonomous teams to maximize the amount of work not done. 21st century managers need to re-focus on flow efficiencies (as business engineers), and not people. 20th century managers won't have a job in 5 years.
Sure, maybe optimize further. Why have managers? The CD pipeline goes throughout the whole value stream, not just at delivery. Just like delivery automation (eliminate intervention of humans), there's also human automation (helping people get out of their own way). So I could see a use case where managers are just eliminated. You need people who can eliminate the noise and replace with enough signal that delivery teams can execute. POs and stakeholders can do that; managers not needed.
I think what you bring up though is an interesting point: maybe managers needs to transition to business engineering roles.
This all will play out in the 21st century. 20th century management is a legacy artifact at this point. Best example is F500s, which are generally mediocre in their execution. If a SpaceX type org (14k employees, private) gets into their space, they're screwed. Even with politicians in their pockets, I don't see how rock swallowing dinosaurs like Boeing (170k employees, public) will make it. Just the energy they have to expend to get anything done compared to SpaceX is massive, due in part to their giant management bureaucracy.
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.
Schedule meetings, move tickets around, moderate meetings, call more meetings, scold misbehaviour during meetings, help management with their stuff(secretary/personal assistant?), scold other teams for not helping out in time, question about stale tasks(tickets), act as coordinator of news/requests/demands from other teams, attend all meetings which involve tickets, coerce/seduce other teams to deliver something early because our team has messed up, promote more scrum agile topics. At least that is what I observed at my work. They indeed do a lot of work but often not well defined.
I didn't mind our daily standups at the last place. They were usually short (10-15) mins. It was all the bullshit and developer grovelling at the end of the sprint, and the lack of allocated time to actually plan future work, that was the problem. I saw people time and time again cutting corners to meet their imaginary deadlines. I'd get sent PR's to review after hours by people in different teams the day before scrum deadlines. It was insane.
The standups themselves were fine and actually I thought they were pretty helpful, especially during covid times.
The problem with standups is that usually the wrong people are talking.
I don't give a rat's ass about what other developers are doing. I either already know by virtue of having to work with them, or they are entirely disconnected from my work and so what they are doing doesn't really matter.
What I really need to know what the managers and executive are doing. That has the most impact on my work. Yet, strangely, they almost never want to share.
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)
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.
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.
If you are working in a place that lets your team pick the sprint length each time based on how long you think it should be for the work you're doing, that is absolutely not typical.
You seem to be either taking your anecdotal experience with what was called "scrum" and projecting it back onto the spec. Or, redefining "scrum" to be what you think it should be, not what it is. Incidentally, I find nearly everyone who defends scrum does the same thing. It's a continual No True Scotsman that gets to the point where "scrum" becomes meaningless. I actually blame the Scrum people for that because there's a ton of things that are guidelines rather than rules, although the ultimate decision is with the ScrumMaster or PM, so the level of flexibility of the Scrum implementation is dependent on the benevolence of this ScrumMaster®.
I worked as a consultant for several years and have been at many different startups, so I've experienced a lot of different flavors of Scrum, and the effectiveness varies widely. There are Scrum implementations that are authoritarian hell-holes where devs are just mice on wheels, and there are some that are pretty good. The problem is, both are still "scrum." So it's a lot like saying "monarchy is good" or "monarchy is bad." Well, it depends a lot on the monarch, but the system itself gives an enormous amount of control to one (or a few) people, and then it's up to that person to divvy out autonomy as they see fit. You might get a benevolent ruler who gives autonomy, but you might not, and both fall under the system.
I’ve never had variable sprint lengths, but picking the internal is exactly how I’ve done agile for years.
The whole point, I thought, is that you’re just frequently releasing so you want some fixed interval rather than adjusting it based on workload. Pick work that fits into the time period, not the other way around.
> My team chooses the characteristics of the sprint. It’s not like they are randomly assigned...It’s not like there’s anything mandatory, so we set our release schedule and what a release means based on what makes sense.
Count your blessings. This is not the case everywhere.
I don't know which process you follow, but while sprints are created in collaboration, in mid/large organizations everything is supposed to be in-sync across departments (so you can align interdisciplinary tasks).
In most cases I've seen, Agile basically introduces an additional company-internal clock with tick-tocks for days and weeks.
To me the article correctly describes how agile is assumed to be 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,...)
> 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.
No dictation on length, but the length is supposed to be consistent. If you want to take a three week sprint or something instead because the feature makes sense, you mess up a whole lot of things, especially the metrics. And, let's be honest, the metrics are the biggest reason why management imposes Scrum. They want to be able to quantify everyones contribution down to hard numbers that they can then use to know how everyone is performing. If you screw up the metrics, it won't take long for someone to step in and "get your team back on track."
Metrics and software process are orthogonal. Now, you can argue that consistent processes across teams is used to enable metrics, but Taylorism is going to creep up any place that has management that has been infected by it.
"They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint." - scrumguides.org
You also need to understand that "release" might mean behind a feature flag. Further, while continuous integration is not within the Scrum guide, it is a common practice in Scrum teams. Yes, there is a concept of a sprint goal, but the sprint goal may be a subset of the product goal. You may choose to group increments across sprint boundaries to present to customers independently of the end of the sprint.
I don't mean Scrum, I mean that people believe the this is Scrum.
Sprints DO have a break. The morning of the first day is just about figuring out what threat will look like. The afternoon of the last day is everyone talking about what they did during the Sprint. That is a full day of doing no coding and just talking with each other about the work. Every two weeks. If someone is forcing you to work in different way, then that's not Scrum.
The dev team is supposed to be encouraged by the scrum master to only take on the work that they can finish during the upcoming Sprint. If they take on too much work the answer is not to insist that they finish it but to ask what they need to understand better about their work. If someone is insisting that the Sprint backlog absolutely must be finished every Sprint, they aren't doing Scrum. As a corollary I hope no one is trying to insist that you do a release that coincides with the Sprint schedule. That's not scrum either.
Scrum is based on principles developed in the Toyota way. There are two pillars in the Toyota way, continuous improvement and respect for people. I'm sorry it sounds like you not lived with either of those pillars. I hope you find a scrum master who understands and can encourage this type of development.
By the way, I am a scrum master myself and this is how I treat my teams. I choose to trust them every time. And I encourage them to make good healthy decisions for themselves.
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.
Exactly right. I've seen it first-hand. It's all about the data. It's also neatly separated from the real operating context in a way that presents it as highly misleading.
Incidentally, if you criticize the data (such as asking "Where does this data show the effort that people who spent time mentoring/pairing but didn't do the actual 'commit'? Where does the data show the effort spent code reviewing?), you should know that it won't be received well. The emperor really does not want to hear that he's not wearing clothes.
Indeed. Which is backwards. The goal shouldn't be giving execs a warm fuzzy feeling. It should be identifying issues and risks that execs can help fix. I.e. handle exceptions to the norm.
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.
Early in my career (mid-90s) I worked for a defense contractor working on avionics for the F-22 and for GE working on a real-time automation OS. Both used waterfall exclusively. The defense contractor had a multi-year plan with monthly deadlines that could not be missed and the same was true for GE but the deadlines were more delivery based. At GE there were 400 engineers working on the overall project and we had a 40 foot long wall where the GANTT chart for the project, generated by MS Project, was taped to the wall - it was about 4 feet high.
I’m not sure why the above comment is being downvoted:
I was reading The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems, and I came across this quote:
Royce’s 1970 paper, which is credited with “inventing” the model, actually identifies it so Royce can criticize it and suggest improvements. He wrote it is “risky and invites failure” because “design iterations are never confined to the successive step.” What Royce suggests as an alternative is similar to what we now call Agile. Sadly, multiple generations of software developers have had to suffer through waterfall projects thanks to people who, we can only assume, didn’t read the entire paper (Pfeiffer 2012) [p. 175].
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.
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".
I remember that as well, but I think scrum lost it's advantage once it was co-opted as a metrics and management tool, and by people looking to make a career out of "managing." That's the point at which it started shifting to being imposed on the team rather than offered as a tool to the team.
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.
I believe, they are describing real world consequences of scrum/agile and how real management uses it, which might be different from what the manifesto actually hoped.
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.
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.
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,...)
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.
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.
Interesting, because I was trained in writing classes to always have a "conclusion" where you make sure to summarize and restate your thesis for emphasis and focus. That AI does this feels like a result of training/emulating what humans do. If people think my writing is AI driven because of that, that's quite unfortunate. If we have to start introducing errors or mistakes into our writing so people don't assume it's AI, that seems like a quick race to the bottom.
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
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.
Because for high performing individuals the framework doesn’t really matter? Most people aren’t high performing, so they’re designed to get the best out of the mediocre ones.
On the contrary, I’d say frameworks can’t set its claws on high performing “politically influential” individuals because they are fairly powerful. In most cases, majority people are high performers but crippled by the frameworks due to power imbalance.
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.
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.
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.
>I can't believe engineers took the scrum/agile workstyle and adopted it like that. Why didn't they vote with their feet?
They didn't. Execs were charmed by people who took a 2 day training class on scrum and told them it would streamline their development process and would save money. Since execs are incentivized by P&L, saving money gets them bigger bonuses. These execs typically have no idea if their dev team is good or not. I'm sure there are exceptions, but all the ones I've talked to seem pretty clueless; and they are the ones making major decisions.
>Why didn't they vote with their feet?
Since tech is a cargo cult; people who make these decisions have no idea what they're doing with dev, for the most part, they just ape other companies. The result is you can vote with your feet, but you'll just walk into another scrum environment.
Scrum works best when all your developers are mediocre and would stare at the ceiling all day if you didn't task them with something. It's probably not a coincidence that scrum came about when hiring cheap offshore labor was really building up steam.
> 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.
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.
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.
Wow, that's remarkable honest of them! I actually respect and appreciate that a lot more than I would some BS about it being for your own good or whatever.
Well I think that comes from top-down micro-managing organizations that just want to call themselves "scrum". They want to do what they want to do and will dress it up in whatever language is buzzword compliant.
A director of engineering flat-out told me that being self-organising wasn't part of our scrum because we couldn't guarantee that each team made the same decisions and we needed developers to be interchangeable between teams.
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.
Many engineering orgs just give lip service to scrum, which is as good as not doing it, which is good and works better. Meaning, in my experience: You work in a priority queue, that priority queue is re-synced with stakeholders (at least) once every two weeks, retros may be there as an opportunity to get other business verticals into the room to see what engineering finished recently, and the concept of "a ticket going over to the next sprint" doesn't raise blood pressure, because the system is designed for this and sprints aren't deadlines. Features might have deadlines, absolutely, but that's independent of the sprint.
I've worked at ~three places that operated similar to this; "minimum viable scrum" is a good name, or even better, "emergent scrum" because it isn't a process that's designed, its the process that emerges when someone toggles the "agile/scrum" button in Jira, but no one really cares one way or the other. Its a good process.
I've worked in one environment that was hard scrum, had scrum masters, extremely strict. To be honest: I felt almost no stress, but the company also delivered very little. There was a lot of "we can't get to swapping the color on that button until Sprint 18 in three months, but we'll schedule it for then". Missing a sprint was life or death, so every estimate got padded like crazy. When you took vacation, it was common knowledge that you needed to leave halfway through a sprint and come back halfway through another, sprint planning would basically forget about you. That (public tech) company doesn't exist anymore, and it radicalized me against agile/scrum: The entropic end-state of perfectly executed agile/scrum is an extremely well-lubricated machine that actually does very little.
Work queues are themselves an issue. Instead you should have ways of documenting things that need doing that is adaptive. For example a groomed page about all the PDF bugs > 56 Jira tickers going back 10 years, some will take a day work to even fathom. It is a big time waste. For customer communication have case tickets. But a JIRA ticket is like body fat. You burn calories just to maintain it.
We don't do scrum. We release major versions once a month, and bugfixes daily. New features go into the next major version when done, bugfixes gets released as soon as they're done.
We use Kanban boards to get an overview and prioritize work. Apart from that devs mostly manage their own work.
We're a small shop though, perhaps that's why it works well.
But is it? Everything is the same if you squint hard enough.
We do not have anything like a SCRUM master.
We don't do stand-ups, we usually don't have a per-release target for features. For example, for the past three months I've had a target of October 1st for a feature, but no specific sub-deliverables for the realeases before that. This is typical.
We don't have a separate sprint retrospective meeting. We discuss such things during our weekly meeting, even between releases (ie we don't wait).
It doesn't feel like what I've been taught and have read about SCRUM. But sure I'll agree it's closer to SCRUM than to the waterfall method.
There are plenty. All you need is a competent team that trusts each others.
I work for a huge corporation. My team plans and commits to quarterly OKRs and has a team meeting once a week to check in on how folks are doing. There are no sprints and no 2-week deadlines. Once a month or so we update the progress scoring on the OKRs.
Yes. And it doesn’t work very well. Lots of late deliveries or reduced project scopes (often still late and over budget, but mot as bad).
Increasingly, iterative models are used and those are much better. For some reason since it isn’t Scrum people still insist they do Waterfall even though they do nothing like it.
Planes fall from the sky far less than, say, some agile/scrum-based web app shitting itself constantly, which happens all the time. Maybe waterfall has its place.
Eh. Waterfall adds risk to iterative approaches, not value. Wait 3 years to do integration testing because that’s what the schedule says. The smart projects get better quality and use iterative models.
Additionally, there are other iterative models than Scrum. That's pretty much the worst one out there and its only value is to inexperienced teams needing training wheels or overbearing management that doesn't trust the team.
Even worse. When I worked in that sector, the government simultaneously mandated that we use agile methodologies, and also that we do waterfall things. Doing agilefall like that was the dumbest possible thing, because we got the benefits of neither and the weaknesses of both.
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
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.
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.
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.
> Those that actually do work, have nothing to say in these scrums. It's a fact.
There is something fundamental here.
Competent programmers make it look like they slack off and what they do is easy.
The ones who create problems that in practice only they can fix and seem blocked all the time are the ones that seem productive in an agile environment.
I guess that is the reason standups evolve into some sort of status update, finger pointing and bragging contest.
> All this imbecility does is to create competition, and weed out the ones that don't comply.
This ten million times. It's about control, and it's about showing you that the only way to be considered to be doing your job, is if you abandon all dignity, and allow yourself to be treated as a child.
The adults (POs and managerial folk) are making your planning, your regime, you constantly report to them them what you are busy with, you summarize what you learned last week and what you'd be doing today, and you present to them your paintings for evaluation. It's so degrading and humiliating, but that's by design!
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.
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.
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."
* 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).
If you are a manager and this makes you angry, you're one of the bad ones.