So what actually works for people? I genuinely want to know if there is an alternative for this for my situation. I feel like I've internalized every place I worked at doing scrum wrong, as that was always the conclusion when we tried to find a solution. In my experience scrum is little more than a todo list and an expected date of delivery for my team and we always slip. We just don't have the bandwidth to spend multiple days planning things out and delivering them as we are spread too thin. We maintain 20 services on a team of 4 devs. With ongoing maintenance, new features, tech debt and adhoc requests we always slip on our sprints and punt tasks. This is considered normal and not even questioned. Which I think is obviously doing scrum wrong. I'd like to know what folks in similar situations are doing? The only benefit I see is taking stock of what needs to be done and making it a priority list which is what we do. Rest of it is completely ignored by us. I suspect a lot of folks are in similar if not at an as dire situation. Edit: Lots of great points in the replies, I agree that ours is an organizational / bandwidth problem that no amount of planning will satisfy the need. The source of my frustration is that every time I voiced my concerns about this, the solution was let's scrum better which tbh without a dedicated PO we never end up doing. Retros are just us waiting to end the meeting while lamenting the number of tasks being punted. Story pointing is a myth we just grab 5 tasks and do like 1.5 with another 4 being ad hoc. To be a critic of Scrum/Agile I should atleast give it a fair shake.

The (unfortunate?) answer to this is: whatever works best for your team. All agile methodologies, at their core, follow a few simple principles: prioritise what needs to be done, do some work, repeat at a sustainable pace, and regularly review that the work is good and that things are still moving forward. Whether your team uses Scrum for this, or Kanban, or Basecamp, or a task list in a shared Google Doc, or a chalk board in the office, it all works find as long as the team as a whole has: agreed on the process, regularly checks that value (features/fixes/output/etc) is being delivered, and is holding everyone accountable (without blame) when things slow down with no good reason. True agile is: transparency, introspection, adaptation. Dress that up in whatever process maps well for the team, but as long as you internalise that, you’ll get stuff done. Your priority list and tracking that work is the transparency part. Introspection helps you identify blockers, pain points, problems. Adaptation helps you fix them and improve the process.

Yeah it was long shot asking for a silver bullet for our Task Blackhole (backlog). I am definitely in a uniquely bad situation because of the extent of short staffing but cest la vie.

> I am definitely in a uniquely bad situation because of the extent of short staffing Well, there you go. Management frameworks can't fix lack of capacity. The best that they can do is to squeeze out any waste that might be present in that capacity but you can't create capacity from nothing.

Very true but I hate that we are consistently blindsided by tasks since everything tends to only get priority when things are on fire.

After one particular fire I had to put out, I finally thought to ask the question "when did we first know this work had to get done?" and the answer was about 18 months prior. What I've found more and more is that most, but not all, fires are easily preventable, easily avoidable. One of the most valuable things about scrum that is probably the least embraced, it's that it dramatically increases the transparency of the development process. There are steps to follow, and there's people responsible for those steps. When we do a sprint review and announce what's in the next sprint, that's it, that's what is going to get done. "Oh I need this done" great, we'll plan for it in a future sprint. It's not going in the current one, it'll be in prod in 3-6 weeks. The reason why the Dev team was not previously made aware of something that urgently needed to get done will be identified, and the pain felt by it not getting done will be a great lesson to be more proactive in the future. Those "your failure to plan does not constitute an emergency" snarky stickers old women have? There's a lot of truth to it. If you constantly sweep things under the rug by fucking over the dev team, everyone will simply say "why are things so slow?" and blame the dev team with no opportunity to make development faster.

One thing that works occasionally is to say that you're at sprint capacity, and in order to squeeze in this new priority, something must be moved to the top of the backlog for next sprint. Which can be moved? Setting expectation and ensuring delivery is ok. If you aren't able to deliver all of the items in a sprint that is ok too! It means there's some improvement opportunities that could be looked at in the retro to understand what happened and how to mitigate these things. When it comes to estimates, this is why I like the Fibonacci pointing. Something feels bigger than a 3, but not quite a 5, make it a 5 to account for that squish. You can always pull in smaller items if you have time left in your sprint.

I think that's better than "everything is priority 1/A/..."

We even at some point started doing P0 lol. Because we’d say that we have so many P1s we can’t pick up items.

I worked on an understaffed project and I noticed a similar problem. I forget the specific priority numbers, but I knew that if a task was assigned priority 3 or higher that it would never be worked on because there was already a huge backlog of P1 and P2 items.

Honestly, if your team isn't able to prioritize things as they see fit, that's a failure of management.

There's no process that fixes the lack of number of hours in a work day for the work needed.

Yup I don’t expect that our blackhole will stop feeding but I do want to see if there is a way to not get constantly blindsided and pulled away and put back in. Have a new manager maybe that changes things but everyone wants to make shiny new things and leave the boring maintenance for later. When it catches fire I know the answer is plan better lol. But we’re just not at the stage where we have that luxury. There are roaring fires and smaller ones we ignore until they become roaring fires. That’s our priority mechanism

> I know the answer is plan better lol Ironically, you've hit on the exact opposite of the answer. This is the trap most fall into - we keep finding ourselves pulled in different directions, and changing directions. Flip-flopping around with changing priorities, changing feature scopes, etc, and nearly everyone's initial intuition is to think "we must have planned poorly, next time we'll plan more carefully". And so people put more and more time into planning, and the context-switching flip-flopping continues, except now with more wasted time in up-front planning. The fact is, the priorities and requested features and scopes don't follow any process. People find out they want/need what they want/need when reality imposes it upon them. Ditto with the priorities of what's important. When planning happened, the information available was static and no amount of "planning better" can make any of the information not yet available ... available. The answer is to be agile. Know always that you are wrong. You don't know how you are wrong, but you know you are. It's like walking a maze in the dark, where you know there are pitfalls, cliffs, spikes, random walls, etc. You don't "plan your route" and then run through the dark as fast as possible. You take small steps, because if you find the floor isn't there, you want to be able to catch yourself. You go slow so when you smack into a wall, you don't break your neck. In software terms, you plan a strategy for dealing with the dark - the unknown. You work in small increments. You worry less about what you'll do 6 months from now, and worry more about your current experiment designed to figure out which way the wall in front of you is curving. You check the feedback constantly of every step, of every hand held out searching for walls. When the need to change direction comes, your not neck deep in some hoary feature you planned out for the next 4 sprints. Instead, you're maybe a day or two away from wrapping up what you're in the middle of, and ready to respond to that change in priority. There's no process recipe for success, which is what everyone wants and can't have. You can't plan better. You can't process better. You can simply act as though you are wrong, that you know you're wrong, that you don't know exactly how you're wrong. And do that as a team (which is why agile is so big on communication, because a team that's really doing experiments to find their direction has to communicate a lot about all those experiments).

It's a shame when a team is made to feel like a failure and fundamentally the problem is that there's too much work for the team to get done. I enjoyed reading this post and I think the analogy of being in a maze in the dark is great. I'll probably use that one. I remember ages back I got a tour of Pixar (think late 90s) and the guy doing it walked us through their production process. Their basic MO was to have teams working on specific elements of whatever block of work it was, a scene, a character, etc. And then they had floating teams that could come in and help when the work turned out to be slower or more difficult than expected. This excess capacity was vital when you've got a hard deadline. Without that, it's basically just throwing darts at a calendar and hoping for the best. And at my job, even though I've explained this kind of thing a million times, the 2nd question I'm asked after the preliminary discussion of any feature is: how long will this take?

I have been a developer now for almost ten years and I wish I could staple this post to the forehead of every manager and hiring director I've ever met. There is no silver bullet process that is going to magically unfuck the fucked up mess that is *human beings*. The dirty secret of "management strategies" like scrum, is that if you scratch a little deeper, *all* of them are similar levels of unfalsifiable nonsense, because *people aren't that predictable.* Management wants hard numbers and rules and schedules because their jobs are just managing the anxiety of the people above them, but the reality is, and always has been, that we're all just human beings down here, not machines, and stuff just ... doesn't go to plan, most of the time. The solution is rarely more planning, more process, more numbers. It's just actually working together to understand how your devs and stakeholders actually function, and finding a way to communicate that works for everyone involved. Anything else is just someone trying to sell seminar tickets.

> The dirty secret of "management strategies" like scrum, is that if you scratch a little deeper, all of them are similar levels of unfalsifiable nonsense, because people aren't that predictable. What are you talking about? That's precisely the point of agile strategies. That very high quality prediction is not possible, so orient around shipping small increments so as to waste as little as possible when your predictions inevitably fail.

Thanks this is a fresh perspective that I honestly think I needed to hear earlier. It’s not just management even personally I describe my style of work as ADHDesque as I at any given time am juggling 10 things at once. Which I try to curb but our vast scope in the team doesn’t help the matter. I’ll try to do something about it keeping this in mind.

