I can relate, the last graph is pretty much every project I worked at for the past 6 years.
There is one thing I’d like to add and it’s how frustrating the ceremonies are. I enjoy writing code, I enjoy solving complex problems, and in order to do so I need to focus.
I can’t focus if every day is interrupted 3-4 times with a standup, grooming, planning, retro, 1:1, plus some extra “Quick 5-minute sync” meetings.
I don’t want to spend an hour thinking what we can do to improve next week, just let people say what they want to improve whenever they want and we can chat about it asynchronously whenever each participant has time to do so.
As a member of senior management let me play devils advocate for what happens if we don't have these meetings:
Stand Ups: Someone says all week they are on track to deliver, they've got just one. more. bug. to fix. and then the day before the end of the sprint, they admit they were stuck all week and didn't complete and rather than pulling that feature you now can't release because other tickets interrelated. Yes, I know, your team would definitely ask for help every time, except when they don't.
Grooming: Congrats, your next sprint is now focused on a POC for something that was going to clinch a sale, except the sale has died on the vine and it is not needed anymore, or there is a suitable work around, or some education change the customer approach. Your two week sprint has added more code to maintain, and had no commercial benefit.
Planning: You did not do planning, you and your coworkers have done tremendous work and completed everything on time. His auth service uses cookies, and your UI expects JWT. Or he does server side pagination, and you implemented locally search and filter.
Retro: One developer keeps making condescending PR comments for the new developers and they decide to leave,nobody addresses this issue because who wants to call up a coworker and say they are a problem. Team because cliquey and insulting. Retaining new devs is very hard and new ideas are long forgotten. Or it could simply be you would prefer pair session to be in the afternoon while the kids at nursery or something, and this is a place to explain that.
1:1: There is no effort from your manager to grow and develop you because they don't know what you want to grow or develop since they never talk to you outside of giving tasks, you have no chance to give your manager feedback or seek explanation for wider strategy decisions. The working relationship suffer and churn increases, now you have a bunch of coworkers who are new and don't know how anything works.
Every developer loves to say about how they can be self directed and handle this in their team without the need for processor or people over seeing it and almost always that is not true in the slightest. they will avoid dealing with things, avoid communicating until there is a huge blow up and some dramatic problem. If you are the 1 in (maybe) 50 who can do all of that, what are the odds the 5 - 10 random sampling of people are all those people?
Stand Ups: Someone says all week they are on track to deliver, they've got just one. more. bug. to fix. and then the day before the end of the sprint, they admit they were stuck all week and didn't complete and rather than pulling that feature you now can't release because other tickets interrelated. Yes, I know, your team would definitely ask for help every time, except when they don't.
All you've done is made it more stressful for them to have to invent more ways to say i'm still working on this which is probably the case. In the best case scenario you've just made life harder for your developer, congrats.
Yea this seems to be a product/result of standup instead of the opposite. “Says all week” means they spent all week focused on their status. What if they only said it “earlier in the week” and used the freed up time to think through problems and contribute differently?
This is a great response. Everything in Agile-Scrum has a purpose to solve a particular problem(s). You can choose not to do steps, but something has to solve those problems else larger problems occur.
And 1:1's are probably the most important meeting. Ineffective 1:1s lead to so many problems and to even less productive meetings. They aren't 'tell me what you are doing' sessions (unless you want them to be), they are a time where the IC gets to talk about whatever they want to. Or not. I have some people that only wanted 10 minutes in the 1:1 and that was perfectly fine. But if they need a longer discussion then we have the time to do that as well.
I keep telling my director and VP that we have a lot of smart people and it feels like every process we implement is designed to get in their way and prevent them from delivering quality software quickly.
If we only had standup, sprint review, sprint planning, and retro, that would be fine. That's only 6 hours per sprint, leaving another 74 free for dev work. But it's all the other crap that distracts us from doing great work.
We keep having meetings to discuss how to improve velocity and I keep saying the same thing. Just get out of our way and let us do the work. Here's me shouting into the abyss.
At the same time, multiple people should know about different areas of the code. That one guy who's worked on the microservice? He's gonna quit someday.
There is a difference from being the expert in part of the codebase, and people not being able to contribute to estimation. What you describe typically results in single points of failure or cowboy coding. And if estimates have large variation you either need to break the task down of define it better.
Maybe you should discuss that in the retro then? If the process is keeping you from being productive then the process needs to change. It's a core principle of agile. What you describe is a company problem and not an agile problem.
It’s not easy to tell your scrum master that you don’t want to do scrum, it’d put their job on the line.
Also, some programmers do like it, I’ve met several devs who would rather spend more time in meetings than writing code. I haven’t asked any of them why.
I really don't get all the "There's too many meetings!" complaints. I have a 10 minute standup every morning, one planning meeting on the first Monday of the sprint scheduled for an hour, a grooming session on Wednesdays that's scheduled for an hour, but once the backlog is under control is rarely half an hour, and a retro on the last Friday of the sprint for an hour. How is that too many meetings?
That's an unusually light meeting load, in my experience (so far 5 years of doing scrum, across 6 different teams). I'm used to 6-8 hours per week of sprint ceremonies. My current team is 30 minute standups every day; 2x 1-hour groomings per week (and yet, somehow, I've never ever seen a backlog that's "under control," every team I've been on has perpetually been creating the stories just in time to work them like the meme of laying the track out in front of the train as it's rolling); 1-hour retro every other week; 1+ hour planning every other week (often spills over its allotted 1 hour); 1+ hour demo every other week.
That sounds like a "your company" problem. Like, 30 minutes of standup is way too much. And if you don't have your backlog under control after a month or two, then what are you doing in that grooming session?
Good lord! I've been in the business more than 20 years and a lot of it was scrum, even with ceremonies. Never ever did I have that many sprint meetings.
How does standup take 30 mins? Honest question. Admittedly, I work on a small team, but 8 of us wrap up standup in less than 10 minutes on average, with 5 minutes being relatively common.
I'm assuming it's a team where people feel compelled to give a detailed status and don't feel comfortable giving a 30 second "working on X and it's going fine" type update.
I mean, those are all the ones that are ever proscribed by the methodology. If you've got a lot of extra meetings, that seems like it's on your company.
I know it sounds lame af, but I had our 'titles' changed to Agile Enabler in our area of the business. I tried Kanban with my team and the others Scrum Masters panicked a bit, because as you say, what is a Scrum Master that don't Scrum?? Arguably even putting Agile in there is a bit redundant these days, it's not like anywhere is saying "nah, fuck Agile".
But you are doing scrum by improving the developer output. This is exactly one of the strengths and core principles of agile. If your scrum master is not supporting you in that goal, then they are the one not doing agile.
If you know exactly what to do and have absolutely no reason to interact with anyone else in the company, then it's perfectly reasonable to stay away from all the meetings. Scrum gives you as developer all the tools to improve your own experience and output, but so many developers don't understand that and many companies sabotage the efforts of those that do.
Those problems are not exactly scrum issues so a competent scrum master should be able to address them. The only meeting that appears on a daily basis is the 15min stand-up, which should give you 7h45min of coding time. Then there is grooming, but that is only collecting the requirements - you need them to start coding anyway.
If you have nothing to talk about on retro that's fine - I've seen teams that do one retro every 2-3 sprints or shorten it to 15-30min.
Every other meeting is your team's invention.
The scrum masters on my team aren’t some scrum evangelists, they’re shoved into that role the same way I am as a PO. It is actually worth discussing how the process can be less painful. Whether your org gives you flexibility to actually change that may vary. which, itself is one of the many ways they ignore what scrum says when it doesn’t match the desires of upper management- scrum teams are supposed to self organize and in part come up with their own process and refine it for what works for the team. Except when management just mandates certain parts of how it must be done lol.
I'm so tired of retros where we privately complain about all the things blocking us but we can't talk about publicly because it's all leadership issues. Of course now days leadership demands access to the notes of our retro so instead people complain about small nothing issues that we have discussed previously but then everyone intensely debates solutions to them for an hour.
Oh, you have that too? We outline our issues and when they get raised to a mamager or senior product owner (Safe sucks), it's like we've dumped them into a black hole. I've never had anyone a management layer up actually resolve an issue. They only cause problems.
They literally gave the amount of time consumed by the meetings; do you think if they were having planning retro everyday they'd only be spending 6 hours?
He’s saying he’s getting interrupted 3-4 times a day for these meetings. If your having 3-4 meetings a days as a developer you’re doing something wrong imo unless your like an architect or something. But then those will not be scrum meetings anyway.
Sprints and standups are also in place to prevent cowboy coders from running off on a tangent by their lonesome.
15 minutes per day is not an imposition. If your shop is dedicating more than that to mandatory meetings (outside of the sprint-planning meeting and the retrospective) then I might suggest they're just pretending to implement Scrum.
That's the rub, though. A sprint is not intended to be a deadline and if a company is treating them as such, then all they want are deadlines, which in turn means up-front long term estimation. No development methodology is going to fix that.
A sprint is simply meant to be a short enough chunk of time that changes can be added and a new build made. The build is the letter of the law. It's meant to be the singular thing that tells you what the state of the software is (rather than charts, docs, or promises) That's why you want shorter sprints: it's easier to estimate tasks that can be done in a shorter window and it allows for builds to be made at a clip that decisions can pivot in the time frame of weeks rather than months or years.
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. But sprints in a Scrum-like process don’t work that way.
Sprints should be team-focused. Aligning them to product goals, and not to the team’s needs and abilities, that’s what makes “scrum” fail.
I've experienced seven separate managers across three separate teams in a very large well known company, all of them do scrum different from each other, and all of them do scrum wrong. My sample size is limited, but I wonder if doing it wrong is more common than doing it right. I've seen it done right once at a different company.
I always find this a ridiculous analogy. Scrum has clear and simple guidelines on what to do, if you choose to just ignore those and then complain about scrum what are you even doing? There are plenty of companies that do implement scrum as it is written and it works fine, there is simply no development framework that will turn your shitty manager into a competent one.
How about shitheads like you who come onto threads with dozens of people complaining about scrum to tell them that each and every one of them is just doing it wrong. Ever consider that something being hard to implement correctly is a property of that thing?
Also the creator is a crackpot and you actually take it seriously lmao
Mostly because almost nobody actually seems to want to implement it correctly. Also because it is a scam designed to make money rather than improve productivity (see linked book)
Is your argument that fake scrum has caused no extra damage that wouldn't have been caused if teams doing fake scrum had never heard of scrum and did something else instead?
In my team's case, we would have just kept doing kanban and enjoyed higher productivity.
Funny you brought up that book! Some guy on this very subreddit convinced me to give it a read and said it has all the solutions. I should have known ...
Anyway I bought it and it's nothing more than techno-blabbering sale drivers.
Here's some shir - it's so overly vague that everybody does it differently. And not in the "we changed things that best fit our needs and agendas" way. In the "we all litterally interpret these super vague ass words differently."
I dare you to put 10 scrummasters in a room and get them to agree on anything outside of "How do you spell SCRUM?" Heck, ask them about the 20% and what it's used for. Guaranteed different answers from every single one.
Scrum has clear and simple guidelines on what to do
Does it? It has very vague guidelines on what to do, but how you interpret those guidelines is an incredibly wide open field. It's like claiming that Christianity has clear and simple guidelines without somehow noticing that there's thousands of sects around the world that disagree on what those guidelines are.
The scrum guide is nonsense. People will make small tweaks which actually improve their experience but according to the official guide they are not doing "real scrum". Therefore, scrum is quite obviously not about being an effective process, it's about making money.
Do you legitimately think it is impossible to improve even a single aspect of the scrum guide?
Well how about this. In 2011, the scrum guide was modified to no longer use the term "sprint commitment" and now uses "sprint forecast". Since pre-2011 scrum did not follow the current scrum guide, was it not actually canonical scrum?
If people successfully applied pre-2011 "scrum", were they lying, or would their team have also worked well without pre-2011 "scrum"?
Now just extrapolate this to a theoretical change to the scrum guide in 2025 or 2026 which invalidates the version of scrum you are currently using.
I didn't say scrum is perfect, I am just saying the vast majority of complaints are things it literlly tells people not to do. I don't think peoples complaints was if it was called a forecast or a commitment, although forecast is indeed a way more accurate term. For that matter I think sprint is a mediocre term and "leg" or "stage" would be a better term as nobody runs a marathon by continuously sprinting.
Sounds more like a straw man? A cleaner NTS argument would be like:
A: "Mac and cheese is delicious"
B: "Kraft dinner is gross"
A: "Real mac and cheese is delicious"
The fallacy is in rejecting that KD is mac and cheese. It definitely is what some people mean when they say mac and cheese. It's not a fallacy to clarify/admit that it might not be delicious under that circumstance. The fallacy is insisting that the counterexample "doesn't count".
It's just that most of the time when people say scrum doesn't work because X, X is not according to the Scrum guide. "business folk" talking in the daily scrum is explicitly not OK according to the scrum guide, you're not reporting "status" - that's genuinely not the point. I'd love to collect some of these and put the relevant scrum guide stuff next to it.
A: Mac and cheese tastes like shit, the cat poo in it is awful.
B: Real mac and cheese without cat poo is pretty delicious, it is a lot better when your boss doesn’t add cat poo
A: No TrUe ScOtSmAn, real mac and cheese has never been tried
I worked for a company who sold Agile Software (long before JIRA did) and even there we eventually gave up on Scrum and went to using Kanban for the development teams. Scrum is great when you have lengthy release cycles like we did 20+ years ago. But in today's modern engineering orgs where we are trying to get stuff into production as quickly as possible (even behind a toggle) Scrum just breaks down and the process gets in the way.
How short are your cycles? We're getting stuff into prod daily.
The point the person is trying to make is that the sprint cadence doesn't match the release cadence, so the extra "stuff" to support it gets in the way.
Our team's big issue was the below simultaneous expectations:
The sprint must be fully loaded at the start
All stuff loaded into the sprint must be done by the end of the sprint
Any "extra" stuff identified for the work and not fully defined must also be done as part of the work loaded into the sprint
If you actually do get done early, you must pull something new in...and that must also be done within the sprint.
These expectations were driven by our product owners and they would not budge. If we weren't getting every single thing done by the end of sprint, we came under fire. If we pushed back and said that that extra thing they just thought of or noticed that wasn't part of the acceptance criteria after we finished the work needed to be a separate work item, we came under fire. If we pull something in because we finished a day early but didn't get it done by end of sprint, we came under fire.
In the end we finally just said we would no longer be pre-loading the sprint. We would pull work in as we went, and the sprint would be used to calculate velocity and as a marker for other activities. Things got a lot better and less stressful.
This situation and your subsequent replies in this thread are so relatable. There are similar feelings from the team’s developers so I hope try to convey some of your offerings here to, at least, try to start a conversation.
I agree. The problem was that the engineers had little control over those decisions.
I think if we took the control over what was loaded into the sprint and what constituted sprint scope and put that into the hands of the engineers then things could play out different.
Another thing I didn't list above is we were forbade from calculate our sprint velocity based on PTO. POs found us doing that "annoying" and felt it wasted their time so they would stop us from doing it, forcing us to commit to the same sprint velocity even if half the team was gone on PTO.
If you want to do weekly releases (or even daily) it is almost impossible to follow Scrum. It cant handle the fast release cycle properly because it is built around the fact that you bundle multiple sprints into a single release train. Thats why you spend so much time doing story points and capacity planning. Its also why you need burn down charts to help you get better at your planning regimen.
Kanban is a superior workflow for development teams with sub-2 week release processes.
Those are bad comparisons to the case here. That's the point they are trying to make, but since there are teams that have made Scrum work it is pretty silly to say Scrum cannot work (even though the original user said "Agile" instead of "Scrum" so who knows what they meant).
Oh the first contract is coming to an end and they haven't done shit to improve our processes yet? Well we spent so much money on this contract, we HAVE to extend to get our money's worth!
Really more of a false attribution fallacy - just because management does the same dumb top heavy shit and calls it "Agile" doesn't mean it is. Just because North Korea claims to be a "Democratic Republic" doesn't mean it is.
Half of these aren't true scotsman arguments. You need to make a claim ("Agile ships products faster"), a counterexample ("My team shipped slower using Agile") and then you pull out the fallacy ("Real agile ships products faster").
The vegan one doesn’t fit, that's just gatekeeping. The other ones could fit depending on framing, but the general statement that "Agile works" is kind of hard to refute. It has advantages and disadvantages, the meaning has changed a lot over time, there are lots of flavors and degrees of seriousness, but overall I think it's pretty uncontroversial to say thr movement improvemented software development as a while, even for people that only sort of follow it (i.e. don't). Go back and read what people were saying in the 90s if you weren't working yet then. It was a lot worse.
No work added to a spring during a sprint, story points not tied to time but to velocity, velocity not being molested by manipulating points mid sprint (i.e. tasks are all or nothing, because it will average out, and pretending you did half a task or whatever taints the original estimate in favor of inflating that Sprint's velocity rather than accepting that some sprints will have more points and some will have less) actually maintaining a prioritized backlog, letting stand up be stand up not status, using the concept of a parking lot.
On top of this, it was an embedded product with FPGA images and firmware to go with it, which is probably the hardest type of project to manage with scrum in the first place. We all spent a week reading a few chapters out of a book, and tailoring the process to our needs, so we were all on the same page. The only flaw was setting future deadlines based on velocity without accounting for obvious buffer that we said would be needed for unknowns, but if we had accounted for that, we would have delivered a solid product on time.
If I remember correctly we still got it done on time, but they made us work overtime without extra pay to do it for a whole summer in a state where summer is short and winter is long. So I left the company because management punished the engineers for not meeting the deadlines the engineers warned them would slip on day one.
In my current role, story points are half day time units, we are pressured to under estimate and under deliver, we're encouraged to subtract points on tasks every day despite meetings consuming 70% of some days and we may not even touch sprint work, work is added mid sprint, estimates are changed mid sprint, and standup lasts an hour because it's a status meeting. Also the tools we use suck. Anyone who hates JIRA has no idea how much worse it can be.
Thanks for the detailed answer and sorry to hear the current situation.
Do you remember the book you read? Would you recommend it to a young company with 6-8 engineer struggling to properly implement scrum-based development?
How did you estimate story points? Did you account for the fact that a (time) estimation heavily depends on which developer works on a task?
On the estimation side of things we started with 1 point being a task that could roughly be completed in one day or less, and used Fibonacci numbers from there. So if you felt like it would take 4 days, you estimated 5. Anything 8 or more we would try to break down if we could, but sometimes things are just 8 when you're not working on simple stuff and that needs to be okay. The important next part is, even though the estimation was made in relation to time, the evaluation of sprint points is not. If an individual velocity is 5 points per sprint even though you would expect 10 based on the time estimate, you would only add 5 points worth of tasks. If that developer finishes early, great, they can help work on other tasks. Or this is the one case where it's okay to add tasks, basically when a dev is out of tasks but other tasks are specialized so they can't meaningfully contribute. The other thing is, if individual velocity is lower or higher than others, rather than saying that person is performing differently, management needs to recognize that they're estimating differently. You really can't neasure performance based on how many sprint points a person completes in a sprint, because it lacks all the information about an individual such as how many meetings they need to attend, how much of their time is spent helping others, the quality of their deliverables, and their overall impact on the team. A good manager can see these things without micromanaging and without relying on individual velocity. A good manager recognizes that engineering is full of unknowns, and estimates are inherently difficult. A good manager understands that velocity is a tool to get better estimates, not to measure performance. And most importantly, a good manager trusts their engineers to be honest with their estimates. Be careful asking why a task is larger than you think it should be. If you think that's the case you can discuss it and suggest breaking it down, but don't ever override it, otherwise that person's velocity becomes a reflection of your estimates instead of theirs. (Specifically in the case of estimates being tailored to individuals rather than the team)
Backlog grooming and estimation should still be done as a team, sometimes when I would estimate my tasks I wouldn't really know how much work it would be, so I'd look to a more senior engineer and ask what they thought and go with their estimate. But the estimate still takes into account who is doing the work that way, and team velocity is still a meaningful reflection of how accurate estimates are, which can be used by management to estimate delivery dates. If dates are too far out, remove tasks or add people, don't ask people to lower estimates because that becomes dishonest and breaches trust.
The book we read (and I think we only did the first 5 or 10 chapters, it's been a while) was "Agile Software Development with Scrum" by Ken Schwaber and Mike Beedle
Most important, everything I said and everything the book says are suggestions, if your team disagrees then agree on something else.
I'm a fan of kanban when management doesn't understand scrum, because it gives management visibility into what people are working on but doesn't waste engineers time on sprint planning and retrospectives which lose value if not being used as a tool that puts engineers first. The downside of course is it makes estimating dates very difficult for management. Personally I've always thought two week sprints are too short, so you can play around with that. Maybe start with two weeks for a few months so you can get some retros in and fine tune the process, then switch to 3 or 4 week sprints to avoid wasting time with too many sprint related meetings.
I also really prefer standup to be only two or three times a week, if an engineer is blocked they should feel comfortable reaching out over slack or in person to get un blocked. A compromise is to do virtual stand-up on the off days
It's also really helpful if upper management is on board, in our case the directive to do scrum came from the CEO, and everyone in the engineering chain read the beginning of the book, so we were all on the same page. That way my manager's manager knew velocity wasn't a metric to track my team's performance, and let it be a tool for the engineers and direct manager to improve estimates, not to measure performance or squeeze deadlines. There will always be some push from upper management to track velocity, so it's also a front line manager's responsibility to push back on that and remind upper management that's not how it works, and their job is not to manage engineers, that's what the front line manager's job is. If they think they can do it better, then they should be the front line manager.
Just like in engineering, you'll have senior engineers that can do a better or faster job than junior engineers, but their job is to grow the juniors, not to do the work for them. Upper management needs to trust lower management, and provide guidance and tenants and mentorship, not do their job for them. Especially because engineering management is a much more fluid type of job that deals with people, not code, and every team's needs are different
This is very helpful. Thank you so much for taking the time for writing it all down.
Since you are talking about individual velocities, do I understand it right that the estimation definitely always takes into account who is going to work on a given task?
So at the spring planning meeting, you take the highest priority item from the backlog, assign it to someone and have that person (with the help of the team) give an on the spot estimation. Repeat until everyone reached their personal velocity average. Or did I misunderstand?
So far I was under the impression that estimation would happen earlier, while grooming the backlog, and then during sprint planning you add the amount of items corresponding to the team velocity. And that the assignment is a bit more flexible, with some items assigned during planning, others staying unassigned until someone takes it on.
Is everyone's individual velocity public knowledge? Does this not result in a sort of leaderboard? And do the individual velocities not drift apart completely overtime? If someone overestimates and then over delivers by 1 point every sprint, they will have a velocity of 35 after a year.
I will check out the book you recommended, thanks!
If something comes up in standup that requires discussion among three or more people, instead of discussing it immediately, you put it in the parking lot, i.e. make note of it and move on. At the end of the meeting, anyone who doesn't need to discuss parking lot items can leave, so the discussion doesn't waste anyone's time
I have the same experience. Scrum was always done, in some form, to appease clients, bosses and managers, never about the team's work. Always to show what's being worked on to the PM and managers.
Kanban is all the management needed, 90% of the time. The best project i worked on was managed in kanban and had competent analysts and PM that identified and broke down the tasks amazingly. It was very satisfactory to close 1 or 2 cards every single day and see everything going well.
From what i've seen it is based on agile concepts, but also, anything that involves efficiency tends to be lumped into agile, and it was conceived in the 40s, before agile if i'm not mistaken.
Also, is it not a method instead of a framework? It's just a way of managing tasks, without any rules about meetings, deadlines, etc. Scrum is a framework in this case.
Kanban predates agile but it fits neatly into the principles of Agile with only a little bit of tweaking. I don't think there's anyone who would say it isn't agile. It's important to understand that the [agile manifesto] (https://agilemanifesto.org/principles.html) says nothing about meetings or deadlines, or any of the things people hate about scrum, and basically boils down to "be flexible'.
Whether you call it a framework or a methodology is just a choice of words, a framework is just affixing a set of rules to agile principles, in kanbans case that's the progress board.
Yes. Although, if you read other comments, the majority of scrum/agile is wrongly applied, so you get a correlation almost 1:1. In other words, hating micromanaging becomes hating agile in the real world.
doing it wrong is more common than doing it right.
Doing it right means standing up to leadership and protecting your developers.
I've only seen a couple of project leads that were good at that in my career. The rest of them cave and come up with absolute ridiculous features or changes in direction every two or three months.
Doing Scrum right is challenging. It requires a really good product owner that can effectively talk to the dev teams, product, and engineering leaders. TBH I've never seen a product owner qualified enough to do this. Anyone who might be qualified enough to do this ends up going into engineering, product, or management, since those roles are much more plentiful and companies usually know how to handle them better. Largely because of this most teams do Scrum wrong.
In retrospect I think it's interesting that so many companies focused on hiring professional Scrum masters, which is largely a useless role and ignored the role of product owner, which is the much more important leadership role in a Scrum team.
Yep. This article is the same as every other anti-scrum article. Scrum is bad because . The last bullet that scrum is bad because it is also waterfall just proves that point.
Bad scrum is bad. To varying degrees every bullet point of this article could be used in a pro-scrum "how not to implement scrum" article.
Without siding with anyone, in my opinion this debate just rages on forever:
A: "My experience of this system is bad."
B: "No you are just doing it wrong, if you did it right it would work."
A: "But the majority of people's experience with this system is bad. So it clearly has large problems and it isn't just me."
B: "The majority of people do it wrong. So the majority of people have a bad experience."
A: "If the majority of people get it wrong in the real world, isn't that also a fundamental flaw in the system that makes it bad?"
B: "The system itself is good, it's just the teaching of the system that is bad."
...etc. It's like people who argue about whether true communism could work in the real world. Just for laughs:
Yep. This article is the same as every other anti-~~scrum~~communism article. ~~Scrum~~Communism is bad because . The last bullet that ~~scrum~~communism is bad because it is also ~~waterfall~~authoritarian just proves that point.
Bad ~~scrum~~communism is bad. To varying degrees every bullet point of this article could be used in a pro-~~scrum~~communist "how not to implement ~~scrum~~communism" article.
Except almost every instance of people "doing it wrong" boils down to a lack of management buy in. I don't know of a single system out there that would stand up to management not buying in.
The question is: Are bad scrum implementations the majority or the exception. By my personal count the non agile, worst of both worlds waterfall BS ( I am looking at you SAFE) are the clear majority. So the point would be „scrum failed because it/we/„the community“/„corporate world“ was not able to convey its concept“
Are bad scrum implementations the majority or the exception.
I wouldn't be shocked if they're the majority, because
Scrum isn't really that well-defined. (A bit more than agile, but not terribly much.) Answering "is this a good implementation of Scrum" is partially subjective.
Some managers are incentivized to say, "yeah, we're totally Scrum!" when they aren't. It makes the team look modern, which attracts both staff and clients. Conversely, managers aren't generally incentivized to actually reflect on what makes for a good Scrum implementation. Staffers may leave; clients probably won't (they, too, often just want to tick a checkbox). Higher-ups tend not to care.
My idea was to figure out if i can clarify one typical friction point:
Are developers allowed to pick² lower priority items from their PO's backlog: yes or no?
I just looked into the official guide pdf, page 8, sprint planning.
Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint.
First gut feeling: "yes" because selecting implies that devs are allowed to make a choice.
But, little bit above it states the following:
The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal.
So even when developers are allowed to select items, the PO is supposed to ensure that they only discuss his most important items. => Now my gut trends towards "maybe". This could be interpreted as the PO ensures that they discuss prio 1-5, but they are still allowed to select prio 1,2 and 5.
But what if the clever PO decides to discuss only prio 1-3 because he knows that those items reflect his teams capacity? Suddenly my gut feeling trends towards "no", because the PO is allowed to force that condition.
Keep in mind that this is a typical friction point because in many teams the PO ranks above developers. In such cases it will will be usually interpreted in his favor.
Have I overlooked an important passage that clarifies the ambiguity of my simple question?
² I avoided the term pull. If the answer is no i would interpret it as push.
Keep in mind that this is a typical friction point because in many teams the PO ranks above developers. In such cases it will be usually interpreted in his favor.
Have I overlooked an important passage that clarifies the ambiguity of my simple question?
No, your friction point is one of the problems in many "Scrum" implementations. The planning should be a consensus-based process: the PO has a better understanding of priorities and value while the developers have a better understanding of costs and technical tradeoffs. They can only decide on a good increment by working together. You can also see this in the order shown in the guide:
First, the PO proposes how to move the product forwards; the team as a whole discusses how to make that into a goal for the sprint
Only then, based on the sprint goal, the Developers decide which tickets go into the sprint.
So there's no "PO decides you have to do these five tasks", and also no "Developers choose the five tickets they enjoy". Instead, professionals based on their different perspectives plan a path forwards.
The question then becomes: if you have professionals that are competent enough to do that, do you still need Scrum?
The question then becomes: if you have professionals that are competent enough to do that, do you still need Scrum?
IME: nope.
Pretty much every place I've worked at either had Scrum forced on them due to management and did it badly, or moved away from it in the direction of Kanban, and the delivery quality only improved.
The best use of Scrum is training wheel for corps that are still stuck in the past, but have the management and devs willing to learn to do better. But in 2024, that doesn't match many places.
My PO says, "here's the priorities". A dev says, "hey we need to do X for reasons A,B,C.There's some discussion. It's decided to bring X into the sprint plan and kick Y out to next sprint.
It's collaborative. The team decides. The team commits. The PO is not an authority figure.
When you note that scrum isn’t that well defined, are you thinking the official guide should go into more concrete detail? https://www.scrum.org/resources/scrum-guide?utm_source=google&utm_medium=adwords&utm_id=psmii&adgroup=%7Bgroupid%7D&gad_source=1&gbraid=0AAAAADyZLu9TvsftaouibeUngUtb66ZMf&gclid=Cj0KCQjwrp-3BhDgARIsAEWJ6SzoDid-eEDEWjun8xtbesBgoumE9dDimyRdXCfULK3ie7jAB_Rg2VcaAqIhEALw_wcB
I think you can not define it better as the agile manifesto already did. Because if you didn’t get the idea or „mindset“ by reading it, everything more going into detail just leads to that check box thinking.
I think you can not define it better as the agile manifesto already did.
You absolutely can. Scrum is not defined by nor part of the agile manifesto, but instead a standalone methodology with a [readily accessible definition|https://scrumguides.org/scrum-guide.html].
It's bad if you follow it to the letter, too. For some reason, this critique isnt allowed though - every time I challenge it on the basis that I tried it correctly I get subjected to the no true scrumsman fallacy.
The whole concept of sprints is dumb - it encourages mini waterfalls. It's better to scrap the whole thing (i.e. kanban) and incrementally move to a process of continuous delivery.
Id argue that this often isnt a problem and that actually you should probably embrace changing priorities based upon new information.
Sure, but you should allow some inertia to filter out high-freq noise.
The Navy doesn't recruit a new Sailor each time the 350,000+ billets is incremented by 1 or 2. It smooths out changes to the list of billets into a personnel authorization that is updated no more than twice a year, to give the rest of the people people a stable demand signal to target.
Similarly you don't actually want to swing wildly to chase good-idea fairies whenever they present themselves. Sometimes the change in priority is to revert back to the old priority.
I hate Scrum and still agree with the need for protection from stakeholders. I've worked at places where leadership came every morning with their unfiltered thoughts on world domination. It annihilated the team in 6 months.
Which comes down to what you're saying here. It's at a much high level of sophistication than what most organizations will afford devs. So I think Scrum in some part was trying to do it as a hack, and then backfired.
In my experience it's usually because this stakeholder doesnt agree with what the other stakeholder changed them to yesterday, or because they got a random idea on their commute this morning.
Of course you can finish your current ticket, provided of course you can do that and the new one today.
In those jobs Scrum would have been a big improvement. Now I have the other problem where no stakeholder feels any urgency at all, it's much less fun.
Naw, sprints are the mechanism of ensuring that problems are appropriately broken down, that progress can be shown to stakeholders to get timely feedback, and that you stop and reflect on where the project is going frequently, the good and the bad.
If you can do those things without timeboxed sprints then more power to you. Bu tthe problem is that people often think they are doing a good job at those things when in reality they are not.
If you are using sprints as a shield from changing priorities then you are using sprints ineffectively since that is not what they are for, and why sprints don't solve the problem of changing priorities.
Those other things dont need the time boxing of the development work. You can plan meetings for them every x unit of time independently of the work, or you can show progress every time a story is completed, etc. Sprints really were invented to provide some sense of stability in the work load, that the to do list couldnt be changed more often than that.
Scrum ensures that no hard work which cannot show progress within two weeks will ever be done, and promotes low quality work which can be rapidly pumped out to indicate productivity to managers.
You can plan meetings for them every x unit of time independently of the work,
That is a timeboxed sprint. You set the timebox, then you determine how much can go into the sprint.
or you can show progress every time a story is completed
Or you can group them together to make mini-goals...but then that is a sprint.
Sprints really were invented to provide some sense of stability in the work load
They are pretty terrible at doing that. If your roadmap is changing that significantly every 2-3 weeks you have a larger problem that sprints cannot fix.
Absolutely, with a correctly communicated limit. If they want to change things every 2 weeks, they see in the sprint log exactly what they're getting/not getting.
agile != scrum. Agile simply means embracing changes during development, contrary to waterfall where you plan everything in advance and then execute.
You can be agile without doing scrum. To me scrum is bad for three reasons: one it take away responsibility from the developer, that is only focused on the activity it's doing, without a full overview of the project. I tend to feel it as a form of work alienation, the same way it was the series productions back in the industrial revolution, you only do your piece, not caring about everything else.
No matter if the project would have needed a refactor, that would have made things worse, just look at your piece of the job and done, if you "loose time" improving things, that later will make you save time in other activities, you are a bad worker since you didn't complete the activities in time, no matter if the developer that came later got a big speedup for the work you did, this cannot be understood by managers (even managers that have programming experience in the past!).
The second thing, and I see the article describing it perfectly, is the fact that scrum is used to make pressure on the team. Pressure that results in cutting corners, writing unit tests? There is no time, otherwise you don't complete the activity they assigned to you in the sprint and the manager is not happy. Writing documentation? Are you kidding? This often lead to poor code.
And finally, there is never time to learn new things. All you have to do is do stuff and deliver. No space to improve things, no time to test out that library, try to see if that design pattern applies, if that refactor will give you a benefit, if the performance of that algorithms can be improved. The important thing is that activities are done in the board, nothing else.
I often get asked by my manager "what you are working on? You don't have any activity assigned!". I have to explain that yes, project may need work even if you don't have specific activities. Do you do oil changes on your car, or only take it to the mechanic when it breaks? Software is the same.
Sometimes having "spare" time to just look at a project, see how it can improved, make experiments, it's essential! With scrum if you have spare time the next sprint they say "well, so this time let's just assign to you more activities, since you finished earlier".
I don't like this. Fortunately I'm in a company where I'm in a position where they tollerate the fact that I don't follow the procedures, just because I'm the one that are there to fix the problems when they are there. Problems that by the way are often to me derived on the scrum development methodology, the result of a constant pressure of going faster.
Whenever we get to the point where we toss aside some of the parts of scrum/agile that would be nice it’s because of the same old business demands. Are we confident this sprint? Well no, we need to do twice as much as our velocity normally is to meet the release deadline that is driven by some pdm wanting to announce something at some tech event. Can we re plan the sprint and release to meet our normal velocity and not have people crunch? No we cannot. You’ll get pizza after everyone crunches to get it done!
I show PM the quality triangle fairly regularly and ask them to say - usually on recorded meetings or in writing in public chat channels - where they want me to cut.
Bad scrum is bad. To varying degrees every bullet point of this article could be used in a pro-scrum "how not to implement scrum" article.
At a certain point, after reading about (and experiencing) endless instances of scrum not being implemented correctly, and not ever hearing about (or experiencing) a single instance of it being implemented "correctly", the rubber has to meet the road.
Someone else mentioned No True Scrumsman and it fits wonderfully here, if the majority of Scrum implementations are bad then Scrum is bad. It's constantly excused for its shortcomings with people claiming that it's just not implemented correctly.
At what point do we acknowledge the emperor has no clothes?
I honestly thought scrum went out of fashion years ago. In the last 5 or so years ive just done kanban and the amount of talking about process has gone way, WAY down (thankfully).
Im really surprised to see people still defending scrum like it's 2012 or something.
My team is forced into the nightmare Jira implementation of Scrum + management misunderstanding. We have fractional story points where 1 point is 1 day - point completely missed. I have never found story points particularly useful anyway, but this makes it worse.
Even "better", our tooling and workflows are tied to Jira tickets. So splitting ongoing work across sprints is really painful because the ticket number flows through into branches and builds and test deployments and more. But Jira won't let subtasks be put in sprints. So I often have a ticket for the workflow and other associated tickets in sprints for the work.
The saving grace for all this is that my manager and the immediate upline don't care about the formal process. Only what works, and what we can get away with within the framework imposed on us.
So we land up doing something closer to kanban much of the time. Sprints are fluid, we pick work from backlog as needed, we shuffle sprint scope as needed, and we manage our own priorities under overarching goals from product.
Nothing stops me from noticing a low priority but annoying issue, opening a ticket and fixing it on the spot if it's small enough to count as a "just do it now" item. And I'm rarely if ever questioned on my ticket queue and board, except for "why is that blocked and do you need help".
people don't flock to message board to talk about when things are running well. I don't personally think scrum is a good system, but "everyone complains about it online" isn't the condemnation you think it is.
The fundamental problem is most people are just bad at running a team. It is a hard and difficult problem that requires a lot of knowledge and discipline to get right.
What makes it more frustrating is people are often good enough that it becomes difficult to point out their flaws and get them improved.
As I am getting older I am coming to the opinion that even more innately, it ultimately comes down to the roll of the dice on personalities.
Right there with you on this one. I think there's loads of truth to the whole topic of "personalities". But people take it the wrong way and read it as "in order to succeed, I need people most like myself".
Reality is, it's going to be more about how disagreeable and intuitive your people are than how well they can coexist. Though I might add the caveat that coexistence is still a pre-requisite, haha.
I heard it said before (and I subscribe to the idea) that people unconsciously seek to create environments in which they would thrive. To me this explains a lot of the nonsense at work when I think about who seeks out authority and gets into positions of power in most work environments.
I’ve worked with people where they are willing to try things, give feedback respectfully, and if it doesn’t work it’s fine. We do something different and move on. Those teams were great and productive, and we received a lot of great feedback.
Then I’ve worked with people who just fight and disagree. They don’t intend to be an asshole. They just have a counter point for everything. Sometimes it’s good, but often it’s a constant uphill battle. Everything takes five times longer to get moving. Ideas are not tried because they can’t be proven to a high enough degree. Those teams did, at best, fine. But never great.
Those teams which did well often had engineers who wanted to do a good job. But it was just a job to them. Not life or death. So they would be pretty chill.
What interests me is how many might take all of your points and generalize them or look for soundbites.
For example "pretty chill" is often interpreted as first-order, after "skill". So then places might come to assert that their best talent can only be the least-opinionated. Mainly to ensure that other talent doesn't feel inadequate. But then they struggle with technological execution because their senior decision makers are too politically motivated to avoid picking directions.
It also factors into the inevitable situation where someone says "it doesn't have to be perfect" vs "it still needs to be good".
These are subtle distinctions and I don't say any of it to disagree. You still need people who are willing to try things rather than sit and snipe from the sidelines constantly. But it's interesting to think about the messes we get into when people avoid thinking on their feet.
The thing is, what can you organize in a two week period ? unless a great team with zero friction you'll only pile up thin layers of low skill value and potential soon-to-be-debt.
I feel worse doing that than learning haskell all alone. So weird.
It’s about communicating to non-engineers what the plan is. And over time you get better at it. Furthermore it simply doesn’t matter what you do unless leadership values and trusts what engineering (not product) says.
I look back fondly to a company that successfully implemented Agile / Scrum bc we had a chief digital officer who believed in it and empowered everyone to follow its guidelines. Product was also wrapped up under engineering so it worked in our favor. IMHO, every point people are talking about reflects the people and not the principles.
that's the issue, it's very subjective in the end. Many times people said no matter the methodology, what matters is the quality of the team (skills and ability for team work).
In typical business development there isn't a lot I can't break down into sub week chunks. Even if sometimes it's "research the thing," "test alternatives for the thing," "select the thing," "do a crude proof of concept of the thing," "do the thing reasonably well," "finish remaining tests and documentation," "polish the thing".
The danger of course is that the earlier bits slip and the later bits get cut. But I build docs and tests into the whole process to mitigate that.
What you’re describing sounds a lot like Spikes, which you can time-box and evaluate. You’re also basically talking about iterating, which is a guiding principle of Agile that you’ve used different words to describe.
It sounds like you have a lot of autonomy which is great, and it would be interesting to know where the bottlenecks arise for you.
I applied agile/scrum correctly in one job and it was successful. Until the company hired a product manager to the level of director and suddenly I had to start using Ms project to make waterfall style projections and that’s when everything went to spit. Moral of the story is companies don’t like dynamic and productive teams. They just want fancy charts because they have their own insecurities.
To me this is the core problem with agile. Almost every one is doing it wrong.
This is like a religious warrior telling his troops that their faith will make them bulletproof; then he tells the survivors that they were the only ones with enough faith.
When nearly everyone is doing a system wrong, then it is the system, not the people who are the problem.
For example, you should never mix a chlorine based cleaner with an ammonia based one. Many fast food places had idiots mixing the two on a regular basis with tragic results. So, pretty much all fast food places now mandate that only very specific cleaners be used. These can mostly safely be mixed.
They didn't blame the cleaners, they didn't blame the workers, they just made a better system.
Agile is like having ammonia and chlorine cleaners. Properly used they are fantastic and between them will clean almost anything very well. But only if exactly used correctly.
When nearly everyone is doing a system wrong, then it is the system, not the people who are the problem.
And I disagree. When Management refuses to buy in, then that's purely a management problem. I've never seen one methodology that would stand up to management, and I don't think it's fair to blame the methodology for what are very, very, very clearly management issues.
They didn't blame the cleaners, they didn't blame the workers, they just made a better system.
When management is the problem, then what's the better system?
But only if exactly used correctly.
No. It's when developers are in charge of how they work. I don't think that's an "exactly correctly" situation.
But, most bad managers instinctively realize that information control is power. So, they play their cards close to their chest. They only give out what information in dips and drabs
That's a fucking management problem. You cannot, in any semblance of good faith, blame that on whatever methodology is being used.
Again, ignoring the intelligence of the programmers.
Agile literally says that the programmers should be the ones in charge of how they work.
I'm very sorry that you have shitty managers. But the blame for your issues lies solely with them.
My argument is a bit off what you are saying. I suggest that bad management encourages bad agile.
But that good management results in teams which don't use agile.
There really is no good agile, just some ideal that nobody reaches other than dogmatic puritans; who work for bad companies which allow for dogmatic puritans.
Most places I've seen doing agile follow roughly this formula:
A manager dictates what the next sprint will entail. He theoretically consults with the team, but any disagreement with his decision is unacceptable.
A collection of tickets is put into jira and assigned to people. Every morning they are badgered to see if they are keeping up.
Seeing the estimates are crap (as most estimates are) the worst estimates mean some people get bogged down. They are now harassed at every "standup". I don't mean stalled, just, the complexity is much higher than anticipated and it just will take that person more time. There is no outside help/etc for this.
The scheduled sprint end is approaching and the manager starts larding on pressure to work longer hours.
The sprint is done, and the next sprint begins without relent. Sprint after sprint after sprint after sprint.
There is no real room for experimentation, for architecture rethinks, for tech stack rethinks.
Whereas a company with a healthy approach has teams of programmers where a leader has imparted a vision. This is what needs to be accomplished. There is a back and fourth with any clients and the leader to refine this vision until everyone is clear as to what and why the vision is good.
Then, the team is sent on their merry way. They can use waterfall, they can use napkins, they can use agile, whatever the team is comfortable with and wants. The leader vaguely monitors what they are up to. This validates they are sticking with the vision, and that they aren't stuck. The leader primary runs interference from those who want to ruin the project, and obtains any resources they might need. There is usually an agreement that the system chosen by the team will provide enough visibility to allow the leader to easily report progress to the executive.
For example, jira might have a list of requirements broken down by section, functional module, etc. These requirements might move through various stages, architecture, design, development, testing, and deployment. Once glance at the project system (can be jira) will allow instant visibility for anyone to see. They can perform whatever metrics they would like. A simple one would be a graph showing the requirements completed per month.
If the team realizes their tech stack is a dead end, then they can throw crap out and restart. That is up to them. The leader will settle disputes between the team, or different teams. Maybe one team wants to communicate with XML, another json, and another in some binary reflecting structs. This is where the leader will act as a supreme court, hear the case, and make a decision.
A leader like this can run many large projects simultaneously. This is where you can instantly detect someone is a manager, or even a micromanager. If they are having regular meetings with the team, and can only handle 2 or three projects at a time, then they are a micro manager. If they are comfortably handling one or two dozen projects with nobody below them acting as a manger, then they are a very good leader.
Most agile projects have a hard core micromanager running them.
People might scream. "But that's not proper agile" The reality is that it is how most companies do agile, and something is wrong with agile that it gravitates to micromanaging programmers and not giving them any autonomy other than in extremely narrow and highly constrained situations.
Exactly. Company culture is going to dictate how well their development works. But, there is a grey area where management is so so, enough that they would not actively push a bad system, nor push against a bad system. This is where bad managers/leaders can pick agile as their favourite micromanagement solution.
I hate when a company makes me have to become a crooked accountant in order to be successful, and that's what happens about half the time when you need a major architecture change for a project. You end up 'embezzling' to take time from other tickets to make progress toward an epic that's small enough and simple enough to get approved. Even a spike sometimes only comes after you've softened a target by doing things you were specifically not asked to do, or specifically asked not to do.
Unfortunately there is actually something to the idea that arbitrary deadlines decrease the rate at which projects expand to fill the available time. Early in the project we are so eager to add one more thing to a design, either our idea or someone in business, because we have plenty of time to make it up later. But later never comes.
Do I resent it a little bit that I now think this way? Yes, yes I do. But is it wrong? Maybe (hopefully) by degrees. But no.
Well, at least for me, it's all about managers feeling like they have control of what's being delivered. Everything agile flavored at my company feels like another hook for micromanagement to grip. And that starts to play in performance review and promotions. I should find one of these miracle jobs where agile actually works for the devs and not just management.
The original Agile manifesto was fine. It was really lowercase agile.
The problem is everything built on top by the consultants and micromanagers, which they call uppercase Agile.
Scrum was created before agile, and was never an agile methodology. They just shoehorned them together.
Turns out, if you actually focus on individuals and interactions over processes and tools, and if you focus on actually working software over planning bs, you actually get somewhere. That's literally me paraphrasing two of the bullet points.
But scrum and Agile and so much other bs is the direct opposite of that.
When I worked in scrum environment, the most annoying part of it was that there was so much focus on the burn down charts, and that it didn't have a stead decline over the spring, but fell only the last 2-3 days of the sprint. So the stakeholders/product owners kept bugging the developers about that. The focus wasn't on what was being delivered, just the charts.
Then there was a lot of issues with more things that was put into the sprints, but it was just hand-waved away each time we questioned why we didn't aborted the sprint and did new sprint planning as our "contract" for working with scrum was detailed...
It's depressing how many teams I have been on where people can't pull work into sprint because it will mess up the burndown chart. The managers would rather you do nothing than upset the chart or they tell you to secretly work on it without pulling the card in.
In a certain letter of 'the law' you're not supposed to put something into a sprint if you're not confident you'll complete it. But it is rather silly how often we finish what we have for a sprint, don't want to pull in the next item, lest we get yelled at if it then 'slips' to the next sprint.... so someone just quietly starts doing the work for that next story, today, this sprint, but doesn't actually put it in the sprint.
i still don’t understand how anyone can be reasonably expected to predict what they can or can’t get done in an arbitrary block of time. i feel like you either overshoot or undershoot by a wide margin.
that’s the problem. assign me something trivial? it’ll probably take a day or two. assign me two things that are trivial? a day or two times two. for another one? a day or two times three… see how things become less certain as more items are pushed into the queue? unless things go absolutely perfectly over the next few days (meaning i don’t get stumped on anything, other parts of the project are available and work as expected, client is available when i need them to be to clarify something, etc), there’s a high likelihood that schedule full of easy and trivial things starts to slip.
it’s necessary for the business
the business needs to take into account the high degree of uncertainty that comes with the domain and budget accordingly. blaming the developers for not being senior enough isn’t going to get the thing over the finish line any faster.
i’m saying this as someone who, despite individual items fluctuating pretty wildly sometimes, tends to get most of their work done by the deadline when they commit to it. don’t assume everything will go perfectly in a schedule.
even one of the founders of agile made a joke (ragging on planning poker and the like) about deadlines: in the old days, the PM could give you a list of work items to be completed each month for the next six months, and when you got to the end of six months, you knew you were halfway done.
it’s not a new problem by any means, and seemingly doesn’t have much correlation with YOE.
i originally cut my teeth in an environment that was extremely unstable. how long would it take to get X done? probably a few days at most. but X depends on Y, and it turns out Y is either not behaving in the way the customer documented it or is completely unavailable, and we’d have to go through a bunch of meetings to figure out why. so a task that takes me relatively little time to execute on paper now takes at least several weeks as we navigate through all the red tape.
maybe there’s a secret sauce i’m missing, but i don’t know how anyone can make reasonable time estimates in an environment like that. it left a bit of a chip on my shoulder as far as planning poker is concerned.
i’ve since moved into something decidedly more low level, and i’ll admit it’s gotten easier because the only dependency for most of what i do is me. things still fluctuate a lot, but somehow it all gets done in the sprint in approximately the amount of time we were expecting.
In other arenas you can obviously right? Like when I’m laying patio pavers I can reasonably tell you when I’ll be done once I’ve made it through part of the job. I can tell you about how long to paint a room because I’ve done it before.
The problem is basically that isn’t possible for complex projects and software, you’re exactly right. Scrum and other systems are all attempts to do it. Scrum will say it maybe isn’t just a way to predict what you’ll get done but it is in reality and PMs use it as such.
This is where you create “chore” tasks that are doable in small time frames to fill extra days. Stuff like adding unit tests, doing training (if your company provides any), or writing documentation.
The only problem is this feels like busy work that becomes a punishment for being productive.
Alternatively the team can encourage using extra time to work on new ideas or side projects for the company (like Google’s 20% time)
Unless I get scolded for it I’d rather we just work the next item that’s priority in reality and in jira leave the story in the backlog. Part of my job is basically shielding my team as I can from the arbitrary boundaries and distortions of how management views scrum.
It should average itself out either way. Whether I score more points this sprint or they’re counted in the next doesn’t change our average velocity, when I show our average velocity that’s usually over six sprints or so. But YMMV, and my work is just pickier about commit versus acceptance and that stuff put into the sprint doesn’t move.
With most engineers I have encountered their main concern is how much overtime they'll have to work to meet the purposefully aggressive deadline of their next big release. Watching someone force you to work in a way that guarantees you will have to work overtime in the future is depressing.
I feel your pain but your fear is misplaced - or at most you're mis-identifying which parts of the process is broken. Breaking another part will only make it worse, it won't fix the bad planning and it won't fix the overtime.
When you do your sprint planning there should never be more work than you can reasonably complete in that sprint, just as you should never move work into an already in-progress sprint. These two things are what protects you from forced overtime and burnout and they send a strong message to the product team and managers that they have to get their shit together to be able to plan ahead by at least 2 weeks into the future.
That's really not a big ask for them to get this one part right, and it's a damning indication of a failed product and management team if they can't so much as plan work 2 weeks into the future.
It's not that you are wrong with anything your saying but I feel like it is all a "in a perfect world that wouldn't be true" response to very common work experiences.
I'm not a new dev. I have been on a lot of projects, in different industries, with different clients and companies. The description of "scrumfall" in the article we are all responding to is very accurate to every single project I have ever been on.
Scrum has never protected my teams from burnout or overtime. There is always a real deadline on the horizon at which point everything has to be finished by. So the amount of work per sprint gets ramped up each sprint as it become more inevitable to the PM and business that we aren't on pace to hit the target. So for those same people who are pulling more work into a sprint than can be finished to also be restricting people from pulling work in on the rare occasion when it is done earlier is even more infuriating and absolutely contributes to burnout and leads to more overtime and stress.
I've also been there and done that and eventually I had to come to terms with the idea that if I don't draw the line for myself nobody else will. I'd rather get fired than continue wrecking my health for a bunch of dumbasses.
My question for you is, who on these teams comes up with these estimates that leads the PMs and the business to believe that these deadlines can be met in the first place? Were they engineering estimates? If not, just quit, it's not worth trying to fix it. If it's engineering, then you and your colleagues have to do some reflection about what it's going to take to give the business a more realistic estimate.
As a side note, don't forget Brook's law. Once a project is late, that's it. Throwing more people at it or doubling up everyone's hours is only going to make it later.
"If we load them up with 40 hours of bullshit sprint work and pressure them to do important stuff too out of pride or professionalism, we get free hours!" -- Management
There are significant benefits to not pulling more work in - it's basically queueing theory. It reduces utilization and thus makes work more predictable (which can have value), and it also helps to focus on finishing work (e.g. by helping to finish other parts) rather than starting work.
queuing theory is pretty well established. once a queue is at around 80% capacity, there’s a runaway effect and lead times go up exponentially. it’s like driving on an empty highway versus heavy traffic.
this video isn’t about software, but it explains the concept well
basically, it comes down to randomness. you can’t predict exactly how long it takes to process most items in a queue, so once utilization hits around 80%, that tiny bit of extra randomness per item blows up lead times in the aggregate.
it’s unintuitive to reason about at first. common sense says that if a dev can complete 1 unit of work in 1 week, then why can’t they do 2 units of work in 2 weeks and get more done each sprint? maybe they can sometimes, but it’s the times that they fall behind due to random bad luck that causes the inertia. that’s when everything cascades and blows up your velocity.
i had this issue on a previous team of mine. it was low-code and maintenance was very common in our domain. management just saw it as a cost of doing business, but every little bit of maintenance work added an item to our queue. the more things we deployed, the higher the chance one of them would smoke on any given day. eventually, our backlog was completely overrun and new work was damn near impossible to get done. and it happened fast. almost overnight it felt like.
so when management freaks out about devs pulling an extra item from the backlog hurting the burn down rate, there’s a chance that’s what they’re worried about. you need some bandwidth on reserve to keep things flowing.
it’s also a core tenant of agile IMO. you have to resist filling up the backlog with several sprints worth of work and forbid team members from getting too far ahead. otherwise, people are going to make themselves too busy and you risk doing unnecessary work if plans change next spring. it’s also why backlog grooming is critical to do every sprint.
This is my problem with scrum. Too many theories are implemented into practice that are only applicable in niche situations but which scrum masters get convinced are vital to success, usually at the expense of team morale.
If I and two other devs finish our cards 2-3 days before sprint end and pull work in from the already planned out next sprint there is literally nothing at risk. Planning for them to do that every time is a risk but one that is simply solved but not doing that.
But what about random events occurring? Well if I pull in a new card and then something happens where suddenly I have to pivot to a critical bug fix I simply pause work on my new card (which I pulled in from the following sprint anyway) to address the critical issue. Then when I finish, I just go back to my card. The only argument I have ever heard against this is that work rolling over between sprint but since the work was actually pulled from the following sprint, this argument seems flimsy.
The risk of unnecessary work isn't a risk. It rarely will happen that the work of the following sprint is made irrelevant and when it does that unnecessary work is only a cost to the dev whose time was wasted. As devs our time gets wasted constantly, we're used to it. You revert the commit and move on with life. Literally no risk there.
I have had this debate with PM's multiple times and it always boils down to them highlighting hypothetical situations where their stance makes sense but is not actually relevant to our teams. It also comes down to them wanting to technically adhere to be some sort of scrum purist at the expense the teams wishes. They insist it is because they want to be able to respond to change but in practice it always seems like their refusal is actually based in resistance to change. If the situation they are concerned about (however unlikely) were to occur, the team can adapt it it's practices. The only pushback to teams adapting in that way in my experience is the scrum master.
i’m actually not a “scrum guy.” i have a lot of issues with it and don’t prefer it (i hate planning poker with a passion). i like the idea of time-boxed sprints and working iteratively, but not much else.
the example you gave (something already that’s committed to and on the docket for a few days from now) is probably fine. i’m not sure who that’s hurting. i think the key is to just be reasonable about it—and to have some sort of gatekeeper in the middle to prevent developers from overcommitting and pulling things out of the queue ad hoc. i think that’s especially true at the beginning of a sprint where everyone is rosy and optimistic about what they can achieve in the next two weeks.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
it’s not explicitly stated, but i always thought these two points imply something along those lines. i doubt the original founders had queuing theory in mind, but i think intuitively, they knew there was extreme benefit to controlling the flow of work within short time spans.
yeah the phoenix project mentions that: wait time = %busy/%idle. the busier a person is, the longer the average lead time for each item in their queue.
you can also apply it to projects as a whole as well. if you want a team to move faster, give them less to work on. that’s why you’re only supposed to work in two-week sprints in the first place. filling up a backlog full of the next several months of work, and seldom taking time to stop and reevaluate, is the exact opposite of agile.
The company I'm about to leave is currently enforcing one ticket per developer at a time.
So if you get blocked (which happens a lot because the management don't facilitate proper planning) you have to just sit and wait until you're unblocked.
They decided this rule, because they thought that's why developers were rolling over each sprint - when that still happens but now nothing else gets done either.
Yeah we tried doing that for a bit but it was clearly impossible when you have work that you simply can't move forward on your own.
So we invented a "Waiting For ____" bin based on other boards we'd seen, which had much higher WIP limits.
This was still bad! The consultant people would tell you this is evidence we needed to improve the approvals or cross-training or whatever so that the worker could more easily push the work to "Done" without getting blocked by people. The WIP would expose the next barriers to be addressed.
But it was still a helpful in-between way of keeping the work flowing while addressing the long-term org improvements that would be needed.
Yes, the whole point of Kanban is that you try to improve the time it takes a ticket to go from 'taken from backlog' to 'in production'. So yes, if there's a place where tickets always wait, that is where you're supposed to try to find improvements.
Of course Scrum is awful. It's like taking everything that is bad with management and putting it in a formally defined workflow process.
But in principle, it doesn't really matter what process/model is used. Some people are always going to look for ways to control and exploit other people. Managers gonna manage.
The most important thing is that developers start standing up for themselves. As the article says: it "will likely require grassroots efforts by engineers".
I see way too many developers being passive and complacent at work. Always expecting someone else to deal with it. Always just waiting for some moment that will never come.
And this article is basically doing the same thing. It says that Scrum is bad, but offers no suggestion on what to do instead. Which only leads to a complaining party in the comments.
The only thing that works in practice is to have developers lead development. Start working on that in your organization.
Talk to your colleagues and get organized. Present a formal document to the upper management stating how you want to work. Explain why it is good for the business, using cost/benefit analysis and risk analysis. Explain why it is bad to never stop and think, and clean up after yourself, and how it leads to much higher cost in the development organization. Use analogies from other industries, for example show how electricians actually have rules that they have to follow. And be prepared to fight for what you want.
I've been doing scrum for 12 years at this point and the last time I saw a burn down chart was in 2014. No one in their right mind uses those any more.
Sounds like classic scrum stress. The obsession with burn down charts over actual progress is a killer. It’s like they care more about the numbers than the end result. Sometimes it feels like scrum gets lost in the process instead of focusing on the product
As a lead, I wish I could keep the estimation parts of project management tools secret from the developers. Or at least not prominent so they aren’t in your face.
The charts for telling a story and predicting estimates and accuracy. If you have to bring stories in, then the chart tells you that you have random stuff coming or you’ve missed things in planning. So maybe the team should discuss improving refinements, or changing how we deal with external issues. It could also be the team just needs to underfill sprints.
All too often people get zealous and religious over SCRUM and think the ceremonies is the delivery.
Simple reason: they can be stacked next to each other and the timeline can be extended to the right to make better predictions of delivery times.
Burn up charts give you much better visual representation on how your team is doing in the medium to long term.
If you do 1 sprint and score 40 story points it will be shown as a line ending at 40.
The second sprint you score 35 points and the chart for that sprint will end at 35, but the combined chart of the two sprints will end at 75.
Which type of chart is easier to predict how long it will take to complete a thousand story points?
Burn up charts!
But still, I prefer kanban over scrum, because I think it's more important to track blockers and inefficiencies in your delivery process, than to track points scored each week.
Burndown chart is kinda useless anyway as of course everything has this sliding window where it is in progress. Scrum doesn't say you have to use them btw.
The SM, and to some degree the PO so there's certainly some blame there too, is supposed to be the barrier between the devs and all that bullshit. If the SM is a pushover, or is having their hands tied by management then you might as well just ditch Scrum altogether because you'll get no value or if it, it'll only be a distraction.
That company did a lot of things wrong, and it was also too small to have good enough barriers between the scrum master and dev team to the rest of the org, I'm happy I'm not there anymore.
Now I'm instead working with some strange "kanban" version, but the PO:s that runs it has a lot more mandate against sales/stakeholders to stand against them when they come prodding.
Neither Scrum nor Agile fix bad managment. Waterfall as we know it is not what was proposed. Waterfall as we know it should be called "a naive inexperienced manager's pipedream", the kind where they just ask their employees "can you guys just work faster" and suddenly productivity skyrockets.
Although true, it is probably still better than what was proposed, where you were supposed to build the thing one time to work out the bugs in the requirements, and then do it all over again the right way.
Waterfall was iterative. It was different from Agile mostly in that it handwaved the get user feedback part, which is where stories and the goal was defined in Agile. Just like scrum becomes a "we do it in just two sprints and never touch it again" when under bad management.
As proposed, it was explicitly not that. It was linear and documentation-heavy, and the reason you'd build it once and then redo most of it was precisely because you were not supposed to iterate.
But Royce didn't handwave user feedback either. You were supposed to engage with the customer at various points throughout the process (usually in the form of "please read the hundreds of pages of docs and confirm they meet your expectations"), and user feedback was to be done as part of the evaluation of the first proto-version you built, to refine and finalize the requirements for when you then built it "for real".
You could certainly iterate it, one major version after the other, but waterfall wasn't supposed to be iterative in the sense we know it with agile methods, where you are continuously delivering small updates to get user feedback.
You could probably find even big mainframe users who were using iterative methods, especially in universities, but you wouldn't have called that waterfall.
I'll take scrum over waterfall all day. But as soon as you add in a project manager pretending to be a scrum master and some ridiculous change management framework...you're fucked, no matter what engineering processes you're using.
Do you want it to hurt a little bit every day, or hurt a ton in 6 months?
Funniest thing to me right now is that the company I work for really tried to make agile scrum a reality and obviously ran into all these issues.
So they just....stopped trying. We're currently running scrum, without a scrum master, with a project manager (no PO) that is like 4 levels deep in a project manager tree that nobody can even still decipher who is responsible for what...and the cherry on top is that each scrum team consists of 4-8 different actual teams which all don't work together, but just have their daily and other meetings together. And some of the meetings (like retro) are done with 3-4 other teams together.
Like....lmao. I don't think you can say more to that than just lmao.
My shop is doing something very similar. The PM is not a PO or even the scrum master. The engineering manager serves as the SM, causing delays because they’re juggling too much. Not a single PO anywhere. Another great aspect is management will set deadlines without consulting with the teams and is shocked when we don’t meet them.
That's a personal thing. I'll take a low level of stress daily over 80 hour crunch weeks. I can manage daily dress...I can't manage stress when I'm working from waking to sleeping.
I want my unified process back. Sure, it was far from perfect either.
But it had this big upside that at the time, management understood too little about the work of software development and didn't care to change that because it wasn't as important yet, it actually let you get shit done.
Early scrum was a bit like that too, before HPCs and management took over the concept and turned it into strict excel-driven-development.
But yeah, one problem is that people think the alternative to Scrum (the modern way, a strict, fixed-development, top-down-driven cycle) is Waterfall (a strict, fixed-development, topdown-driven cycle). Not the loose thing we nowadays usually call UP in hindsight that was quite pervasive at the time.
I've found that no process survives toxic culture or incompetent management. But when the leadership is decent then scrum can be great, and really protects the team. What I like to do (besides all the standard stuff like sizing stories together, retros, etc):
Throw all the reporting away
Dedicate ~25% of your capacity to urgent requests
Of your remaining ~75% capacity, only allocate about 75% to goals
Keep anyone on-call out of the feature work, and focused on operational excellence - as time allows
Keep a prioritized backlog, let engineers pick from the items near the top of the backlog
I find that it's great to have 2 week goals for the whole team to push towards as well as some protection from getting whipped around by constantly changing priorities.
So Scrum can be great when it's not actually Scrum, but your own process that takes some elements from Scrum. Which is great, of course, but not Scrum.
There's nothing in scrum that requires a dedicated scrum master
Except there is... "The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. ... The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide."
Well it's used as training wheels for agile where a company was previously waterfall.
Scrum is agile for managers and surprisingly through weaponised incompetence they often miss the point and encourage turn it in to waterfall with extra steps
I found too many people get too dogmatic around the scrum lifecycle and the ceremonies to the point of being overly rigid. Scrum to me is guidelines, something to use with flexibility in mind for how the team, the org, and the stakeholders operate. Be too rigid and it breaks, be too flexible and you don't see the benefits.
Years ago I had an interview with a company where the head of development was also the head of a local Agile group. He was a hardassed my-agile-way-or-the-highway guy. Didn't take the job because of this.
I told the person who had asked me to interview that the company was going to die because of him. This was a company which required continuous creativity. The software was fairly easy to implement, once someone very creative came up with what needed to be implemented. It was also a very competitive business, so continuous cool features were going to be key.
My statement was clear, this guy would drive away anyone with any actual talent. Drones would maybe like it, but nobody with any self-worth would put up with his BS for one second.
Years later I bumped into one of the founders at a tech event. I asked, "Did you ever fire that Agile D-bag?" in a company with over 100 people he didn't even have to think about it for one second and said, "Way too late, the damage was already done."
The company was bought out a while back for not much money. I would throw out a guess that they could have sold it when I interviewed for 10x as much.
Yikes .... The ultimate tale of failure due to bad agile practices. I don't understand how management lets that happen. I worked at a Fortune 50 company that put some brown nosing engineer into the head position for the division's agile practice. My team had been through the evolution of scrum ban, agile scrum, and then SAFe agile as we grew and our role became more central to the division. My boss told me to offer my expertise and help out the new agile division head. The new agile head sort of brushed me off and was VERY dogmatic in his approach, following the agile method to a T despite me telling him I learned that flexibility is key to its successful implementation. One quarter later I was hearing how engineers and stakeholders were at the point of skipping meetings or ceremonies because it had gotten ridiculous, tedious, and not very useful. I had zero interest in being part of that org because I enjoyed my little island in the sun (division's/CIO's cloud data lake and big data reporting infrastructure), but had they appointed someone with actual experience I think things would have run smoother. The agile head was under tremendous pressure and was definitely not delivering due too much rigidity, ego, and a complete lack of awareness. It was crazy to see such a fuck up at a company like that. But hey, even Apple had weird quirks like not analyzing loss prevention data for YEARS and wondering why a single global policy for losses doesn't work 🤷♂️🤡🤦♂️
That is a problem far past agile to a huge amount of software and hardware development.
Often, their dogmatic approach is defended by weird edge cases which, to an outsider, seem reasonable responses to said edge cases. The reality is that, well, reality says that is stupid. The edge cases are often so rare that they can manually be handled, or are a sign of something else wrong.
Often, I find that agile is designed for crappy programmers. There are two possible solutions:
Fire them.
Put them on a moron team and agile the crap out of it.
I seem to have a very different interpretation of at least how Scrum is supposed to work than the author of the article. Although, sadly my experience with Scrum in practice isn't all that different.
Here's a few things where I think I have a difference of opinion with the author on what "correct" Scrum looks like:
Sprints, on the other hand, are fake deadlines
Sprints are not supposed to be deadlines at all. You don't finish everything you planned in the sprint? -> Okay, that happens, what can we learn from this so we can plan better in the future?
Especially when you're just starting on a project and you have no idea about how your team works together, your initial estimates for how much you can get done in a sprint are going to be completely off base. This should be expected, and a team should get more accurate in their planning what they can achieve in a sprint over time.
Every aspect of a sprint is prescribed: its duration, its meetings, its tasks, and even the roles of its participants.
The duration of a sprint is prescribed. And there are a few meetings that are prescribed: the review, the retro, the planning for the next sprint, and the dailies. If you are not completely incompetent at timeboxing (which, I have learned, a surprising amount of people are. Does nobody know how clocks work anymore?) those really don't take up that much time. Need more meetings in a sprint? Plan more meetings then (and as much as we all hate meetings, in larger organizations you probably do actually need more than those, to align work with different teams and such).
Need to adjust your tasks during a sprint? Talking about that is literally what the daily is supposed to be for, so I don't get how you can think those are prescribed?
Roles of participants? Scrum actually (unrealistically, in my opinion) expects all Developers (which, remember, in Scrum is everyone in the Scrum team except the Product Owner and Scrum Master) to be able to pick up any kind of work. If development is done but QA turned out to be more work, devs are expected to help QA out. So I don't think that's really prescribed either.
Consider, for example, a study with male mice divided into groups: some were subjected to involuntary running periods.
Look I get the point and I don't disagree but you probably shouldn't use a study done on mice to make claims about human psychology. Mice eat their own babies sometimes.
This happens because no time is set aside for proper engineering prep work.
That isn't Scrum's fault, it's yours. It is your job to set aside enough time for proper engineering prep work. Yes, that means you need to do at least some thinking up-front, and incorporate it into your estimates. And also plan to have the time to do the required up-front thinking. This isn't a Scrum failure, this a failure of the developers to plan appropriately. Learn from it and plan more time for these kinds of activities in your next sprint.
Scrumfall: The Real (and Worse) Picture
Honestly, this is pretty accurate. It's a shame, because competently implemented Scrum is a really nice way to work. But almost nobody implements Scrum competently.
Yeah, if you don't want scrum to work, it won't work.
You do need permeable hierarchies; if PO and devs consider each other on opposite sides of the table, you can as well go back to crunch mode and whippings.
My take on that is, scrum is not going to work if you add someone to manage project in it, it's only going to work in an all dev/qa team where they manage internally, the moment higher management is involved, that framework is not going to work.
There will always be failed programmers who are politically connected and will "rise" to become managers. The only way this works is when a company's culture fires bad programmers.
Scrum is BS. It has always been about selling snake oils and create a business out of consulting. When you realise that most scrum people have no clue how to write software or build anything really, you can't take them seriously. They just apply a set of rules without having a clue.
Reading the 'agile manifesto' and the agile 'principles' it's clear what they are all about: faster faster faster; with lip service to quality and documentation. There's a reason they are called 'sprints' and not 'crawls' and 'velocity' not 'thoroughness'.
Waterfall processes in which it's too hard to iterate so everything has to be done perfectly. And the results are a gasoline-soaked house of cards.
Kanban or a complete lack of process when building a system and needing some general milestones to communicate to management & users. So, then management simply sets them without any input (or effective input) from the engineers.
It exists purely through misunderstanding software development which in turn breeds a lack of trust. Hence, why in a stand-up every day you'll explain what you did yesterday and what you'll be doing today, lol.
The point of the standup is to see if people are blocked and appoint people to help if they are. If all you are doing is a status report then why bother with the standup since you can do status reports in other meetings.
If I'm blocked on something I just go to my coworker desk, or make a phone call if I'm not at the office, if it's urgent, or if I can wait I just send him a message on Teams.
In my experience standups always end up in managers asking for status report, and discussing on why we are late on X, often going into the technical details of the thing, making people not really interested in that particular issue (because they are maybe working on another project at the moment) waste their time.
If I'm blocked on something I just go to my coworker desk, or make a phone call if I'm not at the office, if it's urgent, or if I can wait I just send him a message on Teams.
You just interrupted someone else. Also some people do not have the same inclination and need help when deciding to be unblocked.
In my experience standups always end up in managers asking for status report, and discussing on why we are late on X,
You just interrupted someone else. Also some people do not have the same inclination and need help when deciding to be unblocked.
Of curse, you learn when to interrupt and when it's not appropriate. It's part of our profession, in the end. I tend to accumulate my questions for moments like lunch or coffee breaks, for example. Of course there is always the case of the urgency that you need to resolve (e.g. bug in production). I tend to get as many information about something upfront, so that I can take my decision without bothering other persons, and to have a batch of work sufficient enough to be able to work for a few days without indication (well, now that I think about it, I can work for weeks probably). But to me this has anything to do with scrum, it's the norm, even in jobs not related to programming at all.
Then tell them in the 1:1 not to do that.
Well, I do, sometimes. But, you still are talking to who pays your paycheck at the end of the month (at least in my situation, where the manager is also the owner of the company!). So in the end... you are payed to do your job, I do it professionally, but in the end I do it by the indication of the company, even if I don't agree with them.
That would mean you're wasting on average half a day being blocked on something. And then asking for help after you've had your entire evening to remove all of the context from your skull. When you are least likely to be able to help the other person help you.
No it really isn't, it was designed to protect contracting development teams from constant change and having to fight for budget overruns. It got used in countless teams that were a bad for for the process and that's the real problem with it, got sold as the silver bullet for everything because the people that invented it gotta eat.
I got laid off recently and after the initial shock ebbed, I am relieved. The constant sprint velocity BS had worn me out. When there were not enough tasks they had me working on stuff outside my wheelhouse and started dinging me for lower velocity. After a point, it felt like no matter what I did, I was always falling short.
I am curious with all the AI driven coding that's happening now, where will regular devs exist in that domain soon.
Forcing teams without any actual autonomy to do scrum or agile is such a team morale killer. It's cruel to make people pretend they have something that they value a lot but don't actually have. It's like forcing starving people to pretend to prepare and eat a meal everyday.
This is where I'm at. My team has very specific feedback come out of every retro and every time any of it gets raised to management types, it goes in one ear and out the other. I'm just about done bothering trying to make anything better for anyone but myself.
Continuous delivery can help dovetail an actual agile project structure to a tempo that management expects. Sometimes they get the build from Friday, sometimes they get one from Thursday or Wednesday. Here is what was done in this version, aka 'the last two weeks'
I've worked on teams under variants of Scrum, Lean, and Kanban that were joyful and stress free. The choice of process sets a rhythm of work that certain people may find stressful, while others find relaxing. The far more impactful source of stress is the attitude of your team members, particularly those of your manager, lead, and/or product/program manager. Great management will protect a team from an excessive sense of urgency, enabling the team to build with quality in a principled, professional way - which ends up being faster in the long run, often by orders of magnitude. Poor management will unnecessarily inflate urgency, resulting in a stressed out team that is far more likely to take shortcuts, compromise their design principles, and make more mistakes.
I can buy that. Then it seems like great management is very rare. 1 good manager can make life a whole lot easier, which I am fortunate to have one, but even thats not enough since 1 manager can't do it alone and they dont have all the power
The chart of the "combined" Scrum and Waterfall is so true haha. You get both the stress peaks around release time, but the baseline is just a continuous never-ending sprint (which is a bit of an oxymoron in itself, isn't it). Of course it doesn't have to be that way, but I certainly recall jobs where it was.
it's hierarchy. it's always hierarchy. if there's a system where some group of people has the power or authority to tell other people what to do, even the most perfect system will become useless.
Sprints never stop is an incorrect statement. The hardening sprint can be slipped in the planning anytime, giving the team a breather from the mundane repititiousness. Also, the retrospective allows extra room for improvements, so if the team decides to dedicate the next cycle to spikes, training, self-study, then that is also allowed. The team is empowered to achieve goals in any way it deems as necessary.
I think a big part of the stress comes from how Scrum is implemented. It's supposed to be a framework for helping teams adapt and improve, but too often it gets treated like a rigid process with no flexibility. When leadership focuses more on the ceremonies than the outcomes, that’s where the stress kicks in.
I've been a member of this subreddit since it before subreddits even existed and this was just a separate reddit instance alongside joel.reddit.com. So I say this as a person who has been around and knows that this place was never limited to posts precisely about programming topics, but about the software industry in general.
So this is not a "this is not programming" complaint.
With that out of the way: Enough fucking posts about scrum/agile whatever the fuck. If the mods wanted to fucking ban these things I'd be all for it. The discussions are all the same. There is nothing new to say. Yes, I should just downvote and move on. And I do and have for years and years now. But this morning it's got my blood up so I'm going to rant.
Developers seem to think these tools are designed to make them more efficient. VPs only care about efficiency so much. Instead they are primarily for making teams predictable. We are always juggling flexibility with predictability. Scrum isn't a good way to develop quality software, or a quality team, but to the people who force it upon you, that's acceptable.
If the author actually believes this then he hasn't really been part of a substantial software project run in an actual waterfall fashion. Scrum / Agile is not the best method but its the best we have developed so far.
PythonDev96@reddit
I can relate, the last graph is pretty much every project I worked at for the past 6 years.
There is one thing I’d like to add and it’s how frustrating the ceremonies are. I enjoy writing code, I enjoy solving complex problems, and in order to do so I need to focus.
I can’t focus if every day is interrupted 3-4 times with a standup, grooming, planning, retro, 1:1, plus some extra “Quick 5-minute sync” meetings.
I don’t want to spend an hour thinking what we can do to improve next week, just let people say what they want to improve whenever they want and we can chat about it asynchronously whenever each participant has time to do so.
ragnaruss@reddit
As a member of senior management let me play devils advocate for what happens if we don't have these meetings:
Stand Ups: Someone says all week they are on track to deliver, they've got just one. more. bug. to fix. and then the day before the end of the sprint, they admit they were stuck all week and didn't complete and rather than pulling that feature you now can't release because other tickets interrelated. Yes, I know, your team would definitely ask for help every time, except when they don't.
Grooming: Congrats, your next sprint is now focused on a POC for something that was going to clinch a sale, except the sale has died on the vine and it is not needed anymore, or there is a suitable work around, or some education change the customer approach. Your two week sprint has added more code to maintain, and had no commercial benefit.
Planning: You did not do planning, you and your coworkers have done tremendous work and completed everything on time. His auth service uses cookies, and your UI expects JWT. Or he does server side pagination, and you implemented locally search and filter.
Retro: One developer keeps making condescending PR comments for the new developers and they decide to leave,nobody addresses this issue because who wants to call up a coworker and say they are a problem. Team because cliquey and insulting. Retaining new devs is very hard and new ideas are long forgotten. Or it could simply be you would prefer pair session to be in the afternoon while the kids at nursery or something, and this is a place to explain that.
1:1: There is no effort from your manager to grow and develop you because they don't know what you want to grow or develop since they never talk to you outside of giving tasks, you have no chance to give your manager feedback or seek explanation for wider strategy decisions. The working relationship suffer and churn increases, now you have a bunch of coworkers who are new and don't know how anything works.
Every developer loves to say about how they can be self directed and handle this in their team without the need for processor or people over seeing it and almost always that is not true in the slightest. they will avoid dealing with things, avoid communicating until there is a huge blow up and some dramatic problem. If you are the 1 in (maybe) 50 who can do all of that, what are the odds the 5 - 10 random sampling of people are all those people?
satoshibitchcoin@reddit
All you've done is made it more stressful for them to have to invent more ways to say i'm still working on this which is probably the case. In the best case scenario you've just made life harder for your developer, congrats.
Jimmysmalls421@reddit
Yea this seems to be a product/result of standup instead of the opposite. “Says all week” means they spent all week focused on their status. What if they only said it “earlier in the week” and used the freed up time to think through problems and contribute differently?
DualActiveBridgeLLC@reddit
This is a great response. Everything in Agile-Scrum has a purpose to solve a particular problem(s). You can choose not to do steps, but something has to solve those problems else larger problems occur.
And 1:1's are probably the most important meeting. Ineffective 1:1s lead to so many problems and to even less productive meetings. They aren't 'tell me what you are doing' sessions (unless you want them to be), they are a time where the IC gets to talk about whatever they want to. Or not. I have some people that only wanted 10 minutes in the 1:1 and that was perfectly fine. But if they need a longer discussion then we have the time to do that as well.
morewordsfaster@reddit
I keep telling my director and VP that we have a lot of smart people and it feels like every process we implement is designed to get in their way and prevent them from delivering quality software quickly.
If we only had standup, sprint review, sprint planning, and retro, that would be fine. That's only 6 hours per sprint, leaving another 74 free for dev work. But it's all the other crap that distracts us from doing great work.
We keep having meetings to discuss how to improve velocity and I keep saying the same thing. Just get out of our way and let us do the work. Here's me shouting into the abyss.
Dankbeast-Paarl@reddit
Damn, 74 hours? No lunch time built into your week.
morewordsfaster@reddit
Wait, we're not all eating during meetings...?
pydry@reddit
oh dear god...
Dankbeast-Paarl@reddit
The meetings will continue until velocity improves.
RonaldoNazario@reddit
The trainings said this line will always go up! Make it go up!
Ok-Yogurt2360@reddit
This is worse than my tendency to start binge eating when i'm stressed because i feel unhealthy/fat.
IndependentMonth1337@reddit
Managers won't listen because then they wouldn't have a job anymore.
LinuxMatthews@reddit
Definitely agree with this
What's also frustrating is how everyone needs to be involved in every part despite many having no idea about a certain part.
Like you'll have a group of say 10 people and 1 guy has actually worked on the micro service the ticket is about.
But all 10 have to do the planning poker despite no one actually having a clue how much work it'll take.
And because no one wants to look stupid everyone is just guessing what everyone else is going to put
DualActiveBridgeLLC@reddit
You have a problem with defining your tasks and having multiple people understanding the codebase if most people can't contribute to estimation.
LinuxMatthews@reddit
People have different areas that they're good at within a team that's why there's a team
This idea that everyone has to be a Jack of All Trades Master of None is what's killing our industry
As is the idea that it's everyone else's problem rather the system
EveryQuantityEver@reddit
At the same time, multiple people should know about different areas of the code. That one guy who's worked on the microservice? He's gonna quit someday.
LinuxMatthews@reddit
Oh certainly
But that shouldn't be done through sprint planning.
And even if it shouldn't be one person it doesn't need to be all of the team for everything
Have the guy who knows that thing estimate then someone else can do the ticket.
That's how you spread knowledge
DualActiveBridgeLLC@reddit
There is a difference from being the expert in part of the codebase, and people not being able to contribute to estimation. What you describe typically results in single points of failure or cowboy coding. And if estimates have large variation you either need to break the task down of define it better.
LinuxMatthews@reddit
Someone who knows a part of the codebase is always going to be better at estimating.
Obviously it shouldn't be only one person who knows one bit.
But when you have backend guys estimating front end or visa versa then you've got an issue.
On every team I've ever been a good chunk of the people are just guessing what everyone else will put because they don't want to look stupid.
Which means tickets aren't estimated properly because the expectation is how to said
RevolutionaryYam7044@reddit
Maybe you should discuss that in the retro then? If the process is keeping you from being productive then the process needs to change. It's a core principle of agile. What you describe is a company problem and not an agile problem.
PythonDev96@reddit
It’s not easy to tell your scrum master that you don’t want to do scrum, it’d put their job on the line.
Also, some programmers do like it, I’ve met several devs who would rather spend more time in meetings than writing code. I haven’t asked any of them why.
EveryQuantityEver@reddit
I really don't get all the "There's too many meetings!" complaints. I have a 10 minute standup every morning, one planning meeting on the first Monday of the sprint scheduled for an hour, a grooming session on Wednesdays that's scheduled for an hour, but once the backlog is under control is rarely half an hour, and a retro on the last Friday of the sprint for an hour. How is that too many meetings?
Avloren@reddit
That's an unusually light meeting load, in my experience (so far 5 years of doing scrum, across 6 different teams). I'm used to 6-8 hours per week of sprint ceremonies. My current team is 30 minute standups every day; 2x 1-hour groomings per week (and yet, somehow, I've never ever seen a backlog that's "under control," every team I've been on has perpetually been creating the stories just in time to work them like the meme of laying the track out in front of the train as it's rolling); 1-hour retro every other week; 1+ hour planning every other week (often spills over its allotted 1 hour); 1+ hour demo every other week.
EveryQuantityEver@reddit
That sounds like a "your company" problem. Like, 30 minutes of standup is way too much. And if you don't have your backlog under control after a month or two, then what are you doing in that grooming session?
peakzorro@reddit
Good lord! I've been in the business more than 20 years and a lot of it was scrum, even with ceremonies. Never ever did I have that many sprint meetings.
theBosworth@reddit
How does standup take 30 mins? Honest question. Admittedly, I work on a small team, but 8 of us wrap up standup in less than 10 minutes on average, with 5 minutes being relatively common.
RonaldoNazario@reddit
I'm assuming it's a team where people feel compelled to give a detailed status and don't feel comfortable giving a 30 second "working on X and it's going fine" type update.
Quexth@reddit
It is not. But people who complain probably don't have your number of meetings. I know I don't.
EveryQuantityEver@reddit
I mean, those are all the ones that are ever proscribed by the methodology. If you've got a lot of extra meetings, that seems like it's on your company.
OllyTrolly@reddit
I know it sounds lame af, but I had our 'titles' changed to Agile Enabler in our area of the business. I tried Kanban with my team and the others Scrum Masters panicked a bit, because as you say, what is a Scrum Master that don't Scrum?? Arguably even putting Agile in there is a bit redundant these days, it's not like anywhere is saying "nah, fuck Agile".
RevolutionaryYam7044@reddit
But you are doing scrum by improving the developer output. This is exactly one of the strengths and core principles of agile. If your scrum master is not supporting you in that goal, then they are the one not doing agile.
If you know exactly what to do and have absolutely no reason to interact with anyone else in the company, then it's perfectly reasonable to stay away from all the meetings. Scrum gives you as developer all the tools to improve your own experience and output, but so many developers don't understand that and many companies sabotage the efforts of those that do.
mgxc24@reddit
Those problems are not exactly scrum issues so a competent scrum master should be able to address them. The only meeting that appears on a daily basis is the 15min stand-up, which should give you 7h45min of coding time. Then there is grooming, but that is only collecting the requirements - you need them to start coding anyway. If you have nothing to talk about on retro that's fine - I've seen teams that do one retro every 2-3 sprints or shorten it to 15-30min. Every other meeting is your team's invention.
RonaldoNazario@reddit
The scrum masters on my team aren’t some scrum evangelists, they’re shoved into that role the same way I am as a PO. It is actually worth discussing how the process can be less painful. Whether your org gives you flexibility to actually change that may vary. which, itself is one of the many ways they ignore what scrum says when it doesn’t match the desires of upper management- scrum teams are supposed to self organize and in part come up with their own process and refine it for what works for the team. Except when management just mandates certain parts of how it must be done lol.
RDOmega@reddit
"Ok Google, how do I become a company pariah?"
PathOfTheAncients@reddit
I'm so tired of retros where we privately complain about all the things blocking us but we can't talk about publicly because it's all leadership issues. Of course now days leadership demands access to the notes of our retro so instead people complain about small nothing issues that we have discussed previously but then everyone intensely debates solutions to them for an hour.
LiquidLight_@reddit
Oh, you have that too? We outline our issues and when they get raised to a mamager or senior product owner (Safe sucks), it's like we've dumped them into a black hole. I've never had anyone a management layer up actually resolve an issue. They only cause problems.
BilBal82@reddit
Standup everyday ok, but who in the hell is having planning retro everyday. That’s indeed not how it’s supposed to work.
NotUniqueOrSpecial@reddit
Nobody.
They literally gave the amount of time consumed by the meetings; do you think if they were having planning retro everyday they'd only be spending 6 hours?
BilBal82@reddit
He’s saying he’s getting interrupted 3-4 times a day for these meetings. If your having 3-4 meetings a days as a developer you’re doing something wrong imo unless your like an architect or something. But then those will not be scrum meetings anyway.
aueioaue@reddit
Pretty sure they were just listing examples of meetings, not saying they have every one of them every day.
DualActiveBridgeLLC@reddit
You are doing grooming, planning, retros, and 1:1 everyday?
EvaUnitO2@reddit
Sprints and standups are also in place to prevent cowboy coders from running off on a tangent by their lonesome.
15 minutes per day is not an imposition. If your shop is dedicating more than that to mandatory meetings (outside of the sprint-planning meeting and the retrospective) then I might suggest they're just pretending to implement Scrum.
LinuxMatthews@reddit
There are definitely aspects of SCRUM that are good
I think the issue highlighted in the article though is the artificial deadlines.
Having a daily standup I think is good for keeping a team together if nothing else.
And measuring how big tickets are is also a pretty good idea though it shouldn't be mandatory the whole team pitches in.
But having Sprints disrupts the way people work and just causes needless stress.
Seeing your ticket go over to a new sprint is often quite embarrassing and can become frustrating if it's not something in your control.
It should just be a Marathon.
Organise the backlog so the most important tickets are at the top.
Then the developers can pull them into the board work on them and then they disappear.
If it takes ages have a word with the developer and see what's wrong, you can still size them but none of this burndown chart BS
EvaUnitO2@reddit
That's the rub, though. A sprint is not intended to be a deadline and if a company is treating them as such, then all they want are deadlines, which in turn means up-front long term estimation. No development methodology is going to fix that.
A sprint is simply meant to be a short enough chunk of time that changes can be added and a new build made. The build is the letter of the law. It's meant to be the singular thing that tells you what the state of the software is (rather than charts, docs, or promises) That's why you want shorter sprints: it's easier to estimate tasks that can be done in a shorter window and it allows for builds to be made at a clip that decisions can pivot in the time frame of weeks rather than months or years.
Phobetron@reddit
Sprints should be team-focused. Aligning them to product goals, and not to the team’s needs and abilities, that’s what makes “scrum” fail.
Shikadi297@reddit
I've experienced seven separate managers across three separate teams in a very large well known company, all of them do scrum different from each other, and all of them do scrum wrong. My sample size is limited, but I wonder if doing it wrong is more common than doing it right. I've seen it done right once at a different company.
wavefunctionp@reddit
No true Scotsman. Real communism has never been tried. Real vegans are fruitivores. Real Agile works.
Additional-Bee1379@reddit
I always find this a ridiculous analogy. Scrum has clear and simple guidelines on what to do, if you choose to just ignore those and then complain about scrum what are you even doing? There are plenty of companies that do implement scrum as it is written and it works fine, there is simply no development framework that will turn your shitty manager into a competent one.
pydry@reddit
Yup, and it's shit whether you follow them religiously or not.
But, either way, youll be told that if you think it's shit then you must have been doing it wrong.
Additional-Bee1379@reddit
Ok, so name what is shit about it?
ehaliewicz@reddit
Dude just look at the book written by the co-creator of scrum. https://www.amazon.com/Scrum-audiobook/dp/B00NHZ6PPE
How can you possibly take this seriously lmao
Additional-Bee1379@reddit
ehaliewicz@reddit
How about shitheads like you who come onto threads with dozens of people complaining about scrum to tell them that each and every one of them is just doing it wrong. Ever consider that something being hard to implement correctly is a property of that thing?
Also the creator is a crackpot and you actually take it seriously lmao
EveryQuantityEver@reddit
How exactly is it "hard to implement"?
ehaliewicz@reddit
Mostly because almost nobody actually seems to want to implement it correctly. Also because it is a scam designed to make money rather than improve productivity (see linked book)
EveryQuantityEver@reddit
That seems like a management problem, then, not a problem with the methodology.
ehaliewicz@reddit
Is your argument that fake scrum has caused no extra damage that wouldn't have been caused if teams doing fake scrum had never heard of scrum and did something else instead?
In my team's case, we would have just kept doing kanban and enjoyed higher productivity.
Additional-Bee1379@reddit
My company implements scrum just fine, and yes if you just literally do what it tells you not to do then you are "doing it wrong".
Pomnom@reddit
Funny you brought up that book! Some guy on this very subreddit convinced me to give it a read and said it has all the solutions. I should have known ...
Anyway I bought it and it's nothing more than techno-blabbering sale drivers.
DavidsWorkAccount@reddit
Here's some shir - it's so overly vague that everybody does it differently. And not in the "we changed things that best fit our needs and agendas" way. In the "we all litterally interpret these super vague ass words differently."
I dare you to put 10 scrummasters in a room and get them to agree on anything outside of "How do you spell SCRUM?" Heck, ask them about the 20% and what it's used for. Guaranteed different answers from every single one.
Additional-Bee1379@reddit
It's well defined enough to see half those interpretations are just literally what it tells not to do.
ehaliewicz@reddit
Ok, so half of them are correctly interpreting it and still disagree. Sounds about right.
EveryQuantityEver@reddit
If you're doing it wrong, how the hell can you hope to be doing it right?
If management doesn't let you do it right, how is that a fault of the methodology?
pydry@reddit
I did it right. Scrum is still a piece of shit.
thatpaulbloke@reddit
Does it? It has very vague guidelines on what to do, but how you interpret those guidelines is an incredibly wide open field. It's like claiming that Christianity has clear and simple guidelines without somehow noticing that there's thousands of sects around the world that disagree on what those guidelines are.
Additional-Bee1379@reddit
But those interpretations are fine, as long as they don't do literally what the guide says not to do.
ehaliewicz@reddit
The scrum guide is nonsense. People will make small tweaks which actually improve their experience but according to the official guide they are not doing "real scrum". Therefore, scrum is quite obviously not about being an effective process, it's about making money.
Additional-Bee1379@reddit
Ok, give me an example.
ehaliewicz@reddit
Do you legitimately think it is impossible to improve even a single aspect of the scrum guide?
Well how about this. In 2011, the scrum guide was modified to no longer use the term "sprint commitment" and now uses "sprint forecast". Since pre-2011 scrum did not follow the current scrum guide, was it not actually canonical scrum?
If people successfully applied pre-2011 "scrum", were they lying, or would their team have also worked well without pre-2011 "scrum"?
Now just extrapolate this to a theoretical change to the scrum guide in 2025 or 2026 which invalidates the version of scrum you are currently using.
Additional-Bee1379@reddit
I didn't say scrum is perfect, I am just saying the vast majority of complaints are things it literlly tells people not to do. I don't think peoples complaints was if it was called a forecast or a commitment, although forecast is indeed a way more accurate term. For that matter I think sprint is a mediocre term and "leg" or "stage" would be a better term as nobody runs a marathon by continuously sprinting.
ehaliewicz@reddit
I definitely agree about the usage of the word sprint.
thatpaulbloke@reddit
Which religion are you talking about there, Scrum or Christianity?
Additional-Bee1379@reddit
Yes
Nimweegs@reddit
Is it no true Scotsman to claim to make mac&cheese but using shit instead of cheese, and then complaining that mac&cheese tastes like shit?
JayantDadBod@reddit
Sounds more like a straw man? A cleaner NTS argument would be like:
A: "Mac and cheese is delicious" B: "Kraft dinner is gross" A: "Real mac and cheese is delicious"
The fallacy is in rejecting that KD is mac and cheese. It definitely is what some people mean when they say mac and cheese. It's not a fallacy to clarify/admit that it might not be delicious under that circumstance. The fallacy is insisting that the counterexample "doesn't count".
Nimweegs@reddit
It's just that most of the time when people say scrum doesn't work because X, X is not according to the Scrum guide. "business folk" talking in the daily scrum is explicitly not OK according to the scrum guide, you're not reporting "status" - that's genuinely not the point. I'd love to collect some of these and put the relevant scrum guide stuff next to it.
OnlyForF1@reddit
But the argument being made is the inverse:
A: Mac and cheese tastes like shit, the cat poo in it is awful.
B: Real mac and cheese without cat poo is pretty delicious, it is a lot better when your boss doesn’t add cat poo A: No TrUe ScOtSmAn, real mac and cheese has never been tried
ForgetfulDoryFish@reddit
Not when it's nearly impossible to find someone serving the mac&cheese that was actually made with cheese
zoddrick@reddit
I worked for a company who sold Agile Software (long before JIRA did) and even there we eventually gave up on Scrum and went to using Kanban for the development teams. Scrum is great when you have lengthy release cycles like we did 20+ years ago. But in today's modern engineering orgs where we are trying to get stuff into production as quickly as possible (even behind a toggle) Scrum just breaks down and the process gets in the way.
aykcak@reddit
What are you talking about? Scrum is meant to work on short cycles and deliver small changes quickly
puterTDI@reddit
How short are your cycles? We're getting stuff into prod daily.
The point the person is trying to make is that the sprint cadence doesn't match the release cadence, so the extra "stuff" to support it gets in the way.
Our team's big issue was the below simultaneous expectations:
These expectations were driven by our product owners and they would not budge. If we weren't getting every single thing done by the end of sprint, we came under fire. If we pushed back and said that that extra thing they just thought of or noticed that wasn't part of the acceptance criteria after we finished the work needed to be a separate work item, we came under fire. If we pull something in because we finished a day early but didn't get it done by end of sprint, we came under fire.
In the end we finally just said we would no longer be pre-loading the sprint. We would pull work in as we went, and the sprint would be used to calculate velocity and as a marker for other activities. Things got a lot better and less stressful.
wantsennui@reddit
This situation and your subsequent replies in this thread are so relatable. There are similar feelings from the team’s developers so I hope try to convey some of your offerings here to, at least, try to start a conversation.
aykcak@reddit
Sounds like you were not doing agile. Or doing Sprints correctly. Scope changes should be rare, not a habit
puterTDI@reddit
I agree. The problem was that the engineers had little control over those decisions.
I think if we took the control over what was loaded into the sprint and what constituted sprint scope and put that into the hands of the engineers then things could play out different.
Another thing I didn't list above is we were forbade from calculate our sprint velocity based on PTO. POs found us doing that "annoying" and felt it wasted their time so they would stop us from doing it, forcing us to commit to the same sprint velocity even if half the team was gone on PTO.
wavefunctionp@reddit
Sounds like a degenerate and toxic situation if you can honestly communicate issues at not arrive at an improved solution.
puterTDI@reddit
I tend to agree.
zoddrick@reddit
If you want to do weekly releases (or even daily) it is almost impossible to follow Scrum. It cant handle the fast release cycle properly because it is built around the fact that you bundle multiple sprints into a single release train. Thats why you spend so much time doing story points and capacity planning. Its also why you need burn down charts to help you get better at your planning regimen.
Kanban is a superior workflow for development teams with sub-2 week release processes.
Bl4ckeagle@reddit
but doesn't that mean that scrum doesn't work?
mpyne@reddit
Those are bad comparisons to the case here. That's the point they are trying to make, but since there are teams that have made Scrum work it is pretty silly to say Scrum cannot work (even though the original user said "Agile" instead of "Scrum" so who knows what they meant).
Sage2050@reddit
Only if you want to be intellectually dishonest.
MikeHfuhruhurr@reddit
That can't be true because we've already paid for the Agile consultant.
dacooljamaican@reddit
Oh the first contract is coming to an end and they haven't done shit to improve our processes yet? Well we spent so much money on this contract, we HAVE to extend to get our money's worth!
CamelCavalry@reddit
that's wavefunctionp's point as I understand it
Koppis@reddit
You might be on to something
OnlyForF1@reddit
Huh? No true Scotsman doesn’t apply here. Plenty of dev teams have successfully delivered projects using Scrum.
wavefunctionp@reddit
Are they successful because they used scrum? Or Agile? Or Some other methodology?
Or is it that a successful delivery is what makes a team successful regardless. I don’t see any successful teams NOT delivering good software.
djnattyp@reddit
Really more of a false attribution fallacy - just because management does the same dumb top heavy shit and calls it "Agile" doesn't mean it is. Just because North Korea claims to be a "Democratic Republic" doesn't mean it is.
JayantDadBod@reddit
Half of these aren't true scotsman arguments. You need to make a claim ("Agile ships products faster"), a counterexample ("My team shipped slower using Agile") and then you pull out the fallacy ("Real agile ships products faster").
The vegan one doesn’t fit, that's just gatekeeping. The other ones could fit depending on framing, but the general statement that "Agile works" is kind of hard to refute. It has advantages and disadvantages, the meaning has changed a lot over time, there are lots of flavors and degrees of seriousness, but overall I think it's pretty uncontroversial to say thr movement improvemented software development as a while, even for people that only sort of follow it (i.e. don't). Go back and read what people were saying in the 90s if you weren't working yet then. It was a lot worse.
PM_ME_A_STEAM_GIFT@reddit
How did they do it where it was right?
Shikadi297@reddit
No work added to a spring during a sprint, story points not tied to time but to velocity, velocity not being molested by manipulating points mid sprint (i.e. tasks are all or nothing, because it will average out, and pretending you did half a task or whatever taints the original estimate in favor of inflating that Sprint's velocity rather than accepting that some sprints will have more points and some will have less) actually maintaining a prioritized backlog, letting stand up be stand up not status, using the concept of a parking lot.
On top of this, it was an embedded product with FPGA images and firmware to go with it, which is probably the hardest type of project to manage with scrum in the first place. We all spent a week reading a few chapters out of a book, and tailoring the process to our needs, so we were all on the same page. The only flaw was setting future deadlines based on velocity without accounting for obvious buffer that we said would be needed for unknowns, but if we had accounted for that, we would have delivered a solid product on time.
If I remember correctly we still got it done on time, but they made us work overtime without extra pay to do it for a whole summer in a state where summer is short and winter is long. So I left the company because management punished the engineers for not meeting the deadlines the engineers warned them would slip on day one.
In my current role, story points are half day time units, we are pressured to under estimate and under deliver, we're encouraged to subtract points on tasks every day despite meetings consuming 70% of some days and we may not even touch sprint work, work is added mid sprint, estimates are changed mid sprint, and standup lasts an hour because it's a status meeting. Also the tools we use suck. Anyone who hates JIRA has no idea how much worse it can be.
PM_ME_A_STEAM_GIFT@reddit
Thanks for the detailed answer and sorry to hear the current situation.
Do you remember the book you read? Would you recommend it to a young company with 6-8 engineer struggling to properly implement scrum-based development?
How did you estimate story points? Did you account for the fact that a (time) estimation heavily depends on which developer works on a task?
Shikadi297@reddit
On the estimation side of things we started with 1 point being a task that could roughly be completed in one day or less, and used Fibonacci numbers from there. So if you felt like it would take 4 days, you estimated 5. Anything 8 or more we would try to break down if we could, but sometimes things are just 8 when you're not working on simple stuff and that needs to be okay. The important next part is, even though the estimation was made in relation to time, the evaluation of sprint points is not. If an individual velocity is 5 points per sprint even though you would expect 10 based on the time estimate, you would only add 5 points worth of tasks. If that developer finishes early, great, they can help work on other tasks. Or this is the one case where it's okay to add tasks, basically when a dev is out of tasks but other tasks are specialized so they can't meaningfully contribute. The other thing is, if individual velocity is lower or higher than others, rather than saying that person is performing differently, management needs to recognize that they're estimating differently. You really can't neasure performance based on how many sprint points a person completes in a sprint, because it lacks all the information about an individual such as how many meetings they need to attend, how much of their time is spent helping others, the quality of their deliverables, and their overall impact on the team. A good manager can see these things without micromanaging and without relying on individual velocity. A good manager recognizes that engineering is full of unknowns, and estimates are inherently difficult. A good manager understands that velocity is a tool to get better estimates, not to measure performance. And most importantly, a good manager trusts their engineers to be honest with their estimates. Be careful asking why a task is larger than you think it should be. If you think that's the case you can discuss it and suggest breaking it down, but don't ever override it, otherwise that person's velocity becomes a reflection of your estimates instead of theirs. (Specifically in the case of estimates being tailored to individuals rather than the team)
Backlog grooming and estimation should still be done as a team, sometimes when I would estimate my tasks I wouldn't really know how much work it would be, so I'd look to a more senior engineer and ask what they thought and go with their estimate. But the estimate still takes into account who is doing the work that way, and team velocity is still a meaningful reflection of how accurate estimates are, which can be used by management to estimate delivery dates. If dates are too far out, remove tasks or add people, don't ask people to lower estimates because that becomes dishonest and breaches trust.
The book we read (and I think we only did the first 5 or 10 chapters, it's been a while) was "Agile Software Development with Scrum" by Ken Schwaber and Mike Beedle
Most important, everything I said and everything the book says are suggestions, if your team disagrees then agree on something else.
I'm a fan of kanban when management doesn't understand scrum, because it gives management visibility into what people are working on but doesn't waste engineers time on sprint planning and retrospectives which lose value if not being used as a tool that puts engineers first. The downside of course is it makes estimating dates very difficult for management. Personally I've always thought two week sprints are too short, so you can play around with that. Maybe start with two weeks for a few months so you can get some retros in and fine tune the process, then switch to 3 or 4 week sprints to avoid wasting time with too many sprint related meetings.
I also really prefer standup to be only two or three times a week, if an engineer is blocked they should feel comfortable reaching out over slack or in person to get un blocked. A compromise is to do virtual stand-up on the off days
It's also really helpful if upper management is on board, in our case the directive to do scrum came from the CEO, and everyone in the engineering chain read the beginning of the book, so we were all on the same page. That way my manager's manager knew velocity wasn't a metric to track my team's performance, and let it be a tool for the engineers and direct manager to improve estimates, not to measure performance or squeeze deadlines. There will always be some push from upper management to track velocity, so it's also a front line manager's responsibility to push back on that and remind upper management that's not how it works, and their job is not to manage engineers, that's what the front line manager's job is. If they think they can do it better, then they should be the front line manager.
Just like in engineering, you'll have senior engineers that can do a better or faster job than junior engineers, but their job is to grow the juniors, not to do the work for them. Upper management needs to trust lower management, and provide guidance and tenants and mentorship, not do their job for them. Especially because engineering management is a much more fluid type of job that deals with people, not code, and every team's needs are different
PM_ME_A_STEAM_GIFT@reddit
This is very helpful. Thank you so much for taking the time for writing it all down.
Since you are talking about individual velocities, do I understand it right that the estimation definitely always takes into account who is going to work on a given task?
So at the spring planning meeting, you take the highest priority item from the backlog, assign it to someone and have that person (with the help of the team) give an on the spot estimation. Repeat until everyone reached their personal velocity average. Or did I misunderstand?
So far I was under the impression that estimation would happen earlier, while grooming the backlog, and then during sprint planning you add the amount of items corresponding to the team velocity. And that the assignment is a bit more flexible, with some items assigned during planning, others staying unassigned until someone takes it on.
Is everyone's individual velocity public knowledge? Does this not result in a sort of leaderboard? And do the individual velocities not drift apart completely overtime? If someone overestimates and then over delivers by 1 point every sprint, they will have a velocity of 35 after a year.
I will check out the book you recommended, thanks!
Cheraldenine@reddit
What is that?
Shikadi297@reddit
If something comes up in standup that requires discussion among three or more people, instead of discussing it immediately, you put it in the parking lot, i.e. make note of it and move on. At the end of the meeting, anyone who doesn't need to discuss parking lot items can leave, so the discussion doesn't waste anyone's time
crav88@reddit
I have the same experience. Scrum was always done, in some form, to appease clients, bosses and managers, never about the team's work. Always to show what's being worked on to the PM and managers.
Sage2050@reddit
And thus, as usual when these agile discussions come up, people don't hate agile they hate being micromanaged.
WonkaPsychonautovich@reddit
I hate both.
crav88@reddit
You and me brother, you and me.
Kanban is all the management needed, 90% of the time. The best project i worked on was managed in kanban and had competent analysts and PM that identified and broke down the tasks amazingly. It was very satisfactory to close 1 or 2 cards every single day and see everything going well.
Sage2050@reddit
Kanban (my preferred framework as well) is an agile framework.
Cheraldenine@reddit
It can be agile. It's not automatically agile.
crav88@reddit
From what i've seen it is based on agile concepts, but also, anything that involves efficiency tends to be lumped into agile, and it was conceived in the 40s, before agile if i'm not mistaken.
Also, is it not a method instead of a framework? It's just a way of managing tasks, without any rules about meetings, deadlines, etc. Scrum is a framework in this case.
Sage2050@reddit
Kanban predates agile but it fits neatly into the principles of Agile with only a little bit of tweaking. I don't think there's anyone who would say it isn't agile. It's important to understand that the [agile manifesto] (https://agilemanifesto.org/principles.html) says nothing about meetings or deadlines, or any of the things people hate about scrum, and basically boils down to "be flexible'.
Whether you call it a framework or a methodology is just a choice of words, a framework is just affixing a set of rules to agile principles, in kanbans case that's the progress board.
hlipka@reddit
crav88@reddit
Yes. Although, if you read other comments, the majority of scrum/agile is wrongly applied, so you get a correlation almost 1:1. In other words, hating micromanaging becomes hating agile in the real world.
Cheraldenine@reddit
Yes. Agile says "build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
So the moment micromanaging appears, it's not agile anymore.
But nobody really does agile.
chakan2@reddit
Doing it right means standing up to leadership and protecting your developers.
I've only seen a couple of project leads that were good at that in my career. The rest of them cave and come up with absolute ridiculous features or changes in direction every two or three months.
Comprehensive-Pea812@reddit
maybe they are doing it right.
maybe scrum is wrong.
11111v11111@reddit
If everyone you meet is an asshole, maybe you're the asshole.
valkon_gr@reddit
Yeah it's time to talk about this.
iamiamwhoami@reddit
Doing Scrum right is challenging. It requires a really good product owner that can effectively talk to the dev teams, product, and engineering leaders. TBH I've never seen a product owner qualified enough to do this. Anyone who might be qualified enough to do this ends up going into engineering, product, or management, since those roles are much more plentiful and companies usually know how to handle them better. Largely because of this most teams do Scrum wrong.
In retrospect I think it's interesting that so many companies focused on hiring professional Scrum masters, which is largely a useless role and ignored the role of product owner, which is the much more important leadership role in a Scrum team.
G_Morgan@reddit
Ultimately scrum is a framework by which a sensible process can be created while leaving freedom for managers to do stupid manager shit regardless.
Successful software processes will always select for stupid manager shit.
djnattyp@reddit
Anna Karenina principle - All happy families are alike; each unhappy family is unhappy in its own way.
aykcak@reddit
Wow. 0 in 7 is a very bad score. Either you are extremely unlucky or there is some industry factor
DaGreenMachine@reddit
Yep. This article is the same as every other anti-scrum article. Scrum is bad because. The last bullet that scrum is bad because it is also waterfall just proves that point.
Bad scrum is bad. To varying degrees every bullet point of this article could be used in a pro-scrum "how not to implement scrum" article.
deathtopenguin5@reddit
Without siding with anyone, in my opinion this debate just rages on forever:
A: "My experience of this system is bad."
B: "No you are just doing it wrong, if you did it right it would work."
A: "But the majority of people's experience with this system is bad. So it clearly has large problems and it isn't just me."
B: "The majority of people do it wrong. So the majority of people have a bad experience."
A: "If the majority of people get it wrong in the real world, isn't that also a fundamental flaw in the system that makes it bad?"
B: "The system itself is good, it's just the teaching of the system that is bad."
...etc. It's like people who argue about whether true communism could work in the real world. Just for laughs:
EveryQuantityEver@reddit
Except almost every instance of people "doing it wrong" boils down to a lack of management buy in. I don't know of a single system out there that would stand up to management not buying in.
No-Magazine-2739@reddit
The question is: Are bad scrum implementations the majority or the exception. By my personal count the non agile, worst of both worlds waterfall BS ( I am looking at you SAFE) are the clear majority. So the point would be „scrum failed because it/we/„the community“/„corporate world“ was not able to convey its concept“
chucker23n@reddit
I wouldn't be shocked if they're the majority, because
cybernd@reddit
My idea was to figure out if i can clarify one typical friction point:
Are developers allowed to pick² lower priority items from their PO's backlog: yes or no?
I just looked into the official guide pdf, page 8, sprint planning.
First gut feeling: "yes" because selecting implies that devs are allowed to make a choice.
But, little bit above it states the following:
So even when developers are allowed to select items, the PO is supposed to ensure that they only discuss his most important items. => Now my gut trends towards "maybe". This could be interpreted as the PO ensures that they discuss prio 1-5, but they are still allowed to select prio 1,2 and 5.
But what if the clever PO decides to discuss only prio 1-3 because he knows that those items reflect his teams capacity? Suddenly my gut feeling trends towards "no", because the PO is allowed to force that condition.
Keep in mind that this is a typical friction point because in many teams the PO ranks above developers. In such cases it will will be usually interpreted in his favor.
Have I overlooked an important passage that clarifies the ambiguity of my simple question?
² I avoided the term pull. If the answer is no i would interpret it as push.
bramblerose@reddit
No, your friction point is one of the problems in many "Scrum" implementations. The planning should be a consensus-based process: the PO has a better understanding of priorities and value while the developers have a better understanding of costs and technical tradeoffs. They can only decide on a good increment by working together. You can also see this in the order shown in the guide:
First, the PO proposes how to move the product forwards; the team as a whole discusses how to make that into a goal for the sprint Only then, based on the sprint goal, the Developers decide which tickets go into the sprint.
So there's no "PO decides you have to do these five tasks", and also no "Developers choose the five tickets they enjoy". Instead, professionals based on their different perspectives plan a path forwards.
The question then becomes: if you have professionals that are competent enough to do that, do you still need Scrum?
Dragdu@reddit
IME: nope.
Pretty much every place I've worked at either had Scrum forced on them due to management and did it badly, or moved away from it in the direction of Kanban, and the delivery quality only improved.
The best use of Scrum is training wheel for corps that are still stuck in the past, but have the management and devs willing to learn to do better. But in 2024, that doesn't match many places.
MoreRopePlease@reddit
My PO says, "here's the priorities". A dev says, "hey we need to do X for reasons A,B,C.There's some discussion. It's decided to bring X into the sprint plan and kick Y out to next sprint.
It's collaborative. The team decides. The team commits. The PO is not an authority figure.
SoPoOneO@reddit
When you note that scrum isn’t that well defined, are you thinking the official guide should go into more concrete detail? https://www.scrum.org/resources/scrum-guide?utm_source=google&utm_medium=adwords&utm_id=psmii&adgroup=%7Bgroupid%7D&gad_source=1&gbraid=0AAAAADyZLu9TvsftaouibeUngUtb66ZMf&gclid=Cj0KCQjwrp-3BhDgARIsAEWJ6SzoDid-eEDEWjun8xtbesBgoumE9dDimyRdXCfULK3ie7jAB_Rg2VcaAqIhEALw_wcB
No-Magazine-2739@reddit
I think you can not define it better as the agile manifesto already did. Because if you didn’t get the idea or „mindset“ by reading it, everything more going into detail just leads to that check box thinking.
aueioaue@reddit
You absolutely can. Scrum is not defined by nor part of the agile manifesto, but instead a standalone methodology with a [readily accessible definition|https://scrumguides.org/scrum-guide.html].
No-Magazine-2739@reddit
The latter one :-)
Additional-Bee1379@reddit
Well enough to see what people are complaining about just literally is the opposite of what he scrum guide says.
Disastrous_Bike1926@reddit
No TRUE Scotsman…
Additional-Bee1379@reddit
Yeah and the Democratic peoples republic of Korea is democratic because they say so, right?
pydry@reddit
It's bad if you follow it to the letter, too. For some reason, this critique isnt allowed though - every time I challenge it on the basis that I tried it correctly I get subjected to the no true scrumsman fallacy.
The whole concept of sprints is dumb - it encourages mini waterfalls. It's better to scrap the whole thing (i.e. kanban) and incrementally move to a process of continuous delivery.
Cheraldenine@reddit
Sprints are a defense against stakeholders wanting to change priorities every single day.
If you don't have that problem, you don't need sprints, imo.
pydry@reddit
Id argue that this often isnt a problem and that actually you should probably embrace changing priorities based upon new information.
Provided I can finish the ticket im working on i do not give a shit how often the next ticket in the todo column is changed.
mpyne@reddit
Sure, but you should allow some inertia to filter out high-freq noise.
The Navy doesn't recruit a new Sailor each time the 350,000+ billets is incremented by 1 or 2. It smooths out changes to the list of billets into a personnel authorization that is updated no more than twice a year, to give the rest of the people people a stable demand signal to target.
Similarly you don't actually want to swing wildly to chase good-idea fairies whenever they present themselves. Sometimes the change in priority is to revert back to the old priority.
RDOmega@reddit
I hate Scrum and still agree with the need for protection from stakeholders. I've worked at places where leadership came every morning with their unfiltered thoughts on world domination. It annihilated the team in 6 months.
Which comes down to what you're saying here. It's at a much high level of sophistication than what most organizations will afford devs. So I think Scrum in some part was trying to do it as a hack, and then backfired.
pydry@reddit
Scrum isnt a substitute for a product manager who knows when to say no.
Cheraldenine@reddit
In my experience it's usually because this stakeholder doesnt agree with what the other stakeholder changed them to yesterday, or because they got a random idea on their commute this morning.
Of course you can finish your current ticket, provided of course you can do that and the new one today.
In those jobs Scrum would have been a big improvement. Now I have the other problem where no stakeholder feels any urgency at all, it's much less fun.
pydry@reddit
That's a symptom of either a very weak or nonexistent product manager.
DualActiveBridgeLLC@reddit
Naw, sprints are the mechanism of ensuring that problems are appropriately broken down, that progress can be shown to stakeholders to get timely feedback, and that you stop and reflect on where the project is going frequently, the good and the bad.
If you can do those things without timeboxed sprints then more power to you. Bu tthe problem is that people often think they are doing a good job at those things when in reality they are not.
If you are using sprints as a shield from changing priorities then you are using sprints ineffectively since that is not what they are for, and why sprints don't solve the problem of changing priorities.
Cheraldenine@reddit
Those other things dont need the time boxing of the development work. You can plan meetings for them every x unit of time independently of the work, or you can show progress every time a story is completed, etc. Sprints really were invented to provide some sense of stability in the work load, that the to do list couldnt be changed more often than that.
ehaliewicz@reddit
Scrum ensures that no hard work which cannot show progress within two weeks will ever be done, and promotes low quality work which can be rapidly pumped out to indicate productivity to managers.
DualActiveBridgeLLC@reddit
That is a timeboxed sprint. You set the timebox, then you determine how much can go into the sprint.
Or you can group them together to make mini-goals...but then that is a sprint.
They are pretty terrible at doing that. If your roadmap is changing that significantly every 2-3 weeks you have a larger problem that sprints cannot fix.
Cheraldenine@reddit
No, just that the meetings are regular doesnt mean there is an expectation the work also fits neatly between two meetings.
JodoKaast@reddit
Now they get to change only every 2 weeks! Progress!!
JayantDadBod@reddit
I mean, yeah. Yes. Exactly.
It may seem silly if you haven't experienced it yourself, but that is kind of exactly the point.
r1veRRR@reddit
Absolutely, with a correctly communicated limit. If they want to change things every 2 weeks, they see in the sprint log exactly what they're getting/not getting.
alerighi@reddit
agile != scrum. Agile simply means embracing changes during development, contrary to waterfall where you plan everything in advance and then execute.
You can be agile without doing scrum. To me scrum is bad for three reasons: one it take away responsibility from the developer, that is only focused on the activity it's doing, without a full overview of the project. I tend to feel it as a form of work alienation, the same way it was the series productions back in the industrial revolution, you only do your piece, not caring about everything else.
No matter if the project would have needed a refactor, that would have made things worse, just look at your piece of the job and done, if you "loose time" improving things, that later will make you save time in other activities, you are a bad worker since you didn't complete the activities in time, no matter if the developer that came later got a big speedup for the work you did, this cannot be understood by managers (even managers that have programming experience in the past!).
The second thing, and I see the article describing it perfectly, is the fact that scrum is used to make pressure on the team. Pressure that results in cutting corners, writing unit tests? There is no time, otherwise you don't complete the activity they assigned to you in the sprint and the manager is not happy. Writing documentation? Are you kidding? This often lead to poor code.
And finally, there is never time to learn new things. All you have to do is do stuff and deliver. No space to improve things, no time to test out that library, try to see if that design pattern applies, if that refactor will give you a benefit, if the performance of that algorithms can be improved. The important thing is that activities are done in the board, nothing else.
I often get asked by my manager "what you are working on? You don't have any activity assigned!". I have to explain that yes, project may need work even if you don't have specific activities. Do you do oil changes on your car, or only take it to the mechanic when it breaks? Software is the same.
Sometimes having "spare" time to just look at a project, see how it can improved, make experiments, it's essential! With scrum if you have spare time the next sprint they say "well, so this time let's just assign to you more activities, since you finished earlier".
I don't like this. Fortunately I'm in a company where I'm in a position where they tollerate the fact that I don't follow the procedures, just because I'm the one that are there to fix the problems when they are there. Problems that by the way are often to me derived on the scrum development methodology, the result of a constant pressure of going faster.
RonaldoNazario@reddit
Whenever we get to the point where we toss aside some of the parts of scrum/agile that would be nice it’s because of the same old business demands. Are we confident this sprint? Well no, we need to do twice as much as our velocity normally is to meet the release deadline that is driven by some pdm wanting to announce something at some tech event. Can we re plan the sprint and release to meet our normal velocity and not have people crunch? No we cannot. You’ll get pizza after everyone crunches to get it done!
iiiinthecomputer@reddit
I show PM the quality triangle fairly regularly and ask them to say - usually on recorded meetings or in writing in public chat channels - where they want me to cut.
JodoKaast@reddit
At a certain point, after reading about (and experiencing) endless instances of scrum not being implemented correctly, and not ever hearing about (or experiencing) a single instance of it being implemented "correctly", the rubber has to meet the road.
GimmickNG@reddit
Someone else mentioned No True Scrumsman and it fits wonderfully here, if the majority of Scrum implementations are bad then Scrum is bad. It's constantly excused for its shortcomings with people claiming that it's just not implemented correctly.
At what point do we acknowledge the emperor has no clothes?
pydry@reddit
I honestly thought scrum went out of fashion years ago. In the last 5 or so years ive just done kanban and the amount of talking about process has gone way, WAY down (thankfully).
Im really surprised to see people still defending scrum like it's 2012 or something.
josluivivgar@reddit
I had my team forced out of kanban into scrum and saw the development process become tedious....
I miss kanban q___q
iiiinthecomputer@reddit
My team is forced into the nightmare Jira implementation of Scrum + management misunderstanding. We have fractional story points where 1 point is 1 day - point completely missed. I have never found story points particularly useful anyway, but this makes it worse.
Even "better", our tooling and workflows are tied to Jira tickets. So splitting ongoing work across sprints is really painful because the ticket number flows through into branches and builds and test deployments and more. But Jira won't let subtasks be put in sprints. So I often have a ticket for the workflow and other associated tickets in sprints for the work.
The saving grace for all this is that my manager and the immediate upline don't care about the formal process. Only what works, and what we can get away with within the framework imposed on us.
So we land up doing something closer to kanban much of the time. Sprints are fluid, we pick work from backlog as needed, we shuffle sprint scope as needed, and we manage our own priorities under overarching goals from product.
Nothing stops me from noticing a low priority but annoying issue, opening a ticket and fixing it on the spot if it's small enough to count as a "just do it now" item. And I'm rarely if ever questioned on my ticket queue and board, except for "why is that blocked and do you need help".
Sage2050@reddit
people don't flock to message board to talk about when things are running well. I don't personally think scrum is a good system, but "everyone complains about it online" isn't the condemnation you think it is.
Additional-Bee1379@reddit
My company implements scrum just fine.
jl2352@reddit
The fundamental problem is most people are just bad at running a team. It is a hard and difficult problem that requires a lot of knowledge and discipline to get right.
What makes it more frustrating is people are often good enough that it becomes difficult to point out their flaws and get them improved.
As I am getting older I am coming to the opinion that even more innately, it ultimately comes down to the roll of the dice on personalities.
RDOmega@reddit
Right there with you on this one. I think there's loads of truth to the whole topic of "personalities". But people take it the wrong way and read it as "in order to succeed, I need people most like myself".
Reality is, it's going to be more about how disagreeable and intuitive your people are than how well they can coexist. Though I might add the caveat that coexistence is still a pre-requisite, haha.
PathOfTheAncients@reddit
I heard it said before (and I subscribe to the idea) that people unconsciously seek to create environments in which they would thrive. To me this explains a lot of the nonsense at work when I think about who seeks out authority and gets into positions of power in most work environments.
jl2352@reddit
I’ve worked with people where they are willing to try things, give feedback respectfully, and if it doesn’t work it’s fine. We do something different and move on. Those teams were great and productive, and we received a lot of great feedback.
Then I’ve worked with people who just fight and disagree. They don’t intend to be an asshole. They just have a counter point for everything. Sometimes it’s good, but often it’s a constant uphill battle. Everything takes five times longer to get moving. Ideas are not tried because they can’t be proven to a high enough degree. Those teams did, at best, fine. But never great.
Those teams which did well often had engineers who wanted to do a good job. But it was just a job to them. Not life or death. So they would be pretty chill.
RDOmega@reddit
Yeah, that tracks for the most part.
What interests me is how many might take all of your points and generalize them or look for soundbites.
For example "pretty chill" is often interpreted as first-order, after "skill". So then places might come to assert that their best talent can only be the least-opinionated. Mainly to ensure that other talent doesn't feel inadequate. But then they struggle with technological execution because their senior decision makers are too politically motivated to avoid picking directions.
It also factors into the inevitable situation where someone says "it doesn't have to be perfect" vs "it still needs to be good".
These are subtle distinctions and I don't say any of it to disagree. You still need people who are willing to try things rather than sit and snipe from the sidelines constantly. But it's interesting to think about the messes we get into when people avoid thinking on their feet.
agumonkey@reddit
The thing is, what can you organize in a two week period ? unless a great team with zero friction you'll only pile up thin layers of low skill value and potential soon-to-be-debt.
I feel worse doing that than learning haskell all alone. So weird.
winkler@reddit
Sprint length is arbitrary.
Points are arbitrary.
It’s about communicating to non-engineers what the plan is. And over time you get better at it. Furthermore it simply doesn’t matter what you do unless leadership values and trusts what engineering (not product) says.
I look back fondly to a company that successfully implemented Agile / Scrum bc we had a chief digital officer who believed in it and empowered everyone to follow its guidelines. Product was also wrapped up under engineering so it worked in our favor. IMHO, every point people are talking about reflects the people and not the principles.
agumonkey@reddit
that's the issue, it's very subjective in the end. Many times people said no matter the methodology, what matters is the quality of the team (skills and ability for team work).
winkler@reddit
I’d agree but of course I just joined a company that is off the ledge with SAFe and it is 100% the methodology in this case lol.
iiiinthecomputer@reddit
Depends a lot on the subject matter.
In typical business development there isn't a lot I can't break down into sub week chunks. Even if sometimes it's "research the thing," "test alternatives for the thing," "select the thing," "do a crude proof of concept of the thing," "do the thing reasonably well," "finish remaining tests and documentation," "polish the thing".
The danger of course is that the earlier bits slip and the later bits get cut. But I build docs and tests into the whole process to mitigate that.
winkler@reddit
What you’re describing sounds a lot like Spikes, which you can time-box and evaluate. You’re also basically talking about iterating, which is a guiding principle of Agile that you’ve used different words to describe.
It sounds like you have a lot of autonomy which is great, and it would be interesting to know where the bottlenecks arise for you.
agumonkey@reddit
One concern I have is that adding on thin features on top of thin features ends up with a glass noddle bowl with incoherent logic spread everywhere.
iiiinthecomputer@reddit
Right. I tend to develop incrementally and price the needed ongoing refactoring into the future work for this reason.
It's not perfect but what is?
agumonkey@reddit
At least you're well organized, in some shops there's no allocation for proper refactoring. They can later sell their bug farm to the most clueless.
thebuccaneersden@reddit
I applied agile/scrum correctly in one job and it was successful. Until the company hired a product manager to the level of director and suddenly I had to start using Ms project to make waterfall style projections and that’s when everything went to spit. Moral of the story is companies don’t like dynamic and productive teams. They just want fancy charts because they have their own insecurities.
PathOfTheAncients@reddit
Business and management sides do not like "real" scrum or agile. They have all the power so teams will never get scrum done in a way that helps.
LessonStudio@reddit
When I found out about "Agile Coaches" I laughed out loud.
Agile takes away pretty much any autonomy of highly intelligent programmers. But, often to the benefit of managers.
Now with Agile Coaches, those managers were thrown into the same swamp of suck they had shoved the programmers in.
It is just micromanagement with a different name.
EveryQuantityEver@reddit
The entire point of agile is that the developers should be the ones in charge of how they develop software.
LessonStudio@reddit
To me this is the core problem with agile. Almost every one is doing it wrong.
This is like a religious warrior telling his troops that their faith will make them bulletproof; then he tells the survivors that they were the only ones with enough faith.
When nearly everyone is doing a system wrong, then it is the system, not the people who are the problem.
For example, you should never mix a chlorine based cleaner with an ammonia based one. Many fast food places had idiots mixing the two on a regular basis with tragic results. So, pretty much all fast food places now mandate that only very specific cleaners be used. These can mostly safely be mixed.
They didn't blame the cleaners, they didn't blame the workers, they just made a better system.
Agile is like having ammonia and chlorine cleaners. Properly used they are fantastic and between them will clean almost anything very well. But only if exactly used correctly.
EveryQuantityEver@reddit
And I disagree. When Management refuses to buy in, then that's purely a management problem. I've never seen one methodology that would stand up to management, and I don't think it's fair to blame the methodology for what are very, very, very clearly management issues.
When management is the problem, then what's the better system?
No. It's when developers are in charge of how they work. I don't think that's an "exactly correctly" situation.
That's a fucking management problem. You cannot, in any semblance of good faith, blame that on whatever methodology is being used.
Agile literally says that the programmers should be the ones in charge of how they work.
I'm very sorry that you have shitty managers. But the blame for your issues lies solely with them.
LessonStudio@reddit
My argument is a bit off what you are saying. I suggest that bad management encourages bad agile.
But that good management results in teams which don't use agile.
There really is no good agile, just some ideal that nobody reaches other than dogmatic puritans; who work for bad companies which allow for dogmatic puritans.
OursIsTheFury@reddit
How so?
LessonStudio@reddit
The post in this article describes it quite well.
Most places I've seen doing agile follow roughly this formula:
There is no real room for experimentation, for architecture rethinks, for tech stack rethinks.
Whereas a company with a healthy approach has teams of programmers where a leader has imparted a vision. This is what needs to be accomplished. There is a back and fourth with any clients and the leader to refine this vision until everyone is clear as to what and why the vision is good.
Then, the team is sent on their merry way. They can use waterfall, they can use napkins, they can use agile, whatever the team is comfortable with and wants. The leader vaguely monitors what they are up to. This validates they are sticking with the vision, and that they aren't stuck. The leader primary runs interference from those who want to ruin the project, and obtains any resources they might need. There is usually an agreement that the system chosen by the team will provide enough visibility to allow the leader to easily report progress to the executive.
For example, jira might have a list of requirements broken down by section, functional module, etc. These requirements might move through various stages, architecture, design, development, testing, and deployment. Once glance at the project system (can be jira) will allow instant visibility for anyone to see. They can perform whatever metrics they would like. A simple one would be a graph showing the requirements completed per month.
If the team realizes their tech stack is a dead end, then they can throw crap out and restart. That is up to them. The leader will settle disputes between the team, or different teams. Maybe one team wants to communicate with XML, another json, and another in some binary reflecting structs. This is where the leader will act as a supreme court, hear the case, and make a decision.
A leader like this can run many large projects simultaneously. This is where you can instantly detect someone is a manager, or even a micromanager. If they are having regular meetings with the team, and can only handle 2 or three projects at a time, then they are a micro manager. If they are comfortably handling one or two dozen projects with nobody below them acting as a manger, then they are a very good leader.
Most agile projects have a hard core micromanager running them.
People might scream. "But that's not proper agile" The reality is that it is how most companies do agile, and something is wrong with agile that it gravitates to micromanaging programmers and not giving them any autonomy other than in extremely narrow and highly constrained situations.
EveryQuantityEver@reddit
That's all very clearly an issue with management. Name any other methodology that would stand up to such management.
LessonStudio@reddit
Exactly. Company culture is going to dictate how well their development works. But, there is a grey area where management is so so, enough that they would not actively push a bad system, nor push against a bad system. This is where bad managers/leaders can pick agile as their favourite micromanagement solution.
kenfar@reddit
What you're describing are cultural issues not scrum issues:
How would giving that manager a different process result in better results?
bwainfweeze@reddit
I hate when a company makes me have to become a crooked accountant in order to be successful, and that's what happens about half the time when you need a major architecture change for a project. You end up 'embezzling' to take time from other tickets to make progress toward an epic that's small enough and simple enough to get approved. Even a spike sometimes only comes after you've softened a target by doing things you were specifically not asked to do, or specifically asked not to do.
NP_6666@reddit
By setting arbitrary virtual deadlines
bwainfweeze@reddit
Unfortunately there is actually something to the idea that arbitrary deadlines decrease the rate at which projects expand to fill the available time. Early in the project we are so eager to add one more thing to a design, either our idea or someone in business, because we have plenty of time to make it up later. But later never comes.
Do I resent it a little bit that I now think this way? Yes, yes I do. But is it wrong? Maybe (hopefully) by degrees. But no.
LiquidLight_@reddit
Well, at least for me, it's all about managers feeling like they have control of what's being delivered. Everything agile flavored at my company feels like another hook for micromanagement to grip. And that starts to play in performance review and promotions. I should find one of these miracle jobs where agile actually works for the devs and not just management.
Green0Photon@reddit
The original Agile manifesto was fine. It was really lowercase agile.
The problem is everything built on top by the consultants and micromanagers, which they call uppercase Agile.
Scrum was created before agile, and was never an agile methodology. They just shoehorned them together.
Turns out, if you actually focus on individuals and interactions over processes and tools, and if you focus on actually working software over planning bs, you actually get somewhere. That's literally me paraphrasing two of the bullet points.
But scrum and Agile and so much other bs is the direct opposite of that.
LessonStudio@reddit
When a complete and easy to implement system of software development is created, its core will be this line of yours.
sjepsa@reddit
Because it is pseudo science bullshit?
opened_just_a_crack@reddit
Honestly I feel this so hard right now
netfeed@reddit
When I worked in scrum environment, the most annoying part of it was that there was so much focus on the burn down charts, and that it didn't have a stead decline over the spring, but fell only the last 2-3 days of the sprint. So the stakeholders/product owners kept bugging the developers about that. The focus wasn't on what was being delivered, just the charts.
Then there was a lot of issues with more things that was put into the sprints, but it was just hand-waved away each time we questioned why we didn't aborted the sprint and did new sprint planning as our "contract" for working with scrum was detailed...
PathOfTheAncients@reddit
It's depressing how many teams I have been on where people can't pull work into sprint because it will mess up the burndown chart. The managers would rather you do nothing than upset the chart or they tell you to secretly work on it without pulling the card in.
RonaldoNazario@reddit
In a certain letter of 'the law' you're not supposed to put something into a sprint if you're not confident you'll complete it. But it is rather silly how often we finish what we have for a sprint, don't want to pull in the next item, lest we get yelled at if it then 'slips' to the next sprint.... so someone just quietly starts doing the work for that next story, today, this sprint, but doesn't actually put it in the sprint.
allo37@reddit
I remember exactly this at an old job, when the scrum master complained I'd just reply "Oh no, won't somebody think of the squiggly line!!"
theediblearrangement@reddit
i still don’t understand how anyone can be reasonably expected to predict what they can or can’t get done in an arbitrary block of time. i feel like you either overshoot or undershoot by a wide margin.
Cheraldenine@reddit
How much experience do you have?
I mean on any given day, sometimes smaller things differ by that much. But over a longer time it evens out, and estimation can be done quite well.
theediblearrangement@reddit
that’s the problem. assign me something trivial? it’ll probably take a day or two. assign me two things that are trivial? a day or two times two. for another one? a day or two times three… see how things become less certain as more items are pushed into the queue? unless things go absolutely perfectly over the next few days (meaning i don’t get stumped on anything, other parts of the project are available and work as expected, client is available when i need them to be to clarify something, etc), there’s a high likelihood that schedule full of easy and trivial things starts to slip.
the business needs to take into account the high degree of uncertainty that comes with the domain and budget accordingly. blaming the developers for not being senior enough isn’t going to get the thing over the finish line any faster.
i’m saying this as someone who, despite individual items fluctuating pretty wildly sometimes, tends to get most of their work done by the deadline when they commit to it. don’t assume everything will go perfectly in a schedule.
even one of the founders of agile made a joke (ragging on planning poker and the like) about deadlines: in the old days, the PM could give you a list of work items to be completed each month for the next six months, and when you got to the end of six months, you knew you were halfway done.
it’s not a new problem by any means, and seemingly doesn’t have much correlation with YOE.
theediblearrangement@reddit
i originally cut my teeth in an environment that was extremely unstable. how long would it take to get X done? probably a few days at most. but X depends on Y, and it turns out Y is either not behaving in the way the customer documented it or is completely unavailable, and we’d have to go through a bunch of meetings to figure out why. so a task that takes me relatively little time to execute on paper now takes at least several weeks as we navigate through all the red tape.
maybe there’s a secret sauce i’m missing, but i don’t know how anyone can make reasonable time estimates in an environment like that. it left a bit of a chip on my shoulder as far as planning poker is concerned.
i’ve since moved into something decidedly more low level, and i’ll admit it’s gotten easier because the only dependency for most of what i do is me. things still fluctuate a lot, but somehow it all gets done in the sprint in approximately the amount of time we were expecting.
RonaldoNazario@reddit
In other arenas you can obviously right? Like when I’m laying patio pavers I can reasonably tell you when I’ll be done once I’ve made it through part of the job. I can tell you about how long to paint a room because I’ve done it before.
The problem is basically that isn’t possible for complex projects and software, you’re exactly right. Scrum and other systems are all attempts to do it. Scrum will say it maybe isn’t just a way to predict what you’ll get done but it is in reality and PMs use it as such.
IntelligentSpite6364@reddit
This is where you create “chore” tasks that are doable in small time frames to fill extra days. Stuff like adding unit tests, doing training (if your company provides any), or writing documentation.
The only problem is this feels like busy work that becomes a punishment for being productive.
Alternatively the team can encourage using extra time to work on new ideas or side projects for the company (like Google’s 20% time)
RonaldoNazario@reddit
Unless I get scolded for it I’d rather we just work the next item that’s priority in reality and in jira leave the story in the backlog. Part of my job is basically shielding my team as I can from the arbitrary boundaries and distortions of how management views scrum.
IntelligentSpite6364@reddit
The problem with working ahead is it artificially accelerates your velocity and management tends to expect that accelerated pace to remain constant
RonaldoNazario@reddit
It should average itself out either way. Whether I score more points this sprint or they’re counted in the next doesn’t change our average velocity, when I show our average velocity that’s usually over six sprints or so. But YMMV, and my work is just pickier about commit versus acceptance and that stuff put into the sprint doesn’t move.
dagopa6696@reddit
Depressing for who - the product manager? For engineers that is great. That is how you get time to improve operations and catch up on the R in R&D.
PathOfTheAncients@reddit
With most engineers I have encountered their main concern is how much overtime they'll have to work to meet the purposefully aggressive deadline of their next big release. Watching someone force you to work in a way that guarantees you will have to work overtime in the future is depressing.
dagopa6696@reddit
I feel your pain but your fear is misplaced - or at most you're mis-identifying which parts of the process is broken. Breaking another part will only make it worse, it won't fix the bad planning and it won't fix the overtime.
When you do your sprint planning there should never be more work than you can reasonably complete in that sprint, just as you should never move work into an already in-progress sprint. These two things are what protects you from forced overtime and burnout and they send a strong message to the product team and managers that they have to get their shit together to be able to plan ahead by at least 2 weeks into the future.
That's really not a big ask for them to get this one part right, and it's a damning indication of a failed product and management team if they can't so much as plan work 2 weeks into the future.
PathOfTheAncients@reddit
It's not that you are wrong with anything your saying but I feel like it is all a "in a perfect world that wouldn't be true" response to very common work experiences.
I'm not a new dev. I have been on a lot of projects, in different industries, with different clients and companies. The description of "scrumfall" in the article we are all responding to is very accurate to every single project I have ever been on.
Scrum has never protected my teams from burnout or overtime. There is always a real deadline on the horizon at which point everything has to be finished by. So the amount of work per sprint gets ramped up each sprint as it become more inevitable to the PM and business that we aren't on pace to hit the target. So for those same people who are pulling more work into a sprint than can be finished to also be restricting people from pulling work in on the rare occasion when it is done earlier is even more infuriating and absolutely contributes to burnout and leads to more overtime and stress.
dagopa6696@reddit
I've also been there and done that and eventually I had to come to terms with the idea that if I don't draw the line for myself nobody else will. I'd rather get fired than continue wrecking my health for a bunch of dumbasses.
My question for you is, who on these teams comes up with these estimates that leads the PMs and the business to believe that these deadlines can be met in the first place? Were they engineering estimates? If not, just quit, it's not worth trying to fix it. If it's engineering, then you and your colleagues have to do some reflection about what it's going to take to give the business a more realistic estimate.
As a side note, don't forget Brook's law. Once a project is late, that's it. Throwing more people at it or doubling up everyone's hours is only going to make it later.
michaelochurch@reddit
"If we load them up with 40 hours of bullshit sprint work and pressure them to do important stuff too out of pride or professionalism, we get free hours!" -- Management
bramblerose@reddit
There are significant benefits to not pulling more work in - it's basically queueing theory. It reduces utilization and thus makes work more predictable (which can have value), and it also helps to focus on finishing work (e.g. by helping to finish other parts) rather than starting work.
PathOfTheAncients@reddit
I very much disagree.
theediblearrangement@reddit
queuing theory is pretty well established. once a queue is at around 80% capacity, there’s a runaway effect and lead times go up exponentially. it’s like driving on an empty highway versus heavy traffic.
this video isn’t about software, but it explains the concept well
this article explains it in a software context.
basically, it comes down to randomness. you can’t predict exactly how long it takes to process most items in a queue, so once utilization hits around 80%, that tiny bit of extra randomness per item blows up lead times in the aggregate.
it’s unintuitive to reason about at first. common sense says that if a dev can complete 1 unit of work in 1 week, then why can’t they do 2 units of work in 2 weeks and get more done each sprint? maybe they can sometimes, but it’s the times that they fall behind due to random bad luck that causes the inertia. that’s when everything cascades and blows up your velocity.
i had this issue on a previous team of mine. it was low-code and maintenance was very common in our domain. management just saw it as a cost of doing business, but every little bit of maintenance work added an item to our queue. the more things we deployed, the higher the chance one of them would smoke on any given day. eventually, our backlog was completely overrun and new work was damn near impossible to get done. and it happened fast. almost overnight it felt like.
so when management freaks out about devs pulling an extra item from the backlog hurting the burn down rate, there’s a chance that’s what they’re worried about. you need some bandwidth on reserve to keep things flowing.
it’s also a core tenant of agile IMO. you have to resist filling up the backlog with several sprints worth of work and forbid team members from getting too far ahead. otherwise, people are going to make themselves too busy and you risk doing unnecessary work if plans change next spring. it’s also why backlog grooming is critical to do every sprint.
PathOfTheAncients@reddit
This is my problem with scrum. Too many theories are implemented into practice that are only applicable in niche situations but which scrum masters get convinced are vital to success, usually at the expense of team morale.
If I and two other devs finish our cards 2-3 days before sprint end and pull work in from the already planned out next sprint there is literally nothing at risk. Planning for them to do that every time is a risk but one that is simply solved but not doing that.
But what about random events occurring? Well if I pull in a new card and then something happens where suddenly I have to pivot to a critical bug fix I simply pause work on my new card (which I pulled in from the following sprint anyway) to address the critical issue. Then when I finish, I just go back to my card. The only argument I have ever heard against this is that work rolling over between sprint but since the work was actually pulled from the following sprint, this argument seems flimsy.
The risk of unnecessary work isn't a risk. It rarely will happen that the work of the following sprint is made irrelevant and when it does that unnecessary work is only a cost to the dev whose time was wasted. As devs our time gets wasted constantly, we're used to it. You revert the commit and move on with life. Literally no risk there.
I have had this debate with PM's multiple times and it always boils down to them highlighting hypothetical situations where their stance makes sense but is not actually relevant to our teams. It also comes down to them wanting to technically adhere to be some sort of scrum purist at the expense the teams wishes. They insist it is because they want to be able to respond to change but in practice it always seems like their refusal is actually based in resistance to change. If the situation they are concerned about (however unlikely) were to occur, the team can adapt it it's practices. The only pushback to teams adapting in that way in my experience is the scrum master.
theediblearrangement@reddit
i’m actually not a “scrum guy.” i have a lot of issues with it and don’t prefer it (i hate planning poker with a passion). i like the idea of time-boxed sprints and working iteratively, but not much else.
the example you gave (something already that’s committed to and on the docket for a few days from now) is probably fine. i’m not sure who that’s hurting. i think the key is to just be reasonable about it—and to have some sort of gatekeeper in the middle to prevent developers from overcommitting and pulling things out of the queue ad hoc. i think that’s especially true at the beginning of a sprint where everyone is rosy and optimistic about what they can achieve in the next two weeks.
Cheraldenine@reddit
I'm a bit of a purist on this, but if it isn't mentioned in the principles behind the Agile Manifesto, then it cannot be a core tenet of agile.
Of Scrum, yes.
theediblearrangement@reddit
it’s not explicitly stated, but i always thought these two points imply something along those lines. i doubt the original founders had queuing theory in mind, but i think intuitively, they knew there was extreme benefit to controlling the flow of work within short time spans.
theediblearrangement@reddit
yeah the phoenix project mentions that: wait time = %busy/%idle. the busier a person is, the longer the average lead time for each item in their queue.
you can also apply it to projects as a whole as well. if you want a team to move faster, give them less to work on. that’s why you’re only supposed to work in two-week sprints in the first place. filling up a backlog full of the next several months of work, and seldom taking time to stop and reevaluate, is the exact opposite of agile.
HoratioWobble@reddit
The company I'm about to leave is currently enforcing one ticket per developer at a time.
So if you get blocked (which happens a lot because the management don't facilitate proper planning) you have to just sit and wait until you're unblocked.
They decided this rule, because they thought that's why developers were rolling over each sprint - when that still happens but now nothing else gets done either.
mpyne@reddit
Ah, reminds me of WIP management in Kanban.
Yeah we tried doing that for a bit but it was clearly impossible when you have work that you simply can't move forward on your own.
So we invented a "Waiting For ____" bin based on other boards we'd seen, which had much higher WIP limits.
This was still bad! The consultant people would tell you this is evidence we needed to improve the approvals or cross-training or whatever so that the worker could more easily push the work to "Done" without getting blocked by people. The WIP would expose the next barriers to be addressed.
But it was still a helpful in-between way of keeping the work flowing while addressing the long-term org improvements that would be needed.
Cheraldenine@reddit
Yes, the whole point of Kanban is that you try to improve the time it takes a ticket to go from 'taken from backlog' to 'in production'. So yes, if there's a place where tickets always wait, that is where you're supposed to try to find improvements.
Cheraldenine@reddit
The one thing I think is core to Agile and Scrum is that the development team decides the rules.
Product Owner says what needs to be made, dev team decides how.
BrofessorOfLogic@reddit
Of course Scrum is awful. It's like taking everything that is bad with management and putting it in a formally defined workflow process.
But in principle, it doesn't really matter what process/model is used. Some people are always going to look for ways to control and exploit other people. Managers gonna manage.
The most important thing is that developers start standing up for themselves. As the article says: it "will likely require grassroots efforts by engineers".
I see way too many developers being passive and complacent at work. Always expecting someone else to deal with it. Always just waiting for some moment that will never come.
And this article is basically doing the same thing. It says that Scrum is bad, but offers no suggestion on what to do instead. Which only leads to a complaining party in the comments.
The only thing that works in practice is to have developers lead development. Start working on that in your organization.
Talk to your colleagues and get organized. Present a formal document to the upper management stating how you want to work. Explain why it is good for the business, using cost/benefit analysis and risk analysis. Explain why it is bad to never stop and think, and clean up after yourself, and how it leads to much higher cost in the development organization. Use analogies from other industries, for example show how electricians actually have rules that they have to follow. And be prepared to fight for what you want.
Decker108@reddit
I've been doing scrum for 12 years at this point and the last time I saw a burn down chart was in 2014. No one in their right mind uses those any more.
Remarkable-Part-9602@reddit
Sounds like classic scrum stress. The obsession with burn down charts over actual progress is a killer. It’s like they care more about the numbers than the end result. Sometimes it feels like scrum gets lost in the process instead of focusing on the product
jl2352@reddit
As a lead, I wish I could keep the estimation parts of project management tools secret from the developers. Or at least not prominent so they aren’t in your face.
The charts for telling a story and predicting estimates and accuracy. If you have to bring stories in, then the chart tells you that you have random stuff coming or you’ve missed things in planning. So maybe the team should discuss improving refinements, or changing how we deal with external issues. It could also be the team just needs to underfill sprints.
All too often people get zealous and religious over SCRUM and think the ceremonies is the delivery.
Turbots@reddit
Simple change: use burn UP charts.
Simple reason: they can be stacked next to each other and the timeline can be extended to the right to make better predictions of delivery times.
Burn up charts give you much better visual representation on how your team is doing in the medium to long term.
If you do 1 sprint and score 40 story points it will be shown as a line ending at 40.
The second sprint you score 35 points and the chart for that sprint will end at 35, but the combined chart of the two sprints will end at 75.
Which type of chart is easier to predict how long it will take to complete a thousand story points?
Burn up charts!
But still, I prefer kanban over scrum, because I think it's more important to track blockers and inefficiencies in your delivery process, than to track points scored each week.
Additional-Bee1379@reddit
Burndown chart is kinda useless anyway as of course everything has this sliding window where it is in progress. Scrum doesn't say you have to use them btw.
netfeed@reddit
I'm aware, but management loved it
CTPred@reddit
Sounds like you had an unempowered Scrum Master.
The SM, and to some degree the PO so there's certainly some blame there too, is supposed to be the barrier between the devs and all that bullshit. If the SM is a pushover, or is having their hands tied by management then you might as well just ditch Scrum altogether because you'll get no value or if it, it'll only be a distraction.
netfeed@reddit
That company did a lot of things wrong, and it was also too small to have good enough barriers between the scrum master and dev team to the rest of the org, I'm happy I'm not there anymore.
Now I'm instead working with some strange "kanban" version, but the PO:s that runs it has a lot more mandate against sales/stakeholders to stand against them when they come prodding.
Professional_Top8485@reddit
It's stressing if tools don't work, sw is hack and team only tries to do simple and safe tasks quickly and bad.
Management is drawfs that believes backstabbers and fire people regarding that.
SampleSilly7417@reddit
Scrum usually becomes a compressed waterfall when management becomes involved.
lookmeat@reddit
Neither Scrum nor Agile fix bad managment. Waterfall as we know it is not what was proposed. Waterfall as we know it should be called "a naive inexperienced manager's pipedream", the kind where they just ask their employees "can you guys just work faster" and suddenly productivity skyrockets.
mpyne@reddit
Although true, it is probably still better than what was proposed, where you were supposed to build the thing one time to work out the bugs in the requirements, and then do it all over again the right way.
lookmeat@reddit
Waterfall was iterative. It was different from Agile mostly in that it handwaved the get user feedback part, which is where stories and the goal was defined in Agile. Just like scrum becomes a "we do it in just two sprints and never touch it again" when under bad management.
mpyne@reddit
As proposed, it was explicitly not that. It was linear and documentation-heavy, and the reason you'd build it once and then redo most of it was precisely because you were not supposed to iterate.
But Royce didn't handwave user feedback either. You were supposed to engage with the customer at various points throughout the process (usually in the form of "please read the hundreds of pages of docs and confirm they meet your expectations"), and user feedback was to be done as part of the evaluation of the first proto-version you built, to refine and finalize the requirements for when you then built it "for real".
You could certainly iterate it, one major version after the other, but waterfall wasn't supposed to be iterative in the sense we know it with agile methods, where you are continuously delivering small updates to get user feedback.
You could probably find even big mainframe users who were using iterative methods, especially in universities, but you wouldn't have called that waterfall.
spareminuteforworms@reddit
Now we just build it wrong the first time so we have an excuse to make updates with obviously necessary functionality PLUS DARK PATTERNS.
dagopa6696@reddit
Waterfall is just micromanagement.
chakan2@reddit
That's really what this article is about.
I'll take scrum over waterfall all day. But as soon as you add in a project manager pretending to be a scrum master and some ridiculous change management framework...you're fucked, no matter what engineering processes you're using.
Do you want it to hurt a little bit every day, or hurt a ton in 6 months?
buttplugs4life4me@reddit
Funniest thing to me right now is that the company I work for really tried to make agile scrum a reality and obviously ran into all these issues.
So they just....stopped trying. We're currently running scrum, without a scrum master, with a project manager (no PO) that is like 4 levels deep in a project manager tree that nobody can even still decipher who is responsible for what...and the cherry on top is that each scrum team consists of 4-8 different actual teams which all don't work together, but just have their daily and other meetings together. And some of the meetings (like retro) are done with 3-4 other teams together.
Like....lmao. I don't think you can say more to that than just lmao.
dr_exercise@reddit
Are we colleagues? Lmao
My shop is doing something very similar. The PM is not a PO or even the scrum master. The engineering manager serves as the SM, causing delays because they’re juggling too much. Not a single PO anywhere. Another great aspect is management will set deadlines without consulting with the teams and is shocked when we don’t meet them.
i-eat-guitars@reddit
That sounds crazy-making and intolerable to me!
Robot_Graffiti@reddit
The first half of the article is about how hurting every day is worse for your health.
chakan2@reddit
That's a personal thing. I'll take a low level of stress daily over 80 hour crunch weeks. I can manage daily dress...I can't manage stress when I'm working from waking to sleeping.
HolyPommeDeTerre@reddit
It's hurting me every day to know that it will hurt in 6 months. Or I just disengage.
Carighan@reddit
I want my unified process back. Sure, it was far from perfect either.
But it had this big upside that at the time, management understood too little about the work of software development and didn't care to change that because it wasn't as important yet, it actually let you get shit done.
Early scrum was a bit like that too, before HPCs and management took over the concept and turned it into strict excel-driven-development.
But yeah, one problem is that people think the alternative to Scrum (the modern way, a strict, fixed-development, top-down-driven cycle) is Waterfall (a strict, fixed-development, topdown-driven cycle). Not the loose thing we nowadays usually call UP in hindsight that was quite pervasive at the time.
kenfar@reddit
I've found that no process survives toxic culture or incompetent management. But when the leadership is decent then scrum can be great, and really protects the team. What I like to do (besides all the standard stuff like sizing stories together, retros, etc):
I find that it's great to have 2 week goals for the whole team to push towards as well as some protection from getting whipped around by constantly changing priorities.
Cheraldenine@reddit
When you say you like to do this, what is your role? Is this how you do it as product owner, as scrum master, as team member?
kenfar@reddit
On two projects I was the team manager. On another one I was a team member.
None of these teams had a scrum master, and only two had product owners.
Cheraldenine@reddit
So Scrum can be great when it's not actually Scrum, but your own process that takes some elements from Scrum. Which is great, of course, but not Scrum.
kenfar@reddit
It's still scrum. There's nothing in scrum that requires a dedicated scrum master, or requires one to slave over burndown reports, etc.
aueioaue@reddit
Except there is... "The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. ... The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide."
MillerHighLife21@reddit
The reason at its core is a desire for predictability while building the entirely system around a estimating framework that cannot work. Ever.
https://www.brightball.com/articles/story-points-are-pointless-measure-queues
jrhorn424@reddit
Came for the clickbait post, and stayed for the excellent long-form article in the comments. Thank you.
kemiller@reddit
Ironic because keeping management off the team’s backs is the whole point of scrum.
No-Manufacturer-3315@reddit
I openly say it in my company, it’s not agile it’s scrumfall
HoratioWobble@reddit
Well it's used as training wheels for agile where a company was previously waterfall.
Scrum is agile for managers and surprisingly through weaponised incompetence they often miss the point and encourage turn it in to waterfall with extra steps
El_Diablo_Feo@reddit
I found too many people get too dogmatic around the scrum lifecycle and the ceremonies to the point of being overly rigid. Scrum to me is guidelines, something to use with flexibility in mind for how the team, the org, and the stakeholders operate. Be too rigid and it breaks, be too flexible and you don't see the benefits.
LessonStudio@reddit
Years ago I had an interview with a company where the head of development was also the head of a local Agile group. He was a hardassed my-agile-way-or-the-highway guy. Didn't take the job because of this.
I told the person who had asked me to interview that the company was going to die because of him. This was a company which required continuous creativity. The software was fairly easy to implement, once someone very creative came up with what needed to be implemented. It was also a very competitive business, so continuous cool features were going to be key.
My statement was clear, this guy would drive away anyone with any actual talent. Drones would maybe like it, but nobody with any self-worth would put up with his BS for one second.
Years later I bumped into one of the founders at a tech event. I asked, "Did you ever fire that Agile D-bag?" in a company with over 100 people he didn't even have to think about it for one second and said, "Way too late, the damage was already done."
The company was bought out a while back for not much money. I would throw out a guess that they could have sold it when I interviewed for 10x as much.
El_Diablo_Feo@reddit
Yikes .... The ultimate tale of failure due to bad agile practices. I don't understand how management lets that happen. I worked at a Fortune 50 company that put some brown nosing engineer into the head position for the division's agile practice. My team had been through the evolution of scrum ban, agile scrum, and then SAFe agile as we grew and our role became more central to the division. My boss told me to offer my expertise and help out the new agile division head. The new agile head sort of brushed me off and was VERY dogmatic in his approach, following the agile method to a T despite me telling him I learned that flexibility is key to its successful implementation. One quarter later I was hearing how engineers and stakeholders were at the point of skipping meetings or ceremonies because it had gotten ridiculous, tedious, and not very useful. I had zero interest in being part of that org because I enjoyed my little island in the sun (division's/CIO's cloud data lake and big data reporting infrastructure), but had they appointed someone with actual experience I think things would have run smoother. The agile head was under tremendous pressure and was definitely not delivering due too much rigidity, ego, and a complete lack of awareness. It was crazy to see such a fuck up at a company like that. But hey, even Apple had weird quirks like not analyzing loss prevention data for YEARS and wondering why a single global policy for losses doesn't work 🤷♂️🤡🤦♂️
LessonStudio@reddit
Dogmatic.
That is a problem far past agile to a huge amount of software and hardware development.
Often, their dogmatic approach is defended by weird edge cases which, to an outsider, seem reasonable responses to said edge cases. The reality is that, well, reality says that is stupid. The edge cases are often so rare that they can manually be handled, or are a sign of something else wrong.
Often, I find that agile is designed for crappy programmers. There are two possible solutions:
Fearless_Imagination@reddit
I seem to have a very different interpretation of at least how Scrum is supposed to work than the author of the article. Although, sadly my experience with Scrum in practice isn't all that different.
Here's a few things where I think I have a difference of opinion with the author on what "correct" Scrum looks like:
Sprints are not supposed to be deadlines at all. You don't finish everything you planned in the sprint? -> Okay, that happens, what can we learn from this so we can plan better in the future?
Especially when you're just starting on a project and you have no idea about how your team works together, your initial estimates for how much you can get done in a sprint are going to be completely off base. This should be expected, and a team should get more accurate in their planning what they can achieve in a sprint over time.
The duration of a sprint is prescribed. And there are a few meetings that are prescribed: the review, the retro, the planning for the next sprint, and the dailies. If you are not completely incompetent at timeboxing (which, I have learned, a surprising amount of people are. Does nobody know how clocks work anymore?) those really don't take up that much time. Need more meetings in a sprint? Plan more meetings then (and as much as we all hate meetings, in larger organizations you probably do actually need more than those, to align work with different teams and such).
Need to adjust your tasks during a sprint? Talking about that is literally what the daily is supposed to be for, so I don't get how you can think those are prescribed?
Roles of participants? Scrum actually (unrealistically, in my opinion) expects all Developers (which, remember, in Scrum is everyone in the Scrum team except the Product Owner and Scrum Master) to be able to pick up any kind of work. If development is done but QA turned out to be more work, devs are expected to help QA out. So I don't think that's really prescribed either.
Look I get the point and I don't disagree but you probably shouldn't use a study done on mice to make claims about human psychology. Mice eat their own babies sometimes.
That isn't Scrum's fault, it's yours. It is your job to set aside enough time for proper engineering prep work. Yes, that means you need to do at least some thinking up-front, and incorporate it into your estimates. And also plan to have the time to do the required up-front thinking. This isn't a Scrum failure, this a failure of the developers to plan appropriately. Learn from it and plan more time for these kinds of activities in your next sprint.
Honestly, this is pretty accurate. It's a shame, because competently implemented Scrum is a really nice way to work. But almost nobody implements Scrum competently.
elperroborrachotoo@reddit
Yeah, if you don't want scrum to work, it won't work.
You do need permeable hierarchies; if PO and devs consider each other on opposite sides of the table, you can as well go back to crunch mode and whippings.
Besides, flip the mouse please.
Carighan@reddit
It's funny that just like every flawed scrum-discussion, this article uses "Waterfall" as the contrasting point.
Which is funny insofar that:
*: Unless it was done badly.
**: Which is why it's so bad.
Scrum works really well if you do agile development. Nobody does, so nobody can use scrum well.
chengannur@reddit
My take on that is, scrum is not going to work if you add someone to manage project in it, it's only going to work in an all dev/qa team where they manage internally, the moment higher management is involved, that framework is not going to work.
LessonStudio@reddit
There will always be failed programmers who are politically connected and will "rise" to become managers. The only way this works is when a company's culture fires bad programmers.
griffonrl@reddit
Scrum is BS. It has always been about selling snake oils and create a business out of consulting. When you realise that most scrum people have no clue how to write software or build anything really, you can't take them seriously. They just apply a set of rules without having a clue.
RufusAcrospin@reddit
Exactly!
tazebot@reddit
Reading the 'agile manifesto' and the agile 'principles' it's clear what they are all about: faster faster faster; with lip service to quality and documentation. There's a reason they are called 'sprints' and not 'crawls' and 'velocity' not 'thoroughness'.
noutopasokon@reddit
It’s not, actually.
kenfar@reddit
Same. You know what stresses me out?
Dankbeast-Paarl@reddit
It's stressing me out :'(
macgruff@reddit
I simply ignore our so-called “ScrumMaster”
princeps_harenae@reddit
Scrum is relabelled micromanagement.
It exists purely through misunderstanding software development which in turn breeds a lack of trust. Hence, why in a stand-up every day you'll explain what you did yesterday and what you'll be doing today, lol.
DualActiveBridgeLLC@reddit
The point of the standup is to see if people are blocked and appoint people to help if they are. If all you are doing is a status report then why bother with the standup since you can do status reports in other meetings.
alerighi@reddit
If I'm blocked on something I just go to my coworker desk, or make a phone call if I'm not at the office, if it's urgent, or if I can wait I just send him a message on Teams.
In my experience standups always end up in managers asking for status report, and discussing on why we are late on X, often going into the technical details of the thing, making people not really interested in that particular issue (because they are maybe working on another project at the moment) waste their time.
DualActiveBridgeLLC@reddit
You just interrupted someone else. Also some people do not have the same inclination and need help when deciding to be unblocked.
Then tell them in the 1:1 not to do that.
alerighi@reddit
Of curse, you learn when to interrupt and when it's not appropriate. It's part of our profession, in the end. I tend to accumulate my questions for moments like lunch or coffee breaks, for example. Of course there is always the case of the urgency that you need to resolve (e.g. bug in production). I tend to get as many information about something upfront, so that I can take my decision without bothering other persons, and to have a batch of work sufficient enough to be able to work for a few days without indication (well, now that I think about it, I can work for weeks probably). But to me this has anything to do with scrum, it's the norm, even in jobs not related to programming at all.
Well, I do, sometimes. But, you still are talking to who pays your paycheck at the end of the month (at least in my situation, where the manager is also the owner of the company!). So in the end... you are payed to do your job, I do it professionally, but in the end I do it by the indication of the company, even if I don't agree with them.
bwainfweeze@reddit
That would mean you're wasting on average half a day being blocked on something. And then asking for help after you've had your entire evening to remove all of the context from your skull. When you are least likely to be able to help the other person help you.
luckymethod@reddit
No it really isn't, it was designed to protect contracting development teams from constant change and having to fight for budget overruns. It got used in countless teams that were a bad for for the process and that's the real problem with it, got sold as the silver bullet for everything because the people that invented it gotta eat.
bwainfweeze@reddit
Every form of agile except Scrum accomplishes this. Scrum extracts a heavier toll for that than any other Agile or Lean process I've encountered.
gigilu2020@reddit
I got laid off recently and after the initial shock ebbed, I am relieved. The constant sprint velocity BS had worn me out. When there were not enough tasks they had me working on stuff outside my wheelhouse and started dinging me for lower velocity. After a point, it felt like no matter what I did, I was always falling short.
I am curious with all the AI driven coding that's happening now, where will regular devs exist in that domain soon.
BanAvoidanceIsACrime@reddit
It's always managers.
It doesn't matter what structure you use. Nothing can protect you from trash management.
PathOfTheAncients@reddit
Forcing teams without any actual autonomy to do scrum or agile is such a team morale killer. It's cruel to make people pretend they have something that they value a lot but don't actually have. It's like forcing starving people to pretend to prepare and eat a meal everyday.
LiquidLight_@reddit
This is where I'm at. My team has very specific feedback come out of every retro and every time any of it gets raised to management types, it goes in one ear and out the other. I'm just about done bothering trying to make anything better for anyone but myself.
bwainfweeze@reddit
Expecting them to be grateful for gruel.
n3phtys@reddit
Scrum is bad because it's a fixed framework that is designed to make output per sprint measurable and standardized.
It makes bad developers output a moderate amount and great developers output a moderate amount.
This is also the reason why it's bad. It's also why some people consider it good. It just depends on what you value more.
bwainfweeze@reddit
It can't even do its primary goal because each backlog grooming we redefine what 'medium' means based on our experiences over the last few sprints.
We are plotting time on the X and Y axis and it's aaaaallll bullshit.
weggles@reddit
A previous manager told me my team can organize however we like so long as it's scrum with 2 week sprints.
He wasn't joking either, he thought he was providing helpful guidance and didn't realize he was a complete jackass.
bwainfweeze@reddit
Continuous delivery can help dovetail an actual agile project structure to a tempo that management expects. Sometimes they get the build from Friday, sometimes they get one from Thursday or Wednesday. Here is what was done in this version, aka 'the last two weeks'
Zynque@reddit
I've worked on teams under variants of Scrum, Lean, and Kanban that were joyful and stress free. The choice of process sets a rhythm of work that certain people may find stressful, while others find relaxing. The far more impactful source of stress is the attitude of your team members, particularly those of your manager, lead, and/or product/program manager. Great management will protect a team from an excessive sense of urgency, enabling the team to build with quality in a principled, professional way - which ends up being faster in the long run, often by orders of magnitude. Poor management will unnecessarily inflate urgency, resulting in a stressed out team that is far more likely to take shortcuts, compromise their design principles, and make more mistakes.
Best_Lavishness_9785@reddit
I can buy that. Then it seems like great management is very rare. 1 good manager can make life a whole lot easier, which I am fortunate to have one, but even thats not enough since 1 manager can't do it alone and they dont have all the power
Anonymous_user_2022@reddit
Back in the early 2000's when y company sent me off to train as a scrum master, that was known as Scrumbut(t). As in "We do Scrum, but ..."
Chisignal@reddit
The chart of the "combined" Scrum and Waterfall is so true haha. You get both the stress peaks around release time, but the baseline is just a continuous never-ending sprint (which is a bit of an oxymoron in itself, isn't it). Of course it doesn't have to be that way, but I certainly recall jobs where it was.
AluminiumSandworm@reddit
it's hierarchy. it's always hierarchy. if there's a system where some group of people has the power or authority to tell other people what to do, even the most perfect system will become useless.
Apart_Technology_841@reddit
Sprints never stop is an incorrect statement. The hardening sprint can be slipped in the planning anytime, giving the team a breather from the mundane repititiousness. Also, the retrospective allows extra room for improvements, so if the team decides to dedicate the next cycle to spikes, training, self-study, then that is also allowed. The team is empowered to achieve goals in any way it deems as necessary.
throwawaymo11812@reddit
I think a big part of the stress comes from how Scrum is implemented. It's supposed to be a framework for helping teams adapt and improve, but too often it gets treated like a rigid process with no flexibility. When leadership focuses more on the ceremonies than the outcomes, that’s where the stress kicks in.
valkon_gr@reddit
Scrum sucks.
zoddrick@reddit
ITT - People who think the only Agile Methodology is Scrum...
avemg@reddit
I've been a member of this subreddit since it before subreddits even existed and this was just a separate reddit instance alongside joel.reddit.com. So I say this as a person who has been around and knows that this place was never limited to posts precisely about programming topics, but about the software industry in general.
So this is not a "this is not programming" complaint.
With that out of the way: Enough fucking posts about scrum/agile whatever the fuck. If the mods wanted to fucking ban these things I'd be all for it. The discussions are all the same. There is nothing new to say. Yes, I should just downvote and move on. And I do and have for years and years now. But this morning it's got my blood up so I'm going to rant.
wineblood@reddit
Scrum is fine, though I have no idea what process this blog post is describing.
quests@reddit
I just don't want to live with an anxiety disorder for the rest of my life.
-ghostinthemachine-@reddit
Developers seem to think these tools are designed to make them more efficient. VPs only care about efficiency so much. Instead they are primarily for making teams predictable. We are always juggling flexibility with predictability. Scrum isn't a good way to develop quality software, or a quality team, but to the people who force it upon you, that's acceptable.
hippydipster@reddit
If they could just prevent the team from making any progress, it'd become very predictable. Success!
MisterHekks@reddit
If the author actually believes this then he hasn't really been part of a substantial software project run in an actual waterfall fashion. Scrum / Agile is not the best method but its the best we have developed so far.
joe-knows-nothing@reddit
Nothing like a huge deadline several quarters out for an absolute massive amount of requirements to get the blood pumping! BRUP BRUP BRUP!
IHaveRedditAlready_@reddit
Why Scrum ~is~ may possibly Stress You Out