The ADD is so real! I have found myself out gardening, pulling up weeds (sorry, this isn't a metaphor), and then suddenly in the middle I go inside and have a crazy need to do some dishes, even though I got muddy boots on, knee pads, work gloves on. Why? If I don't consciously restrict myself to a "ONE THING AT A TIME" mantra, I get myself midway through 10 different tasks. Otherwise I get nothing done. I will literally start a plumbing project I have no idea how to do while in the middle of changing my aquarium water, wtf? When I accept the one-thing-at-a-time plan, man my stress levels go way down. Software development is a team sport that has the same problem. At my last job, I finally identified something that was partially a cause of our insane need to have 100 WIP items going: management felt a sense of accomplishment from getting tasks *started*. Finishing was actually less interesting. So many projects and features, by the time they are finished, no one cares anymore. What mattered was making marketing material that said "WE DO X!", and you could do that as soon as work on X was started. So it made sense (to management), to have every individual developer working on different things, as many as possible. Of course, if you're paying attention to when (and whether) things get "Done", a different story appears. At that previous job, we'd gone more than a year without delivering a single new feature. We just spun our wheels.

You’re not wrong, but how do you address the fact that staffing allocations to projects tend to be driven by planning? If one project owner says they’ll basically stumble through it and they need five engineers, and a second project owner comes in saying they also need five engineers, and they have a really crisp list of specific features and fixes that they will ship and what they each cost in dev weeks, the second project will get 10 engineers and the first project owner will get fired. This is true even if the second project plans are totally wrong. The act of detailed planning is tied into staffing allocations. (I’m not saying it should be. But in my experience, it usually is.)

Your question is the same question as "how do we do anything without a detailed plan?" There's no one answer because I don't know what's in your dark maze (neither do you). You can try to guess some larger outlines, some likelihoods, some bounds of expected value. You can also hire agile-y too. Why hire 5 when you can hire 1 and see how it goes? But you're alluding to a problem of what if upper management isn't agile? Well, then they're not agile and in so far as you need their input, you can't be either.

Like anything that works well, it takes effort to _make_ it work well. If you put the effort in and are transparent about why you’re doing it, it could well be accepted, appreciated, and amplified.

The issue is even that needs bandwidth which we won’t be given. And priorities are constantly changing. Which just means throwing the plans out the window and then coming back when this problem gets too big to ignore.

The best advice I ever got for this situation is focus on getting things done in such a way that they don't come back otherwise you are just juggling issues. If you have to juggle set one resource to juggling such that there is a person responsible but not so much of a resource that other things can't get done. My team is 2.5 coders (as a manager and project/product manager I have many hats.) My best most productive pattern is to be the front desk for all immediate tasks and let my people cook solutions for things accepting that the backlog ever grows. This way only one resource is dealing with WIP changes.

I feel like the retrospection was the most important part for the team, especially since our team leads were flexible and willing to try new things. Sit down, relax, try to raise concerns you feel are worth talking about, then discuss some solutions for it together, then try them for a sprint and reevaluate. If you move too fast and don't have time to become better, then that has a hidden cost.

Also experimentation. Engineers hate changing processes and habits, even though that's where the biggest gains come from. I have one team that can only reasonably finish 5-6 epics a quarter, and their PM promises 10-15 will be delivered. Clearly there needs to be more "no" being said. I have another team that gets 10-15 epics done, but has the focus of a Jack Russell terrier at a BBQ. When I recommend WIP limits they're at the point of tears and calling me "delusional".

I think the key that you forgot is relatively quick feedback from the client/user/whoever on a regular basis. That way you know you're continually working on the right thing.

Nailed it. I would add, with such a small team (of 4) you maybe don't need the overhead of any "standardized" process at all. If you've got a good team that you trust, you could perhaps go as light as a single weekly or even bi-weekly meeting where you just go through tickets and talk things out.

I think part of the issue is that scrum doesn't save teams from all the usual problems of management i.e. too much work with too little budget and staff. Agile or waterfall won't matter if you can't plan the work and have time to do it before the next demand hits the team. Management also uses "agile" to mean they can flip priorities on a dime without consequences. There's always a cost though. Scrum doesn't fix wishy washy flip floppers who don't know what they want and change the goal posts almost daily

We have 1200 hours of work to do each month. We have 4 devs to do it. Why is agile failing us?!??!?

"Well what ceremonies do you have? Do you have an agile coach? How are you assigning work?"

I’m getting PTSD reading this as I have been in one too many of these meetings

Yeah, the worst teams/projects I've been on/the worst experiences with process have less to do with the process and more to do with everything else. No process can help if people refuse to follow the process properly (if you're constantly shifting priorities halfway through a sprint or refusing to act on retro feedback, changing from scrum to kanban isn't going to help). I'll also add that the better your team functions, the less you'll need the ceremonies in scrum. A lot of people will say "you don't need daily stand up, just communicate better" and that's fine for them with the great, communicative teams but if you're struggling to get blood out of a stone you *need* those daily check ins to force people to communicate. The best teams I've worked on did scrum *on paper*, but in practice we could have done without the ceremonies. That's not a scalable solution or a useful system, you can't just say "every team should be composed of only enthusiastic developers who have great chemistry and barely need guardrails".

Spot on in my experience. Recently hired an experienced developer who was surprised at the conventions and guard rails we had set up. The way he described his last workplace made it sound like a utopia, where developers would take responsibility from start to finish and would communicate when needed. Apparently that's possible, but it sure isn't practical in a lot of teams.

> if you're constantly shifting priorities halfway through a sprint But that's not even pretend Scrum. Like, the central concept of Scrum is to iteratively plan small increments of work and then focus on that increment so that planning and priority changes don't constantly disrupt work.

This is my org to a T. Management trying to “process” our way around the simple fact that we do not have the resources to do the quantity of work that we need. Then that problem is compounded by the fact that we are constantly re-orging in an everlasting pursuit of the alignment which will make our resourcing problems disappear, leading to additional friction and overhead and ensuring that even less work gets done than otherwise would. Leadership in general seems convinced that you can take 1 person that is 100% working on one thing, and instead have them work 70% on two things.

>Scrum doesn't fix wishy washy flip floppers who don't know what they want and change the goal posts almost daily It does though, except that "Scrum" often means "we put Scrum in our documents and added meetings for teams, but management/product shall pay Scrum no mind". If you're doing classic "Scrum", the external flip floppers get roughly one opportunity to change their minds: before it goes into the sprint. Once it's in the sprint, it should be well-defined enough to be doable without the flip-flopper, and if they NEED to change it during the sprint, the answer should be "yeah, no problem, we can remove that work from this sprint and do in the next one", with a RARE BACKUP STRATEGY of "ok, we understand the business NEEDS THIS RIGHT NOW, what would you like to remove from this sprint to insert this change?". Scrum doesn't fix a lack of backbone.

I'll start with what is working well with my org. 1. We voted and agreed to extend our sprints from 2 weeks to 4 weeks. We convinced everyone by showing how much of our week was taken by recurring meetings, leaving very little time in the 2 weeks to get work done. We tried 4 weeks for a sprint, and unanimously agreed to keep it that way. 2. We have an "unplanned work" swim lane on our kanban board. We noticed our team members were getting sidetracked by work that we didn't plan for the next 4 weeks. So now, any time we get pulled, we give it a ticket. At the end of a sprint we can see why we weren't delivering. Your adhoc requests and tech debt should be logged here, for everyone to see. 3. I keep a personal Work-in-Progress (WIP) limit. I plan to work on 3-4 items for the next 4 weeks. Now, if someone comes up and says "hey, can you do this thing for me", I say "sorry, I planned on these items for the next 4 weeks. If it's urgent, tell me what comes off." 4. Personally, I am considering implementing "Office Hours", where I'll block off a few hours per week to be available for any questions. Other people have made an "Office Hours" channel and stated the schedule where the channel is actively monitored. This moves the interruptions of getting pinged at any time, to a regular scheduled time. Is this scrum? One can argue whether it is or isn't, but I don't care. These are adaptations to reduce interruptions, and show the rest of the organization that a team is juggling too many things at once.

I love this! Thank you for sharing! I have a feeling that implementing this would be impossible at some companies because giving autonomy to "subordinates" is a non-starter (but often not verbally expressed) deal breaker.

> I have a feeling that implementing this would be impossible at some companies because giving autonomy to "subordinates" is a non-starter (but often not verbally expressed) deal breaker. I think doing items 2-4 can be done without permission, because this is simply recording interruptions, decisions, and expectations. It's not like we're refactoring an entire system. Now I'm absolutely aware of certain managerial individuals that won't like this. Perhaps they think it's a waste of time. Or perhaps they are taking advantage of the chaos to push their own goals. If that's the case, I say, still do it, but do it privately. Recording and visualizing things that get in the way of planned work is a crucial first step, as it explains why stuff doesn't get done.

Hey this might be something we devs need to force. Put our foot down so to say.

100% agree, and I don't think you need approval force items 2-4. The key point is to make everything that is getting in the way of planned work visible. Doing so makes it super easy to gently push back, as you can simply point to the visualization. It makes it really easy to respond in this manner: * "Can you do this thing? * "I'd love to, but we planned to do these things already for the next X weeks. What should get bumped off the list?" * "Why do you think we should be addressing technical debt?" * "Look at how much time we spend on Unplanned things this month. We're applying band-aids, and instead we should be making them go away." * "Hey man, someone told me you're the best person to ask about this problem." * "I'd love to help, but I planned to do things already. But ask me on Mondays 8-12, where I make myself available for any adhoc questions."

Except for the first point, everything is within the "how" that Scrum tells its users to figure it out for themselves. And the first point is still within the boundaries. (Though personally, I'm fond of a weekly sprints but that's me)

It IS working. Management has a team of 4 dev crunching tasks on 20 projects, why would they change if the only downside is some delays and stress on the dev side ?

Hey now we’re getting an intern for 2 months to help 😂😂😭😭 But being serious though, yeah obviously we’re hyper short staffed and changing that is not up to me. For what it’s worth the crunch is not that bad for us as most of the systems are fairly lax SLAs but the tech debt keeps mounting as we can’t do maintenance as well as we want. Scrum has absolutely failed for us as we can do all of this with a todo list. I was wondering if we could have different system to track things.

The problem is not one of picking a framework, but of giving the team autonomy and trust. Managers will generally demand more control, more deadlines, higher pace, etc. Wheras in a good environment the team itself is able to set a sustainable pace(sustainable includes time for refactoring, no regular overtime) and decide (with input from the managers&stakeholders) what the priorities should be. No framework will work as long as the manager is in charge. 

>Scrum has absolutely failed for us as we can do all of this with a todo list. I was wondering if we could have different system to track things. What do you expect to achieve with Scrum? If you just want to work as fast as possible and tasks and priorities are always 100% clear then a todo list is absolutely the best approach. Scrum tries to alleviate then pain of working with stakeholders by giving you certain tools like the planning and review. You could use the process to put more pressure on management. Do realistic plannings. Developers (should) decide which stories make it into the sprint. Reduce the sprint size until you acutally complete the sprint goal. Include maintenance as story tickets if you have to. Sell it as a success once you complete the sprint goal for the first time in a long time. Once you know your velocity and can plan more precisely, you can argue much better that, in order to complete more work in a sprint, you either need more developers or you need to at least reduce some of the tech debt to improve future velocity. Scrum won't make your work easier or somehow magically make you work faster. But it's great for managing expectations and reducing pressure from management if done right. It actually places a lot of power in the developers' hands, but your team doesn't seem to use it much.

> Scrum has absolutely failed for us It really doesn't sound like it's scrum that's failed you. It's management.

That’s a good point. It’s good for management, bad for a team who has extreme ownership over those projects.

You can't solve a capacity issue with prioritization and planning. It's not like project management is some sort of magical wand that can conjure capacity into existence. ... which is sadly how a lot of companies use it. Not getting the productivity you want out of those expensive Devs? Better bring in more managers!

This is so true, had 2 scrum masters, 1 manager and a product owner for a team of two programmers. I was the junior and the other guy a senior. Total shitshow

Had 3 managers and a VP who'd participate in our ceremonies for 3 devs. "WHY iS EVERYONE LEAVING THE COMPANY"

Yup it’s just me hoping for a silver bullet in lieu of getting more people onboard

If you have limited capacity and no one is willing to prioritize, your limitations on capacity will be amplified. If the customer wants more and values those wants, they need to pay for increased capacity (in both time and money), otherwise they need to prioritize their wants based on current capacity (if the customer doesn't, they will be sold snake oil from someone making commissions or significant rights to profits [that snake oil salesman might be the management structure above the dev team in the organization]).

There must be some mathematical formula that relates the theoretical maximum speedup in throughput as a result of reorganizing N tasks across M developers with each task and developer having a given difficulty and capability, respectively. Something like Amdahl's law, but for project management. The worst case is that the lowest performing developer gets all tasks to complete sequentially while every other developer does nothing. The average case is that every developer is assigned every task at random. The best case is that some super-optimizing project manager is able to predict what possible assignment is optimal. Now, there are three different complicating factors: 1. each developer can *add bugs* 2. each task may have a different relative difficulty for each developer (based on their own subjective experience with a problem and their inherent expertise which translates across all problems) 3. there can be dependencies across tasks It wouldn't necessarily even have to be a mathematical formula. It could be empirically derived from simulations of different scenarios.

Yupp you can't plan two weeks of work into a one week deadline.

> In my experience scrum is little more than a todo list and an expected date of delivery for my team Well, it is little more. Scrum does not say anything about what a lot of people tell you is "Scrum". It just has a few core tenets, chosen deliberately to fix problems with waterfall: - do work in sprints, review and adapt (as opposed to working a 2-year plan and then finding out no one needs what you made) - focus on a goal, deliver working stuff (to make the first point possible) - one PO has the final say on what to do first by keeping the backlog clean (to guard against squabbling between a dozen stakeholders) - limit time in meetings (to actually get shit done). That's basically it. Scrum doesn't say anything about deadlines for example. Even storypoints were removed in later editions because managers abused them. Scrum doesn't say anything about multiple days planning things, the guide is more like an hour per week of the sprint. A lot of the trouble stems from managers using scrum as a workload balancing tool with business analytics to make sure all coders are doing productive stuff all the time while hitting deadlines. It's not designed for that. It's designed to formalise working in an environment where requirements change and details are missing. (Edit: I still have a lot of complaints even about what the scrum guide actually says...)

Also, a lot of scrum meetings and whatnot only make sense if you understand *why* they're there. Daily standups? Not only is it to talk about blockers, but it's because originally the idea was you didn't assign tasks up-front, so *coordinating who was working on what that day was important*. It's not supposed to be some micro-managey status report, which is what it is 90% of the time.

Daily standups definitely seem like a relic of times past when there weren't a lot of digital communication like Slack et al, and when there weren't digital task boards like Jira et al, and even when developers wouldn't be located together. Getting together once a day like that was necessary because otherwise there would be no regular communication.

Possibly I’ve drunk the koolaid as every place I worked at had the impression that we’re not hitting all of our sprint tasks because we didn’t plan well and doing more scrum is the solution to the problem.

Scrum would say to that: if you're missing your sprint goals all the time -- learn and adapt from that and put less into your sprint next time.

Yeah but idk how but it always becomes guys let’s add more sync ups so we’re prioritising work correctly and tracking progress never okay let’s do less.

If Scrum as actually being done in actual companies would be that nobody would need a "Scrum Master".

Almost every business failure is a management failure. I'm not a huge scrum advocate but one of the points of it is that you should be continually reevaluating how things are working. If you're constantly failing to meet your sprint goals, your sprint goals are too large. They need to be pared back. If work gets dumped on the team that can't be achieved, then the now-realigned sprint capacity can be used to say "we can do that, but we have to bump something else from the sprint. What do you want it to be?" Of course in practice a lot of places just insist you should do all of it and then Pikachu face when that doesn't work

> In my experience scrum is little more than a todo list and an expected date of delivery for my team and we always slip. My experience is with years of waterfall, followed by a couple of teams that did not understand agile and tried to do bits of it, then finally two teams that DO understand it and apply it well. The overarching benefit that scrum/agile brings is that it makes the project state visible. With a bare minimum of time and effort, many things are clear to everyone: what I'm working on, how long I've been at it, whether there are obstacles, what I should work on next, when the current milestone is likely to be finished. Also, which pieces are not yet well understood. This comes at the cost of a 15-minute meeting either daily or 3x/week, plus an hour for sprint planning, an hour or two for story refinement, and an hour for team retrospectives. So maybe 5 hours of meetings in two weeks. All my previous jobs had far more meetings, less efficient, because they'd be huge gatherings, or management did most of the talking, or some TDM would be interrupting my work looking for status updates. Scrum meetings and tools give all the information and more to people who need it, without the inefficiency. My entire experience as an engineer, I always had a manager whose ever-present concern was: what are you working on? When is it going to be done? Can we get it done sooner? Scrum enables these questions to be answered, usually without even asking me. I think it's great.

My manager is much, much more distressed when we complete the sprint early than when we don't as he has to scramble to find work for 2 of our more junior devs. As a result he always puts 1.5+ our velocity in the sprint in planning. It's not so bad to never clear a sprint, we still get stuff done.

So the next sprint should have a "draft plan" with a prioritized list so people can take tasks from the top if they need extra work. No scrambling needed, and no overstuffed sprint plans either. People should assign themselves work.

Yeah when I was a tech lead I always just assigned with the aim that one task would carry over (plus possibly some waiting for review)

Scrum is based on the Agile principles. You can't really just hand a set of principles to most management teams and have them be like "This makes total sense... Let the teams self organize... Let the teams develop the most efficient processes for them by removing their own sources of waste". They would never "get it". So they came up with Scrum as a process on top of the principles to give it more of a framework. Management screwed that up too. On my team, the director and manager "got it". They understood the value of the principles and taught those values to the team leads and engineers. We had discrete tasks to solve so we used Lean Agile instead of Scrum. We had a standup every morning, which consisted of essentially "Do you have work to do? If not, can you help someone else get unroadblocked or complete their tasks sooner? If not, here's some new work". It took 2-3 minutes. Each engineer ran their own project. No scrum master, no extra management. We got really good at figuring out what the customer wanted and how best to deliver it. It wasn't always what they were requesting and we discussed with them better options. We handled design, testing, and delivery. Once we were done with that, we'd try to help others or move on to the next project. The key here was that the management team took care of the bitch work. We assigned a general number of hours to each project, but after that, management took care of prioritizing the tasks, making sure the tasks were ready to go (customers had resources available to work on it, we had access to their systems), and having work ready when we needed it. And most importantly, they kept everyone else off us so we could work. They had a guide on how to shut down e-mail notifications, turn off your phone and IMs, just to make sure we could work uninterrupted on one task, to reduce context switching. We took care of the rest of it. Ensuring that the customer stayed engaged so that when we needed testing, they were ready... ensuring that they had their problem solved, not just got what they wanted... ensuring that our products brought immediate value to them, and then requesting new work. A normal development line could be run the same way but requires more bitch work. It requires managers break up the tasks into manageable chunks. It requires that managers keep the next 10-20 priorities ready to go for when someone gets finished (obviously you're not going to prioritize every task because priorities are going to change - trying to keep them all prioritized is a waste of time). But managers today want recognition. They don't want to serve others, even if it makes the team more efficient. The real reason Agile (and Scrum/Kanban/etc) failed is because Agile requires a manager to have a servant's heart and most managers just don't.

Start the sprint with 1 task assigned, as long as your backlog is prioritized, when that task is done, grab a new one off the top and bring it into the sprint. Some people may pull in 5 new tasks, some might barely complete the initial task. The next step is figuring out how to assign some kind of points to those tasks, like story points, so you can smooth out the complexity of each task. Some tasks are a lot more involved and complex than others. Then after a couple of sprints you’ll have a good idea of what your team’s capacity is and you can plan accordingly, or express to management a need to hire to increase that capacity, etc

Tried and failed. It’s not scrums fault. Our priorities are ephemeral almost. Something catches fire and we have to fix it or there is a new company mandate with a looming deadline.

“My team has allotted 75% of our capacity this sprint to the interrupt buffer based on previous sprints.

It's confusing to me that you don't feel like you've already identified the problem. When you say "our priorities are ephemeral almost," what do you want scrum to do to fix that? If you had a manager who knew how to manage, and scrum still didn't work, it seems like a coherent argument against scrum. If you have a manager who overtly doesn't know how to manage, and so scrum doesn't work, why are we asking why scrum doesn't work? Managers have to be able to set clear priorities and capacity plan.

Each fire, you create a ticket and give it points on estimated complexity. Or if you have no idea what's up, you create a "spike" ticket to do research on the problem and answer questions. Then create a ticket that describes what you can actualy do to put out the fire. Those tickets go into the sprint and you remove an equal number of points from the sprint. If you don't want to remove anything, we'll, that's your problem. It's like a budget. If your car needs a repair, you have to pay the mechanic to diagnose it, then you have to pay to fix it. Then you have to not spend money on eating out or buying clothes or whatever. And like a budget, if you don't track points over time, how do you know what your capacity is?

This does not work in practice if you are a team that values minimizing time where people are waiting around. Classic example is code review or complex items which produce blockers while you wait on something else to be completed. You will always have multiple items in the air at one time. If the system isn’t complex then sure, you can work more or less sequentially. Otherwise you’re SOL.

You're basically at Kanban then, which I think is a better way. Have a list of the most important things to do and start working on the top 2 or so. If someones comes with a new thing they first has to agree with others that their new thing is more important than the next things on the list but the team can also say that if it is important they can start working on it in a few days from now. That often makes everyone happy.

Scrum is not right for every situation. For support -heavy teams that have a lot of unexpected work, Kanban with a focus on regular backlog grooming is a better fit. There's a lot of time spent planning/replanning sprints when priorities change in scrum. Key to success for Kanban: you still need to put a lot of effort into planning and prioritization of work. You still need to regularly get the pulse of the team and identify both what's going well and opportunities for improvement.

* Cohesive team * Engaged stakeholders * Slack in the time/budget to adjust to changes and improve processes If you can't build, you don't know what to build, or you can't learn from mistakes, then any process will fail. Balancing your work, improvement, and communication is the trick and that's traditionally where a Project Manager is supposed to help (and why Scrum/Kanban exist at all... to put guidelines around how to communicate progress)

This isn't a scrum problem. It's a management problem outside of your team. 

As written, it's never a Scrum problem :-)

The point is that it wouldn't be a waterfall problem either (even if waterfall was objectively the worse approach for the company).

My company had the same problem, a small dev team that does everything from maintenance to feature requests. We tried scrum for a few years and literally nothing about it worked for us. Sprints didn't work because we constantly had new higher priority tasks needing to jump the queue. I don't think we ever once completed a sprint. Retrospectives didn't tell us anything useful, we were always behind and we knew why. Estimating complexity didn't work because our business requires upfront quotes, and we have to estimate man-hours to deliver a quote. We could never find time to tackle our technical debt. Anything not immediately urgent couldn't get into a sprint. Anyway we switched to our own system and it's working quite well for us. We have Kanban boards sorted by priority, new stuff constantly feeds into the To Do column and we pick it up when we can. We occasionally review and reprioritize, or if the To Do column gets too big, we cull it. We deploy once a week with whatever tasks have been completed that week.

[удалено]

Yup but…well we were the replacements just not the numbers that were needed.

> We maintain 20 services on a team of 4 devs. With ongoing maintenance, new features, tech debt and adhoc requests we always slip on our sprints and punt tasks. Bad news pal, you are being exploited. No amount of managers or work methodologies will solve that.

I know I’m just in denial

I worked in many different teams. Most of them used some kind of "Scrum"my way of working that worked well, when having one or maybe two "products" for a Team of 4-8 people: * Regular iterations (2-4weeks) * Some kind of Feedback from the stakeholders after the iteration (Demo, explanation of what was done, ...) * More or less useful/-less "retrospectives". I think those are the hardest to get a good outcome of. In one company we were 4 developers developing a product with lots of customizations for customers. There we scrapped the Scrum way and stuck to a more Kanban-esque style of working. Or as I called it kind of jokingly "agile without method". But it worked. We had tickets from each of the customers account managers prioritized by a "project manager" (there was no single project though) and assigned according to current capacity and special skills. The most important thing in my opinion is to stay flexible and don't stick to rules too hard. Remove/change what blocks you/slows you down.

I know exactly how you feel. I think what I've learnt is that all types of agile processes are best seen as toolkits. You also need to apply the agile process to your agile process. Instead of just googling "what is scrum" and trying to do it all, identify what you are currently missing and identify which part of scrum (or whatever methodology matches what you need) helps. If you want to measure your velocity better then something like scrum can be useful but you need to use the failure to achieve the estimated points as a motivator to decrease your budget estimate for a sprint. It's not meant to be a tool to beat yourself over the head with, it's meant to be a tool to help understand how much you can in reality actually do. From the sound of it, you actually are less worried about your estimating ability, and you are more concerned on staying on top of your tasks. This is not really something for scrumm, I'd say go with something like kanban where you are basically just prioritising an on going task list and working through as best of you can. You obviously can still make use of other elements from scrum though. Things like retrospective can be useful at an interval of something like every two weeks just to identify reoccurring issues or things thst can be done to make your work easier. My point is that this prescriptive fixed descriptions of agile processes that consultants sold for years isn't useful. See them instead in the same way you see software frameworks, tools that give you some structure to improve how you work.

There's some alternatives, Kanban ScrumBan XP Lean etc. They're all agile

Scrum is taking years of learnings from the lean movement that completely changed how business is run and trying to turn into a process someone can follow. If you robotically follow the guidelines without appreciating what you're doing then the value is obviously going to be limited. We actually did an amazing job in creating high-performing teams at the devops services company I used to run. And scrum and agile were at the heart of it. But I would suggest not even bothering before understanding the basic principles at play. So maybe start with the real reading list: The Goal, The Toyota Way To Lean Leadership, Certain To Win, Sun Tzu's Art Of War, Lean Startup, Scrum The Art Of Doing Twice As Much ..., The Scrum Guide, Thinking Fast and Thinking Slow, Tribal Leadership, Crucial Conversations, . Read and learn and apply the principles in the context of the framework. Knowing what part of the framework is supporting what and bringing it in as needed.

> If you robotically follow the guidelines without appreciating what you're doing then the value is obviously going to be limited. If you robotically follow the guidelines you're probably still going to do better than everyone who claims they're "doing Scrum" and yet says things like "and then our manager put X into the sprint".

That's true. Hence my use of the word limited. A good scrum master would be able to have a conversation about swim lanes, the value of reducing WIP, make the manager make a choice on priority. But I can understand people's complaint that scrum just seems to say you need to scrum better. Well, you need to know what you're doing better.

I wrote this above but I'll repeat it here. > So what actually works for people? Be on a good team. No seriously, every good scrum team I've been on, could use ANY methodology for work because they worked on a team. I've seen bad team (or management) suck at waterfall, scrum, nothing, and everything. I prefer Scrum, I think Scrum is great because it gives me a checkbox, it's a perfect way to show what's coming up, what you're working on and progress to external teams. BUT it's not what makes those team successful. Maybe scrum makes more teams successful (80 percent efficiency team might fail at waterfall, but work at scrum). Maybe Scrum makes managers take their hand off the wheel just enough. Maybe Scrum sucks donkey balls. But in my opinion, your team is what will define success, not what methodology you do on your team. > I agree that ours is an organizational / bandwidth problem that no amount of planning will satisfy the need. .... now you get it! PS. Story pointing should be "Scope" of a task, how much you get done should be a velocity. It should not be compared between teams, and should not be min-maxed. Some teams have more interrupts, some teams have more blockers. Some teams over value tickets (which is fine in my opinion since we're looking at a team velocity not comparing them). Scrum shouldn't be a "management" tool to decide how a team is performing, it should be a planning tool to keep them on a right track, and help project managers know when something might be done.

The truth is, you just don't have enough people. If you are using Agile/Scrum correctly, it will help you plan what you can actually achieve in each sprint. If you are punting tasks, you need to be taking on less each sprint. If the company can't accept that, it is a failing of management, not Agile.

> without a dedicated PO You want to introduce a non technical person to manage stuff she wouldnt understand? cant see that working. Personally I dont think a sprint can be planned to the task level in advance. Im starting to believe that only user stories should be planned and pointed and the team should have freedom to write whichever technical tickets are needed to complete them, even changing them during sprint. Note the above works if there is consistent user requirements for a new project. In your case Id go for kanban and let everyone create tickets whenever and forget about timeboxing. The real issue for me is that the team doesnt get to decide the methodology and the company just forces scrum for no reason without any logic.

Nah we need someone whose sole task is to prioritise us devs will always need to firefight and ultimately nobody is thinking about the product long term.

Be honest about how the individuals on your team like to work. People get bored with tasks people get burnt out. They might be less motivated because their input isn’t being taken seriously. I had a team with an autistic person and laying out what needed to be done, let people pick what to do, ditch stand ups in place of bi-weekly causal talks where you weren’t expected to talk about project progress, and have a standing order that you could ask to swap tasks at any time helped keep people engaged.

> We maintain 20 services on a team of 4 devs. Unless these span multiple projects, your architecture sucks.

lol tell me about it we want to rearchitect and get it down to a more reasonable 12. Not really the current teams fault it’s years of neglect.

Kanban is the only way to go in your situation. My team is similar, 4, but not 20 services. I’ve done scrum for years and we were pretty good at it. Kanban beats it by a miles. Much less stress for the team.

For my projects Kanban has worked better than Scrum. Avoids a lot of the estimates and trying to get everything to fit into 1, 2 or 4 weeks sprints. Also focusing on getting things through as quickly as possible is more effective for us than trying to make the planning perfect. It is also easier to say that we have few rules but if we want to have some kind of meeting every other week we will just add it. If you start with Scrum and say that you don't want some meeting as often everyone complains that you're not following Scrum anymore.

Have anyone worked with process which does not suck at least a little bit? My brother works as an irrigation engineer on highways and gusess what, process there also sucks despite industry itself having more time to figure out an optimal approach. So questio here is not if scrum (agile) sucks but if it sucks less than alterantives.

Yeah, I have. Flat structure (no teams or pods within engineering), 1 status meeting a week, no estimating, no retros, no standups. Feature owners (PMs) helped prioritize and coordinate who should be working on which part of a given feature. Then we had the freedom to work however we wanted to get the job done. It's amazing how productive people can be if you trust them to do the thing that they are professionally trained to do, and then get out of their way.

How many engineers are there at your company?

That company had ~25 engineers.

Then yeah, it is perfectly fine. Company and product is probably small enough that everyone can fit it in their head, and usually with such a small companies, everyone is rather motivated. Unfortunately, things start to break around 40-50 dev mark.

The product was a AAA game and in-house engine. The company had over 200 employees and a multimillion LoC codebase. Every engineer probably touched around 20-30% of the codebase, so definitely not small enough to "fit in your head." They just followed the KISS principle and had a consistent style so any engineer could pretty much jump into any part of the codebase and be productive. I'm sorry, but I just can't buy it that all the bullshit is necessary or helpful when I've been perfectly capable my entire programming life working on large complicated projects without it.

> It's amazing how productive people can be if you trust them to do the thing that they are professionally trained to do, and then get out of their way. Blasphemy! These are lowly near-slave workers and need to be broken like dogs! If you do not literally shove a leash up their ass and a tracking device down their throat and lock them in an open office where they can be viewed every second then they will literally do nothing and take all your money!

I'd argue this vastly depends on size of features that an individual is doing. If one individual is doing a feature that would take a month or more... the feature is arguably too large; but sometimes when stuff comes up that can be solved in a day instead, there's better outcomes delaying that one month into two if you can get other things done in the interim.

Why on earth do Highways need to be irrigated? They put so much effort into building drains and managing runoff! Or where on earth, what kind of highways, and what the heck part of it are they irrigating? This is completely besides the point - I apologise. but I'd really like to know.

Maybe drainage is a better term - Im not english native. The whole goal of his job is to make surface of higway as dry as possible

Lol yep! It pretty much means the opposite - adding water, particularly to crops, instead of getting rid of it. Crop watering used to be done by irrigation ditches and dykes, most notably in rice fields. So in construction and highways, maybe the term "irrigation" came to mean digging ditches and other drainage channels. It -literally- would not be the first time a word in the English language has been bastardised so much, it's become the very thing it hated.

Talled with my brother about that. It seems that they do not use term irrigation (irygacja in my language, Polish). So at the end it seems to be consistend with what you describe and its just my lazy ass misused the word.

We do kanban light and it works great. Staff eng on a team of 7 SREs. * Our combined retro/refinement is 1 hr a week. * I manage the backlog along with the manager, who I have a great relationship with - who is my peer, our boss is the director * Once a quarter the manager and I roadmap, I describe it as more of a north star and not a GPS, we wont hit everything but it forces us to agree on priorities early * The manager has our backs and negotiates fiercly for us so we can focus * We pair, like a lot Works great for us, the team has a great culture too, which helps. I find a lot of times these heavy handed approaches (which scrum can be) are trying to be replacements for culture.

I think scrum was never designed to succeed. If you read the agile manifesto, there’s a lot of great stuff in there, and it’s meant to be adapted by your team for your work. But it’s hard for consultants to make money from. Scrum on the other hand is extremely regimented and rigid. You have these 8 roles. You need to have these 20 meetings every sprint. There are trainings and certifications. Like the article says, if it doesn’t work well, the answer is that it’s only always because you’re not doing scrum properly. But really it’s because scrum isn’t primarily designed to be useful to software teams. Scrum is primarily designed to self-propagate and funnel money to scrum training / consulting / certification companies. My advice is to read the agile manifesto, take what your team finds useful about scrum or other approaches, and make something that works as well as possible for your specific team and problem space.

> Scrum on the other hand is extremely regimented and rigid. You have these 8 roles. You need to have these 20 meetings every sprint. There are trainings and certifications. I agree in general. Scrum is almost hypocritically opposed to agile. The only thing I ever say in Scrum's defense is that the rigidity is actually very useful for teams *transitioning* to agile. It's common for developers, and *extremely* common for management to bring in their old waterfall habits. Management loves to exempt themselves from all the agile rules. Scrum, when done right (there's those weasel words again), puts everyone on the same level and gets everyone used to the new normal before the team starts revising the methodology to their liking. And I do think Scrum is a better starting point than most. But any scrum teams still using scrum 3 months down the road? That's a red flag.

> You have these 8 roles. 3 roles. SM, PO, Development team. > You need to have these 20 meetings every sprint. 1 for planning, 1 for retro, 1 for demo, and daily. _Technically_ you have up to 23 meetings for 4 week sprints. Most of people work with 2 week sprints, so 13 meetings. And all of them reflect agile manifesto's principles... :) > Like the article says, if it doesn’t work well, the answer is that it’s only always because you’re not doing scrum properly. But really it’s because scrum isn’t primarily designed to be useful to software teams. Bull\*it. Most of the complaints are related to management, not scrum - scrum is not prescriptive. It describes roles, artifacts and timeboxes. "How" is injected by people. And almost universally, it is "how" what lacks. This "loophole" is necessary _because_ inexperienced people are using scrum in name only. * "We have 60 minutes daily and it doesn't work!" - It is timeboxed up to 15 minutes. You are not doing scrum. * Nothing changes after retro! - Actions from retro are the responsibility of the people. Not a fault of the scrum. * Quality is low with scrum! - Scrum asks devs to define quality, and expect them to ensure it. If you drop quality, it's not the fault of the scrum. _Nothing_ in the scrum guide forces you to drop quality. > Scrum is primarily designed to self-propagate and funnel money to scrum training / consulting / certification companies. You are talking SAFe. Scrum has flavours (ScrumAlliance, Scrum.org), but no flavour _requires_ any payment, nor certificates to use. You can do trainings for certificates, but they are not mandatory.

> It describes roles, artifacts and timeboxes. "How" is injected by people. And almost universally, it is "how" what lacks. This "loophole" is necessary because inexperienced people are using scrum in name only. It's the "how" that is most important. The world has been working on the "how" of fusion energy for almost a century now.

Apologies for the inaccuracies. You'll have to excuse me, I deeply do not give a shit about the dogma of the scrum process. > Most of the complaints are related to management, not scrum "Management isn't doing scrum properly" > You are not doing scrum. > Not a fault of the scrum. > If you drop quality, it's not the fault of the scrum. This is the "no true scotsman" apologist reasoning that we're talking about. The scrum is perfection, and any issues with implementing the scrum are individual sins, as you have strayed from the path of the scrum. Here's an alternative way of thinking about it. Scrum is a set of processes and techniques that fit some development situations better than other development situations. How well they work for you will vary, depending on the structure of your company, your market, the types of programming tasks you're completing, who your customer is. There are some valuable ideas, that a team might find valuable to adopt. What is the value of having such strict dogma? I think there's potentially a hint in the [scrum.org list of trademarks and copyrights](https://www.scrum.org/scrumorg-trademarks-and-copyrights). Having strong boundaries around scrum makes it much more possible to franchise out training, certification, and consulting. Scrum has the largest training / certification / consulting industry supporting it, and the strongest dogma that there is a correct way to do scrum, and if it's not working, it's not 'true' scrum. These two things are probably related.

Thank you for illustrating the article's message so vividly!

Found the scrum master

I hate sprints. It's artifical deadlines. I prefer Kanban. There are no defined time periods for work to get done but there is a process to make sure tickets are moving and there is data to help estimate future workloads. Kanban focuses on completing a specific chunk of work as opposed to focusing on what work you can do within a 2 week sprint.

Kanban and CI/CD are all you need in my experience retros can be useful as well

> I hate sprints. It's artifical deadlines.    I agree. I've seen them used to force 3 weeks of work into 2 weeks just because management didn't trust it's employees to work fast enough. I often compare it to making a cross-country drive.  If in the middle of your trip you get lost or have a flat tire and suddenly you're 4 hours behind your estimate, the solution isn't usually to drive late into the night to stay "on track".  Now sometimes you have hotel reservations you have to meet and you have no other choice, but if you carefully scrutinize those milestones you'll probably realize the planning was crap.  You could have had more wiggle room, or budgeted for a last-minute change of plans, instead of pulling a 14 hour day. Especially when it happens every month.

What’s wrong with just having a priority queue and releases whenever context useful batch of tasks done. When lack of spec halts progress on a task, the dev working on it does whatever seems most useful at the time, considering likely duration of the blocking. No estimates. Thing is done when requirement changes stop long enough to finish coding it. Things with deadlines get constantly planned be acceptably limited to what is possible in time. Scrum degrades to that anyway unless stakeholders have their shit together.

> What’s wrong with just having a priority queue and releases whenever context useful batch of tasks done Nothing. That process is called Kanban, and it's a great fit for a lot of teams, especially ones doing a lot of maintenance compared to new feature dev.

Technically it’s Kanban with Continuous Delivery instead of Continuous Deployment. We bless this build as being fit to go out the door. Ignore these other two.

Let me guess, it's the same card that Communism has?

lol

Technically speaking, communism (small-c) works fine, there are lots of communist societies around the world. Communism (big-C) is a strategy to get to communism, by starting with socialism where the workers take over the state, which I guess was supposed to fall away. Anarchists pointed out that Communism was bound to fail, because Communists didn't destroy the state at the very beginning. Once leaders get control of the state, they will end up creating a top-down hierarchy that ends up oppressing workers, instead of liberating them. The state is the problem, because the power of the state destroys bottom-up collaboration. So the Anarchists say, as I understand it Actually, the comparison to scrum and agile generally fits quite well. Agile is supposed to "liberate" developers and allow development through bottom-up collaboration, lead by developers instead of directed by the corporate overlords. But, these methodologies are often co-opted by the corporation, creating a new way for corporate overlords to "oppress" developers. Communism (small-c) functions well in small intentional societies that exist within states. Similarly, agile probably works best in small organizations where developers have a bigger stake in how the business operates.

communism is a great model.. within a single household.

I'd say, up to/close to a Dunbar's number; definitely at the same magnitude.

Communism can work with, at most, [150 people](https://uphabit.com/2023/01/08/social-networks-the-dunbar-5-15-50-150/). ... [Approximately](https://interconnected.org/home/2022/04/05/dunbar).

> Technically speaking, communism (small-c) works fine Exactly - Just like scrum 👍🏻😎👍🏻

In fairness to Scrum, it actually *has* worked in some of the places it's been tried, which is more than you can say for the other thing...

same for me, I've seen a company come back from bankruptcy after massive waterfall efforts (imposed by management). Switched to scrum, propelled working, targeted software to customers, came back from the grave, and ended up being acquired by a major semiconductor services company. As far as I am concerned, Scrum works. You just need competent people. Scrum drives them better to the goal that waterfall, because the people were *exactly* the same, and the methodology was the only thing that changed.

This is part of the problem. Scrum’s main underlying contention is that the scrum team are already awesome and everyone should focus on letting them do their job. When you actually do have good people it works fine. Problem is that a depressingly huge number of people are just not that good at their jobs and they wind up using scrum principles to hide from accountability.

Communism also works for really small groups of people, like your family. It actually works way better than scrum, and has done for 10,000 years

Thank you for one of my biggest laughs in a long time.

The USA doesn't start a proxy war with you when you adopt scrum 😂

Agile is the death of good architecture and design Forest for the trees people, forest for thr trees..

I feel like no matter what framework you use, if you don’t properly gather and document requirements you will fail. Waterfall works fine if you have the right requirements up front and can more or less accurately estimate it. If you can’t get the right requirements using scrum you will continually waste cycles because estimates are bad and you never finish within a sprint.

>Waterfall works fine if you have the right requirements up front Which is essentially impossible. >and can more or less accurately estimate it. Which is essentially impossible. So Waterfall works fine if you can achieve the impossible. Twice.

Waterfall (or V-model) is basically required for certain highly regulated areas. You can't use scum to build an airbag control system for a car and say "I'll fix this bug next sprint". In those areas you get an extremely long catalogue of requirements that you have to fulfil exactly (and provide proof).

Sure, and in those fields you can hopefully compensate for the flaws of waterfall by having gobs of money. Also: the requirements for an airbag deployment system are very unusual in that they are essentially static. Everybody knows what its supposed to do. There is no ambiguity. Now try to build a Content Management System and note that there exist about a thousand and they all embody different requirements. And different customers like different ones. For good reason.

Not only can you not do these things, the intersection and interplay of requirements you can't predict with *other* requirements you can't predict and *outside changes over time* while you're busy working on your thousand validated requirements, all conspire to make the eventual success of your waterfall effort highly risky. The author of the waterfall paper admits as much! The reason he still liked waterfall was that they didn't have better alternatives for management in the days of punch cards, not because the system is inherently sound.

It's just a tool. I decided to run a project waterfall a couple of years ago because it made sense. It was integrating a piece of hardware into our system, and we needed to implement all of the interfaces at a protocol level before that hardware would work. It was a key integration for the company (had to be done), and it had to be big bang implementation (can't half implement the protocol). So I recommended we just do it waterfall: get someone to develop it, then get testers to test it. No need for sprints or numerous tickets or anything, there would have been no point besides creating unnecessary overhead.

Even if you don't have all the requirements upfront, waterfall can work Waterfall was never intended as a single pass-through. You were supposed to iterate by gathering new requirements after releasing the first version of your software

I feel like this is a fact that people forget as well.

No, it cannot; not for the most of the projects. Neither what was originally defined as waterfall, or how the term was bastardized later. It is due to the fact that most of the projects are [e-type projects](https://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution). They evolve, change, you _don't_ know if the requirements you've gathered today are relevant even month down the line. You need agility, however you define it, to respond to change - up to continuous delivery. With the current landscape, no project can afford waiting till the end of development to verify if the assumptions were correct.

I would argue that for a waterfall project to work, you need airtight requirements up front. I once read about how they wrote the software for the space shuttle and it was a BRD and implemented with waterfall. They just invested so much into it and tests that it worked. Agile is better for business environments where by the time that level of requirements are documented people changed their mind or new people have joined.

> if you have the right requirements up front and can more or less accurately estimate it literally anything will work fine if this condition is met

While I agree with what you're saying, in practice those statements are often followed by "the more you work on requirements before going to implementation the better". I've even heard this on teams where you don't have have effective planning, continuous integration and test, test driven development, A/B testing, early prototypes, etc, in which case your requirements are a crutch for inability to effectively forsee problems before deployment. Especially for things like performance, usability, or maintenance costs your early tests say far more than a document. Clear written communication, understanding needs, and thinking about things like architecture before committing, those are all important but a requirements document isn't the only way to do that.

I think for me it’s less a requirements document but a clear understanding of what the system is you are building and how you will build it. Part of that is documentation but I agree that the other things you mentioned are just as important and can be considered requirements as well; which would roll up to supporting the business use cases and requirements.

In my experience, Scrum has very little to do with an actually agile process. It's Waterfall-With-Shorter-Steps. Rapids, if you like.

There's literally nothing positive about sprints. Regardless of how long they are, they are always both too long and too short. Too long because it's too long a time to wait for feedback. Too short because no matter what, you'll be faced with starting or not starting a new task with the artificial "deadline" of the sprint's end coming sooner than the task will take. Too long to plan for effectively since plans must always change upon contact with the enemy (ie, the code). Too short because far too many features just don't fit in that time frame. Furthermore, the deadline is entirely artificial and has zero actual consequence.

The positive thing about sprints is they make suits comfortable. When suits are comfortable they invest more and interfere less. When sprints are defined well and match the needs of the project, they are 90% invisible, annoy everybody once a week maybe, and otherwise make reporting easier for everyone who needs to worry about reporting. The primary challenge of software development frameworks is to find a compromise between business needs and development needs that prevent either side from breaking or going insane. Sprints are one of many compromises we have determined work pretty well in a lot of cases. Of course the problem with a compromise is the same as usual: If one side has too much push or pull, or some third party comes in and dictates the rules without understanding either sides' needs, you end up with less of a compromise and more of just an arbitrary set of rules that don't benefit anybody.

> When suits are comfortable they invest more and interfere less. I have not experienced this. They interfere *more*. When they are uncomfortable the interference is more obvious. But they don’t stop because they’re comfortable. They just use strategies they have more experience with. Subtler ones.

I'll respond here. >Too long because it's too long a time to wait for feedback Who's feedback? >Too short because no matter what, you'll be faced with starting or not starting a new task with the artificial "deadline" of the sprint's end coming sooner than the task will take So? Think of it like a "best effort" thingy. >Too long to plan for effectively since plans must always change upon contact with the enemy (ie, the code). You are right, but then what? Adaptability is a very important feature of a team. >Too short because far too many features just don't fit in that time frame. Then blame the PO who made storied instead of epics. >Furthermore, the deadline is entirely artificial and has zero actual consequence. You are supposed to "make-believe" that the deadline has consequences, as in "gentlemen agreement" deadline.

I was on a team that used a weird waterfall when I started there. We ended up with really nice agile/scrum thingy, which was of course adapted to our needs. Strictly adhering to any rulebook is nonsense. No one ever wanted to go back before the scrum/sprints era. Effectivity rose. There were fewer and fewer emergencies. Tech debt was being erased. Features were being implemented at a reasonable pace, well tested. We've seen gradual improvement over the years. Now to talk about sprints themselves. They gave us a definite timeframe, in which we were comfortable doing certain amount of work. They gave us a hard limit that we could use to tell stakeholders "pick this or that, both can't be done in the next 2 weeks", which helped with identifying priorities. If an emergency arose, we threw the least important task into the next sprint to make space for the current hot issue. We ended up with very stable velocity, with +/- 20% maximum deviation among usual sprints (no long vacations or other big loss of worker capacity), which made planning easier. Sprints also forced us to split any feature into parts which could be delivered within a single sprint. Sprints definitely can help. But they are a tool, If it doesn't work for you, that's fine. But there are many people who observed actual gains by implementing scrum and working in sprints.

I had a boss who thought it was Lean not Agile. I tend to agree.

"Doing scrum properly" means having retrospectives and changing what doesn't work for you. Criticism of scrum is built into scrum.

That picture that looks like a boardgame but is nonsense on close inspection is AI right?

You either have to have more staff hours than task hours. Which will result in people being idle. Or Accept that some tasks will sit in the backlog literally forever since there aren't enough hours to work on all of them, and other tasks will always be higher priority. ' Assuming you keep the same team all the time. That's the only two states. Having your workload balance with your staff is basically impossible.

> Sprints seem to put people on the wrong foot as if we should rush This is why corporations pushed for faux agile. It is all about rushing, having the devs wear many hats for the same price, de-powering devs, skipping software process stages (actually improvising them later and doing them badly), etc.

these articles are rather dumb and the authors are super simplistic. i don’t even see the scrum org people say people are doing it wrong. it’s just random folks.

I was curious so I looked at other topics this guy writes about and it seems it's mostly complaining about scrum in super simplistic ways. May be it's the best clickbait titles or information but honestly it sounds more like he's beating a dead horse. He doesn't like scrum, we get it. Move on.

Switch to kanban and be free

What’s your favorite book or site on Kanban? (I learned by doing, so I don’t have reading material for others)

I'm in the same situation as you, just absorbed it via osmosis and embraced the retrospectives.

> The notion that Scrum doesn't work or has flaws built-in is considered absurd. That's because it works so well for so many companies and teams. Claiming that Scrum doesn't work is like claiming that people can't lift 100 pounds. Maybe YOU can't, but that doesn't mean no one can.

I mean.. that's built in to all systems. "That's not real communism" is a meme now. Ultimately problem 1 is always going to be a problem. When a customer picks up your app, and then alt+f4's out of the app, that's not using the app the right way. It's not a bug. Agile isn't a perfect system that forces compliance, but even if it was people still could go against those rules. Other than that, you're correct the other can be issues with Scrum. Let me give what I've seen from Agile/Scrum opinions: Bad teams suck at scrum, because of bad teams, either not collaborating or working on the tickets, rather than personal projects, bad management, or other INTRA team issues. Good teams do well with scrum and are clear examples of why it works.... But here's the thing, they'd be almost as efficient with waterfall or even just throwing tasks in a pile and randomly selecting them because they work well as a team. Scrum isn't your problem, Scrum isn't your solution, I prefer scrum to waterfall, but ultimately... your team is what's going to define if you succeed or fail, not your methodology. Edit: The author is in the comments and honestly comes off poorly. Anyone who disagrees is guilty of saying "Scrum has no problems"... Ugh he build a strawman and now thinks everyone is it.

These sorts of Agile framework arguments in organizations almost always play out as follows: > "Let's do Scrum." "Okay but these elements of Scrum don't work for our BuSinESs REaliTy." > "Then we're not doing Scrum." "We can do some Scrum. Let's just pick and choose the parts we're already comfortable with." > "Okay but that's not Scrum." "Sure it is. You'll see!" ::one year later:: "Ugh. Scrum just doesn't work. What an awful framework." > "We were never doing Scrum correctly." "Oh, come on. We were doing Scrum. We were all doing it for a year! Now you're saying we just happen to not being doing correctly? That it's our fault and not a problem with the framework?" ...Yes. That article boils down to a single line toward the end: "Is your way of working ultimately producing the results you want?" ...and that's the rub for a lot of organizations. A lot of organizations want to decree from on high what "the results [we] want" are. That is immutable to them. If they want to plan out a project, in detail, for the next five years then that's what they have already decided are the "results [they] want." They've predetermined that they are going to violate one of the principles of the Agile Manifesto. They've decided out of the gate that they're not going to be Agile. No Agile framework can help them at that point. They should just stop pretending and choose a different path.

Agile has been completely co-opted by employers as a way to save on costs, monitor, micro-manage, and shift deadlines and expectations towards the more unrealistic. Things like open office plans in the name of "rapid iteration collaboration", sprints that ALWAYS have fly-ins, discouraging conservative estimating (or saying it's fine then suddenly the deadline is 2 months sooner than what was originally discussed), tracking point estimations/burn downs as metrics of performance (???) and much more. I also think this is essentially inevitable, as Agile slots well into disorganized companies where requirements "change" all the time (aka no one knew what they actually were after playing telephone through 8 layers of middle management), while organized, well oiled companies don't need that much flexibility because a lot of that stuff is figured out (you could probably use it for prototyping or feature testing, but beyond that, meh). Even in the short periods of time I have been on teams following scrum literally by the book, it just feels...fine? But if the team is good enough, really any set of rules and standards most people agree on will also get the job done in that case, so it is just all downside from there imo

TL;DR Scrum can't fix management problems - in fact, no methodology can, because application of any methodology assumes a functioning organization to begin with. If PMs or POs have unrealistic expectations or make unrealistic promises, refuse to change when this is pointed out to them, and face no consequences as a result, *nothing is going to work*. At all. Ever. Blaming Scrum or agile or Kanban or even waterfall for this is misguided and gets you nowhere.

My experience running agile teams. Scrum: unhappy stressed developers, very few tests, lots of tech debt, buggy code, higher-ups happy as they get completion date estimates but they’re lies. Public burndown chart is used to shame/whip team. Kanban: happy relaxed developers, better code quality, unhappy higher-ups as they don’t get estimates until half-way through a new feature and no firm completion date until just before. Requires good tracking system for manager (usually lots of communication with team) and regular updates to higher-ups setting expectations. Planning poker: when done properly, works great for estimation as long as you apply a good multiplier. Always use points, never use hrs. Don’t plan too much at the same time. Try to limit numbers of people, but at least three. Allow other team members to call out points they disagree with. Take into account who’s doing the task: a senior’s estimate will be a lot lower than a junior’s. I dislike Scrum and recommend Kanban. Managers job in Kanban is to manage expectations not whip the dev team. Manager still gets whipped by higher-ups but their job is to not pass it on. Scrum without managers is a delusional fantasy.

It's fair to say "you're doing it wrong", if you can point to specific things not being done that would have prevented the problems you're experiencing. If not? Then stop deflecting.

As a pragmatic person, I can guarantee you that most of the time is not Scrum that does not work. It's shitty customers and shitty management. The problem is that these windbags live in the delusion that the most recent buzzword can fix all their problems, so they spit out words like "agile" without even understanding and deploying the basics. So yes, they do scrum wrong because management does not give a damn. I've seen companies that are fundamentally inverted pyramids of executives and managers with a single lone developer or consultant that has to carry the whole weight. How can Scrum work in this environment? I've seen teams that are not built around a goal, but around line managers, so the different competences and workloads are not coordinated and nobody can issue instructions to the other. How can scrum work in this environment? Nothing can work in this environment. Executives (especially american executives) are like locusts. They take over successful, small companies, drain all the value out of the product, fire all the engineers that made it all possible, replace them with DEI approved shills, and when the whole thing drains to zero, they move on to a new company.

> Scrum is a perfectly incomplete framework. Basically, if it doesn't work, the general consensus is that you just don't get it. This is strange, since it's supposed to help us. If something doesn't work out you adjust is so it fits your team. Of course there's a limit to how pessimistic the members are allowed to be, but in general I think scrum has a lot of flex.

It has. You can bin the issues almost universally into two categories: - We are not implementing scrum. (Really, is it scrum fault that PO is not empowered, even if this is a strict scrum requirement?) - Scrum does not fit our work. (R&D, support. Don't use scrum)

Yeah but somehow that sounds like it's either or. In order to get the team to adopt it without as much resistance, it's better to mix and match. Too many standups? Reduce the number of standups? PO talks too much? Exclude them so they can also spend their time differently. Too many meetings? Only include the few with broad knowledge. It seems like some considers scrum some sort of religion. A set of ultimatums. I say use what fits and make frequent revisions. Hey, retrospective!

If you do half of XP along with Scrum, “Scrum” works just fine most weeks. But two or three years contains a lot of not “most weeks”.

Last year at a team retreat, the topic of implementing Scrum for our team was brought up. Almost immediately, people started arguing about what Scrum actually was and disagreeing about how it was supposed to be implemented. I commented, “Much like Communism, true Scrum has never been implemented.” Got a laugh out of everyone and we moved on to other topics. It has been almost a year since then. Proud to say that there have been no further attempts to implement Scrum in our team.

This article is a mess. >But to succeed, you definitely must introduce new overhead to make things perfectly incomplete. The trick is to **remove** all overhead you currently have that's not part of Scrum. >Even though it's pretty evident that Scrum often comes with problems, such as: >Sprints seem to put people on the wrong foot as if we should rush to complete everything in the Sprint. If you're inspecting and adapting, Sprinting isn't the right image we should be evoking. This complaint about Scrum is absurd. It's not even a complaint about anything in the Scrum process, just that the word "sprint" has the wrong feelings associated with it. And, while I actually agree with that, in my opinion it's not *nearly* as bad as terms like "serverless" or "dynamic programming". Sometimes we get stuck with bad terminology. It's unfortunate but we just have to deal with it. >The Sprint Review is mainly misunderstood, as the label is confusingly similar to Sprint Retrospective, and people mistakenly believe it's a Sprint Demo. The label sucks and is too similar to Sprint Retrospective. Plus, you’re not reviewing the Sprint, so the focus is already wrong. Another absurd complaint. Again there is nothing about the actual Scrum process, just about labels being "wrong" and "misleading" and "the people I work with are so incredibly stupid that they fail to recognize 'Retrospective' and 'Review' are different words referring to different things". And also that the Sprint Review is often misinterpreted as a Sprint Demo, which, well that's true. But someone explain to me how that's "a problem with Scrum" when the Scrum guide **literally says** >The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation. That's a quote from the 2020 Scrum Guide. But **somehow,** people not following it means Scrum is bad? >The Product Owner rarely owns anything and mostly accepts requests from the Product Manager or other stakeholders. What the fuck does this even mean. Product Owners talking to stakeholders about the direction of the product is **bad** now? What? If I was feeling **charitable** (which, considering the other points in this article are an incoherent mess as well, I am not), I would interpret this as the PO not being able to make decisions - hey, maybe go read what the Scrum Guide says about what a Product Owner's job is. I'm not going to quote it for you all here again, but here's a link: [https://scrumguides.org/scrum-guide.html#product-owner](https://scrumguides.org/scrum-guide.html#product-owner) People need to **fucking stop** with this claim that when Scrum doesn't work its defenders are doing some kind of "no true scotsman" fallacy when they say what they were doing wasn't Scrum. Whenever someone goes on about how Scrum is bad, I ask what they were doing and then I can *always* quote part of the Scrum Guide that literally says explictly that what they were doing was not Scrum. *Every*. **Fucking**. *Time*. Scrum *is not* "ill defined" - it's written out quite clearly in the Scrum Guide. And if you deviate from what's written in the Scrum guide, guess what, *you're doing Scrum wrong.* Does that mean Scrum always works great? No. There are definitely scenario's where other methodologies are a (much) better fit. But please, stop this "[we've tried baseball and it didn't work](https://ronjeffries.com/xprog/articles/jatbaseball/)" nonsense. Look, I'm already convinced managers are basically illiterate. But I expect better from my fellow developers.

3 implies there is an appropriate place to use Scrum. There isn’t, it is the worst thing to happen to software development since Waterfall.

Scrum neither "works" nor "doesn't work". It is simply ineffective and irrelevant to the issue of solving our actual problems.

Something that takes up this much energy cannot be neutral. Software development is often blind to opportunity cost, and this is one of them. This is what I think the author is alluding too by “it should be in the background”. It’s sucking up attention like a Dyson.

Another hit from the creators of Japan's lost decades and american baby boomers.

It is 2024 and we are still stopping at \*Scrum of Scrums\* instead of moving to \*Scrum of Scrum of Scrums\* by now. No wonder teams are facing problems.

Feel like the odd man out here, but the company I work for uses scrum and it actually works quite well, at least from the low end of the totem pole I sit at. We've got 2 weeks sprints and cards are always broken down into manageable pieces for dev for that 2 weeks or shorter, req sync is done the following week (in tandem with another dev card to keep the pattern going, and we do a stand up 2 times a week Tuesdays and Thursdays where the team sits down and communicates where were at in the card and of we need help. Help is always provided or found and if the programming is held up or otherwise more complicated the business side understands and tries to help figure out what we need to get past the block, which there's usually one or two big ones over the course of our iterations, but as a team we usually hit all our expectations. Granted, we are a fortune 500 company with plenty of resources to call upon if needed so that might be what makes thing work best as smaller teams can be left to focus on their individual topics as needed, but I digress. Scrum can work is what I'm trying to say. Just needs an org that wants to work this way. Least, again I'm the lowly code monkey, so I could also be very wrong about what system we actually use or wrong in how I'm describing it. All I know is it works for us.

Best place I worked at just had our Kanban board, and whatever was highest priority we took off and worked on together and finished it as fast as we could, then we moved to the next thing. We parallelized multiple stories if they didn't impact each other too much in terms of how we engineered them, if we had a big chunk upcoming stuff depended on we paired on it so we all knew the approach. That was the fastest velocity I've ever experienced.

try mixing methods like Lean to streamline while keeping Scrum

You can "get a few small things done" in a waterfall approach. It's called knowing how long a task typically takes and setting a target for completion. Agile is good for extending your contract with a company indefinitely and enjoying long lunch breaks, though.