I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting.<p>I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that I must be exaggerating or lying. He then fell back to a lecture about how Scrum is an industry standard and how it's more efficient than alternatives.<p>Really opened my eyes to the disconnect between Scrum mythology and Scrum in practice. The amount of time lost to doing Scrum things was so out of control that some people had fewer than 3-4 hours per day to actually work.<p>Of course, the Scrum proponents will rush in and tell me that we were doing it wrong or that it's not truly Scrum if it's helping more than hurting, but these people were highly trained in the ways of Scrum and Agile and pointed to various Scrum and Agile books and certifications to defend their ways.<p>OTOH, I have been on very small teams where Scrum was implemented with low overhead, but those teams were filled with efficient people who would have been productive without formal methodologies either way.
I've seen it suck even worse when trying to manage large X-Ops organizations. Something about the work, let's call it DevOps for the sake of simplicity, simply does not seem to lend itself well to the scrum methodology. Often priorities will shift rapidly even during the course of 1 working day, issues are vaguely defined and poorly scoped by nature (AZ1 cannot reach AZ2, plz fix ASAP), and the work is extraordinarily hard to measure complexity/effort (a one line config change can take weeks of investigation and touch tons of services).<p>I've seen plenty of people try though, to varying degrees of unsuccess. A kanban style system has always worked better for me personally.
I agree that agile methodologies are a whole lot of bullshit, but the problem really is cargo cult.<p>Most people working in software are juniors, and that includes most managers. The fact that they have a title of "VP operations" 2 years after graduating does not magically make them experienced. What do they do then? They read books about "how to lead a team", and they blindly apply what they find there.<p>Because they have no clue. Many times they have not even had a team lead in there professional career themselves: they jumped right into management. And of course their team of junior developers (with high titles that don't make them experienced either) don't know better. So it ends up in a big cargo cult. Which sucks.
One comment - the article mentions that Waterfall was basically the only approach used prior to agile. This is false. In some industries waterfall was used, but in others software was designed and driven incrementally just as with core agile. The work I did in fixed income brokerages in the early 90s was largely ad hoc agile.
The things I've taken from scrum and use at every team:<p>- plan in 2 week chunks<p>- estimate in points (relative size to something you've already done), emphasis on consistent estimates for each dev.<p>- make sure you define what 'done' means, and make sure it relates to what exactly you are trying to measure (Eg just coding effort, work till feature can ship?, etc). This is probably the most tricky bit.<p>- capture total velocity every 2 weeks and eventually use the avg for future planning<p>- review the entire process and modify things that take a lot of time for devs.
I’ve seen “scrum” work. The single most important thing we did was the retro always happened. In the retro we somehow managed to create a safe space where we could honestly discuss ways to improve. This may never be repeatable depending on the culture of the company, but the goal of a retro is to be a safe space where honesty is possible. Without honesty there can be no improvement to the process. Is some ceremony providing no value? That should come up in the retro. Proposed fixes should surface in the retro. Maybe you dump the ceremony, or do it less often. Ceremony is sort of stupid in general, but it’s often there because historically for some large percent of teams it was useful occassionally. It may not be useful for your team.<p>Retros are hard. Managers will try to run them. People can’t be honest with managers present. At least half an hour of the retro should be without the manager present. Retros should should also be long enough they feel slightly painful. There are people who have a hard time finding their voice in a group setting, especially with difficult topics. Giving them time and opportunity to speak is essential.
None of the things the author complains about are specified in Scrum. The Scrum guide states that the developers choose the work: "Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint." I've also heard people complain about the meetings, but honestly people hate meetings generally--my current team doesn't do Scrum or any other agile system, and we still have several time-wasting meetings every week. In my experience, scrum reduces the meetings you need to have to a minimum, and each one is there for a reason. If you use each meeting for its reason, they are valuable, if not, then sure, they probably are a waste of time.<p>I know that scrum has often been weaponized by managers and tools, but scrum doesn't prescribe this. Scrum doesn't prescribe story points or velocity or burndown charts. Those things may suck at your company, but they're not Scrum's fault.<p>Personally I like Scrum. I like the focus of the sprint goal and I like being able to show what I did at the end of the sprint. My team, as I say, has no process, and I started implementing scrum just for myself and my projects, that I work on solo. It's not perfect or ideal but it's better than any other system I've seen.
Having spent a year or so in a scrum and "scaled agile framework" shop, this resonates.<p>The disease is KPIs and metrics, and I'm betting it has gotten worse since COVID and WFH.<p>As the article states, teams have to focus on capturing every iota of work in tickets and stories and make sure they log the closures correct ly and tie every task to a greater story.<p>Scrum tools and pointing and tickets should <i>support</i> the goal of writing functional software. But when middle management demands 15 different KPIs determined by various calculations of time, estimates of effort and # tickets closed, the tickets/stories/epics become the goal, and development is the sideshow.<p>Before my devops role in 2019/2020, I was on a security operations team. We did our version of Kanban. It was simply organizing all our bigger goals/projects (initiatives with a definable end state) into backlog, doing, blocked, done. Operational tasks were worked on without documentation (daily software patches, on call tasks, etc) and small tasks from external teams were documented with a ticketing system and a 3 day SLO. A breach of SLO was not measured in any reporting! It was a good-faith goal that we met most of the time, and if it were breached and the external team got angry they could escalate to our manager.<p>The point is, the tools we used were made for the team's benefit of productivity and organization, without manager-observed KPIs. We just got shit done.
People who don’t use scrum or sprints or any of it, two questions: 1. Do you actually have very few meeting and all of them are meaningful and useful? 2. Is your work predictable and both devs and PMs have a reasonable idea of how much work is coming up and the nature of the work?<p>I’ve worked on “no sprint” teams and I end up having several “weekly checkin” meetings for different projects, plus intermittent “stand ups” that lack a clear focus, plus my manager discussing tactical matters in 1:1s and the work plan is still a clusterfuck where it’s hard to know what’s priority, what work is coming up, ensuring we have requirements clarified before starting work etc..<p>The biggest mistake I see people making with sprints is not understanding that you cluster your planning over 1-2 days then you have 2-3 weeks with basically <i>zero</i> meetings besides standup or working meetings like system design. The benefit of scrum is lots of heads down time, the <i>cost</i> is you’re not allowed to just book meetings Willy nilly whenever you want. Most places I’ve worked have wanted the benefit of sprints but not understood or been willing to pay the cost (no-meeting weeks). So it’s agile rituals <i>plus</i> whatever other meetings you already had, and of course that sucks.<p>I feel like agile processes are this boogeyman and people think “just get rid of them and we’ll be good!” but you need <i>some</i> process or else work is chaotic. So what’s the better process that works for you?
The term scrum comes from rugby, and it has nothing to do with organization. It's literally when something goes wrong, pack everyone together and get the ball moving again. Symbolically, obviously, ball=project.<p>The problem, like everything these days, is corporatism. Things have been added to the old development model to create positions for knowledgeless managers to do nothing and make money. Agile means fast without preparation. That name no longer reflects the model.<p>These days, businesses have become so ritualistic to maintain power structure that they're inefficient, and morale is low. It gets to an unsustainable point and fails, meaning mass layoffs and restructuring, or the organization itself going down.
It's interesting to speculate on why, if Scrum is so bad, everyone uses it?<p>Is it because everyone is an idiot (e.g. management)? Or for some nefarious reason? Or maybe it isn't actually that bad?<p>On one project I was on, there was a contractor company billing millions per year to create a React admin tool frontend. Many developers involved, Scrum master full-time, and so on. Tickets were created for small parts of features, of course not considering anything more than 2 weeks ahead due to agility, then later other tickets would be created for the next phase of the feature so everything that had been done so far had to be thrown away as it was wrong (great for billable hours), etc.<p>The person on the customer's side managing this didn't really know what they wanted, so was happy to be told that, due to agility, they wouldn't have to specify anything more than two weeks ahead. A big decision can't be wrong if you aren't allowed to make big decisions! Can't get fired for decisions being wrong if you aren't allowed to make them.<p>So everyone won out of this situation really.<p>I don't know if there would have been a better way to manage this project. But I can see what everyone got out of it.
Scrum is a decent framework for teaching business stakeholders how to work in an agile fashion, and to force some developers to always have releasable software.<p>But at a certain point people get so attached to the process (or teaching process) that they get scared to take the training wheels off. So yes, Scrum sucks.
From a more constructive "what is there besides scrum" I've been enjoying this persons blog and especially his book on software systems: <a href="https://softwarecrisis.baldurbjarnason.com/" rel="nofollow">https://softwarecrisis.baldurbjarnason.com/</a>
"Way of work should be defined at a team level by its people, not by the company." - This is basically the origin of scrum.<p>Essentially every problem ascribed to scrum is its departure from this origin story.<p>Scrum is about making each team work better, but somehow it turned into the same weird top-down imposed structure that it was supposed to replace. 2 week sprints are mandatory for all teams? They all have to start and stop on the same day? And you can use any story point system you want as long as they neatly summarize into these t-shirt sizes?<p>There is little resemblance between the agile manifesto and what people are pretending to do today.
I have never, ever worked at a company where I e joyed any form of agile or scrum. All it did was kill my joy, add more meetings and complicate even the simplest things. I honestly wish it would just go away.
Scrum/Agile is awesome! I always used the daily calls to ask as much dumb shit as possible to make the meetings as long as i could so i could keep charging my hourly rate without actually working.
I wish there was an executive scrum that the rest of the company could see what their work load was for the week and how it was co-ordinated.<p>My feeling on scrum was it was always a way to daylight what people were doing for upper levels (and co-ordinating that work). It would be nice to see what higher echelons were actually working on.
Aside: We need an alternate viewing filter for medium like how nitter is to X.<p>Every time I open a medium hosted link it is just unbearable.<p>Edit: The firefox reader view (F9) works very well at getting rid of Medium nonsense and making it clean.
You know when some tools have a section <i>When to use X</i> and <i>When not to use X</i> ? (e.g.
<a href="https://htmx.org/essays/when-to-use-hypermedia/" rel="nofollow">https://htmx.org/essays/when-to-use-hypermedia/</a>). Management frameworks like Scrum should have the same, and should not be followed blindly. There are specific historical contexts and reasons why they were invented and those should not be ignored.<p>So, when is Scrum a good fit, and when is it not?
Scrum isn't the problem. It's your company's culture or whatever other dysfunction exists. Scrum is just how developers experience that. You could switch systems, but you'll just get beatings of a different flavor.
Here is a typical scrum meeting:<p>7-10 people gather in a circle every day, they all say “no blockers” or some talkative person diggs up some detail that sounds like it’s for another discussion, then they repeat “continuing to what I did yesterday” because we all already know, the scrum master tries to say something new but it sounds like BS, meeting over and we are all shaking our heads thinking “another waste of 10 minutes”
<p><pre><code> Take the retrospective seriously, as a moment to reflect with a clear mind, over what turned out to be a good strategy, how to iterate on that and praise the team for the job done.
</code></pre>
I suspect you can probably predict how effective a scrum style team is based on how effective the retrospective is.
Interesting, I guess this may have resurfaced here because a German translation was posted today, <a href="https://www.golem.de/news/arbeit-scrum-nervt-2401-180930.html" rel="nofollow">https://www.golem.de/news/arbeit-scrum-nervt-2401-180930.htm...</a> ?
I retired two years ago, but finally made peace with SCRUM in my final years by eliminating standing team meetings for retrospective / review / backlog.<p>Backlog - groom during long/medium term planning. Not everyone needs to be in the room for this, just leads. Use 1:1s to triangulate on issues that we're ignoring or under-resourcing.<p>Retro - on an infrastructure team, retros are already built into the incident management process.<p>Sprint review - start sprint planning by asking how'd the last sprint go. Did anything gunk up the works? Are there any promises we didn't keep? The rotating on-call and triage (secondary on-call) would fill us in on any active fires, or less us know if we can/should hand ownership of an issue to another team.
I had an interview where communicated some critics of scrum, some that i agreed with experience and collected through posts about it etc, and was dismissed even without receiving no counterargument during the interview because they were looking some strict believers of scrum, it was an interview with a couple of non tech managers, i guess that’s the issue, scrum is a shallow version of XP who serves non tech middle managers, there is no criticism about it that can be useful to change anything, tech people already knows, but until companies keep useless middle managers around, the tech people just have to accept it
> Oh, and say goodbye to pair-programming and collaboration, everyone is too focused earning those juicy story points.<p>ugh yes this was my biggest gripe when my team used scrum at my last job. Collaboration was thrown out the window.
I get really tired of seeing this once a month. OP had a bad experience with Scrum. Lots of people have. I've seen it be incredibly effective. I generally prefer Kanban, the principles are mostly the same. In my experience, the effectiveness really boils down to team maturity. The crux of the process revolves around writing user stories that define an increment of user value and executing on each story past all defined quality gates in strict priority order. It does not and really cannot make a team actually operate faster, only deliver increments with observable velocity. In practice, most teams will end up going slower, but delivering more accurately and reducing rework or unmet expectations.<p>At best, Scrum or Kanban with a tool like JIRA are really there to establish a shared vernacular and facilitate clear communication and manage expectations. And if done properly, they are incredibly effective.<p>My biggest problem with Scrum in particular is really the word "Sprint". It implies we're all rushing to a goal and that's really never the cast. Literally just rename your 2-week iteration as a "Slog" and change nothing else and see how people react.<p>Where the process typically breaks down is being unclear about priorities, working on too many things at once, skipping quality gates, defining tasks instead of features or trying to estimate an entire product backlog at once and setting a deadline that is utterly doomed to fail.
I've never worked in a supremely functional scrum org, but as others have stated it may only really work if the whole org is on board.
In places that I've worked there has always been a fundamental tension between how developers/makers work best ("leave me alone! It'll be done when it's done!") and how the rest of the world expects things to happen ("I need to know if it's going to be next week or next year"). I imagine organizations that can take the "it'll be done when it's done" approach are very much the exception.<p>So in the usual case that means that developers have to "waste" a not insubstantial amount of time making plans (that may largely be thrown away) and estimates (that might be off by an order of magnitude), and then course-correct over time (trading off time, scope, and quality) as they learn things while doing the project.<p>The other thing I've found over the course of the last ~25 years is that any kind of system (waterfall, scrum, GTD) is an abstraction that inevitably leaks. It's not somehow provably correct that if you follow a system perfectly that nothing will fall through the cracks. You can either admit that any model of the world is necessarily simplified, or you can keep retroactively adjusting your definitions of things in the model and at some point end up like a game developer treating a subway train as a piece of clothing, or arguing about whether a particular body of water is a "pond" or a "lake".
Scrum was my first real experience where I saw marketing people and consultants take something beautiful and just smash it into the ground and turn it into a parasitic money and time suck, a twisted parody of what it was meant to be. It made me more cynical but perhaps better prepared when things like that happened later in my career, like DevOps.
Bad management will turn any methodology into a bad experience. I also think scrum, and especially its implementations that I have been subjected to, could use improvement.<p>I dislike the artificial time-constraints of the sprint, and the PI in SAFe. In my world, I wouldn't concern engineers with deadlines, but rather I'd have them work continuously, like in kanban. I think it eliminates overhead, and if velocity, and other such metrics are desired, management can conjure numbers out of thin air, just as they always did.<p>Without sprints, there would be no need for planning either, but I'd hold refinement meetings regularly. What I'd do is break down the work into tasks and create a dependency structure, like the Critical Path Method in project management.<p>I'd estimate in person-days, and that person would be a hypothetical normal teammate. Like, the best guy would do it in half that time, and a junior would take twice, even with hand-holding.
After working in teams using Scrum and fully unstructured “trust the engineer”, I agree there are certain parts of Scrum that feel like dead weight / overkill.<p>Daily standup can feel productive when you are doing it, but I think you have to be a very small and nimble team with high density of juniors for it to be appropriate to meet that frequency. With a mostly-senior team folks just reach out when needed to unblock each other, and proactively broadcast async updates. Tooling to encourage this “ambient information” is I think under-invested. Takes a lot of discipline in Slack to prevent channels from devolving into noisy discussions.<p>I think a lot of teams think they need more predictability than they actually do, and sizing/points are overrated. Again this is contextual; in some projects you really do need to forecast a Q/H roadmap for customers. But if you are shipping every week or two, sizing barely matters as you can just Kanban it and keep picking the most important item to work on each sprint.<p>I think retro is mostly time wasted. You can fill an hour per two weeks with it but I’m not convinced it’s the best use of that time when you are moving fast. Async tools that can measure a pulse survey & flag common themes that are bright red/green is probably a better place to be.<p>I think some sort of stakeholder review on a regular cadence is great, and sadly is the bit that is taken least seriously in Scrum IME. When stakeholders (in small companies this means CEO and the rest of leadership!) take this seriously you get a great feedback loop. Too often I see folks skipping as they have “real work” to do. I think this also points to lessons for the engineers; really need to keep things snappy and customer-focused. Have your tech-facing demos another time. Or, even better, record your product facing demos and post them, so you can get feedback async. If the CEO comments regularly on these it can still provide that feedback that the meeting / demo is valued and important.
It would be interesting to attempt an analogy between software development processes and parallel computations. Let's analyze which job tasks are atomic, parallelized, depend on read or write operations with common shared data, and the costs associated with setting up new job tasks.<p>It is likely that we would discover that the majority of programming tasks are not parallelized and are costly to set up, especially if frequently switched between job workers. This is because programmers need to delve into the problem domain, the existing code base, the API, and various other factors before commencing an actual task implementation.<p>Assuming that task workers are fully fault-tolerant ("no bus factor"), the optimal design would involve dividing the code base into loosely coupled modules, possibly organized into a hierarchy, with each module's management entrusted to a single worker (programmer). To mitigate the fault factor, we might have substitutional task workers dedicated to critical modules.<p>Regarding other task types, such as manual testing, these are usually less expensive to set up, do not require write access to the code base, and can be efficiently implemented by worker groups not bound to specific code modules.<p>This approach should be scalable and could effectively contribute to product quality. However, it necessitates the business being run and owned by programmers, and more crucially, earning revenue directly from end users who value product quality—a major success factor for the business.<p>There are successful examples of businesses following this model, including many indie game development studios and some software product businesses. The scarcity of such examples in the broader business community is attributed to the fact that the majority of funds today come from large corporations and ultimately from governments. This system undermines the free market, impacting everything in software development, from product quality to development methodologies.
Works great for us. Things that usually indicate that you're not working with agility: spending more than 10% of your time on process/meetings, have professional project managers 100% dedicated to processes, team unaware of mid and long term direction, team talks about scrum stuff instead of what they're working on, ...<p>I've learned to avoid any shop that has professional project managers doing what they term "the agile processes" instead of the team itself, as those shops are generally buzzword compliant cargo cult ghettos.<p>I get the "no true scrum master" thing. It's real. However, I was trained by Ken Schwaber, and I'd say most shops who say they're doing scrum are not doing anything that actually resembles that training, other than the lingo.
Scrum/Agile as it's practiced was invented in large part at consulting companies who were dealing with toxic clients. If you need a methodology to defensively manage a bad client then it's a pretty good cool.<p>As for the other parts there's a general problem of people applying a tool they don't understand. The benefit of a daily scrum meeting is not to remove blockers. If you think that's the point of the meeting then you've failed already. It's to build team camaraderie through repeated casual interactions. If you think it's there to remove blockers than you're tempted to try to eliminate those casual interactions instead of facilitate them and you end up doing the opposite - you erode team culture.
I wonder how much of the suckiness is because of scrum, or because of the company that's adopting scrum's existing culture.<p>I'm not defending some of the ridiculousness of these ceremonies etc. but they're really a symptom of the problem.
You forgot adding lengthy descriptions and constant updates to each ticket. The person who pushes the most tickets and with most words per ticket gets promoted. You're better off spending time optimizing JIRA than doing actual work.
37signals / Shape Up?<p>For anyone who's read 37signals development methodology (in Shape Up), how does it compare to other common dev methods?<p><a href="https://basecamp.com/shapeup" rel="nofollow">https://basecamp.com/shapeup</a>
> Scrum is broken<p>That section describes various scenarios how scrum can be misapplied — starting from a team that doesn't find value in it ("Does your team still attend the stand-up meeting [without PO and SM in the office]? I doubt it."), and ending with various organizational dysfunctions (bosses, hierarchy, confusion, estimation, someone writing useless tickets, people not collaborating, and so on).<p>Why are those organizational dysfunctions Scrum's fault? Why is the title of the article "Scrum sucks"? Not clueless bosses suck, or orgs that are too firmly set in their ways suck?
I sometimes wonder if agile/scrum’s inefficiency stings so much because of its disconnect with the end product. Or, you end up being involved in a bunch of bureaucratic work as a programmer, even though you can see the codebase’s flaws in plain sight. You can view a peer’s backlog, but also see their concrete work on GitHub. The map truly isn’t the territory.<p>I haven’t really been wowed at all by LLMs over the past cycle, personally. That said, I wonder if it could truly shine as a tool that could conversationally explain a codebase to management to empower staff and cut down the red tape.
Two thoughts:<p>> "Way of work should be defined at a team level by its people, not by the company."<p>OP delivers that like a surprise, but isn't that the single core defining tenet of Agile? I thought it was.<p>> Sprint Planning — as simple as it seems, a long session (up to 4 hours)..<p>My big insight is, painful sprint planning is a result of painful deploys. Once you accomplish real CICD, you can just dispense with sprints and sprint planning entirely.<p>I'm not sure if that's something most people would agree with or not so I won't belabor it unless someone argues, but I can go on at length about that...
I feel like I have to add insult to injury: the extra people who work full time to manage the scrum overhead earn more than the average dev - at least in the EU. Devs over here are criminally underpaid.
I'm a scientist that through a lateral career move has ended up doing something akin to software development. This means for the last few years I have attended daily scrum meetings for the project I'm working on.<p>Perhaps it's my inexperience with software development, or maybe it's specific to the company I work for, or the people on my team, but but I find the entire process a gigantic waste of time and mental energy. How does everyone else deal with this? Is there a better way that will help me not dread attending my standup?
Scrum is not the problem.
I worked with waterfall, Scrum, Extreme Go Horse, etc.<p>All the methodologies I was forced to work on basically didn't work, all the methodologies are just a play of “business theater”.<p>Someone with the power to decide decides to use anything fashionable, now it's Scrum, but it used to be something else. Whoever does well in this theater isn't a good employee, it's whoever does best in the current play.<p>My defense in the face of all this nonsense is to be professional, because the company will never be. I start work on time, do my work, leave on time. I help in emergencies, but if emergencies become the norm, I change sectors, hours or companies.<p>I try to avoid meetings. I say “I’m working on something important.” Always works.<p>I never allow anyone to disrespect me (I know a company with “physical punishments”). If that happens, I'll change companies.<p>Again, Scrum is not the problem. The next fantastic methodology will fail. It's just a Play, and you need to be an actor, or move to a theater whose play is in pre-production...and enjoy it until the play starts to be performed.
I wonder how Lockheed used to manage their successful projects like U2, which was delivered ahead of schedule and under budget. Joel Spolsky used to say that FogCreeks didn't need much project management because pretty much all the dependencies can be mocked out, so everyone would make progress in parallel. If someone needs to know where the project is, well, there will be plenty of offline channels for that. Daily meetup is silly.
Scrum is really useful for exploration and innovation work, things that may not even involve programming.<p>In general I think sticking to Scrum for Software Engineering is overkill, or maybe the 2 week sprints are too short.<p>I've had much happier engineers and product owners when working in Kanban, a steady stream of work with as few meetings as you can manage is much better for SE work, it is harder to get it up and running though, and can take some time to bed in.
Any eng project management practice that has its own name sucks. Same goes for programming paradigms. I like my team to be free of this pretentious stuff.
Developer-only "agile" never works, no point in ranting about the details. Either your company is able and willing to develop a product incrementally, or they’re not.<p>Agile is not going to help you better track a project that the rest of the company treats as waterfall, fixed date, fixed scope shit.<p>99% of the ranting about Scrum or whatever is about typical shit project management, that they've bolted agilish lingo to.
I believe that the most valuable aspect of Scrum is the retrospectives. These are recurring meetings where we assess what has been effective and what hasn’t. If the retrospectives consistently focus on the same issues, such as ongoing complaints about test environments, this also indicates a fundamental flaw in the overall architecture.
The only part of scrum I like is daily standups, I get an overview and mostly sync up with what the team is doing.<p>The other ceremonies (like sprint planning/review and retro I find mostly a waste of time and don't go unless I am forced to).<p>JIRA tickets, I can create them if needed but I can pump out way more code if I don't need to waste time on those :D
The best is when you, as a dev, get to have a struggle session with project planners because "your group's estimates are consistently half of the required points to complete the project." But, for some reason "then just double our consistent estimates for your purposes" is treated as a joke.
Correct me if I’m wrong, but Sprints only make sense for teams with more than, say, 4 engineers.<p>Because a Sprint is fundamentally about estimating bandwidth. You look at the old Sprints and are able to average out some kind of true estimate of capability, right?<p>But if you have a smaller team, everyone basically already knows what your bandwidth is.
most of the discussions on SCRUM come from people running scrum or commenting on scrum as employees.<p>scrum exists because companies are paying salaries for engineers and dont want them sort of milling about doing random sh*t all day in an aimless fashion.<p>my experience is most engineers are incredibly passive and just want a paycheck and are barely productive.<p>except management is often completely clueless / non-technical / not interested in technical topics / view technical stuff as being "beneath them" sort of like taking out the garbage or cleaning the windows.<p>solution is to create a pseudo-science pretend self-governed democracy.<p>let the engineers manage themselves! genius!<p>It is a zero-interest rate management cop-out for badly led highly mediocre companies with a lot of dead weight.<p>make the over-hired engineers engage in a lot of activity so they seem to be making progress.<p>scrum needs to be looked at in context of past economic conditions and the structure of the market. lots and lots and lots of engineers work in these environments of non-technical management who just want to see "activity that looks like progress" and dont have any intention of getting more engaged or involved than that.<p>compare to startups where the ceo is often an engineer and doing the work themselves<p>I think scrum is going to die a horribl death in a high interest rate environment with AI.<p>the mediocre overpaid middle in tech is going to get a very hard re-evaluation<p>so is mediocre middle management<p>all of that needs to go away<p>mediocre middle management and scrum and over-hired, bloated organizations are all phenomenon of low-interest rates.<p>in a tight environment, I hope that talent is what matters and all that gets the chop.<p>I think scrum will be categorized with "sitting in cubicles" as a productivity method in the near future.
The real culprit is coming up with a bunch of metrics that fail to model the actual performance of people. It instead incentivises going after the metrics. The type of orgs likely to metric-ify just happen to overlap a lot with the people that prefer scrum or agile or whatever.
If scrum sucks, suggest better. Waterfall is not better for software development. Author gives examples from bad management practices, work load, overloaded job queue and points all the problems to scrum but scrum has nothing to do with these problems.
I have my own (and many) criticisms of Scrum, but this article is so poorly written that I cannot say whether the author's views align with my own. I couldn't make it beyond the first few paragraphs.
SAFe is a cancer. In my experience scrum is done absolutely wrong, every time, and teams should be able to decide the most effective way to manage themselves, not top-down directives and one-size-fits-all garbage.
Holy shit people - scrum does not work without a fundamental understanding of the theory of constraints.<p>If you're burndown chart isn't burning down, something is blocking your team. A manager finds out what is blocking the team and works on it.<p>If your team has a bunch of tickets in process- then your WIP is high - that's bad. Someone taking on more tickets to just get to work should be pulling the equivalent of an Andon cord.<p>Tasks should not have estimates - tasks should roughly have the same time to complete - a task that takes 10 days is not a single task.<p>A sprint meeting should only assign new tickets based off the previous rate of completion. Adding more WIP only fucks things up more than they are.<p>Management sees the rate of completion of features - and then calculates the time to project completion in sprints.<p>IF YOU HAVE A DEADLINE and you're missing it...<p>- cut back on features
- or find out what's blocking your team.<p>Developers need to be told to emphasize and raise up items that are blocking them.<p>In any value stream - there is only one current constraint. The rest of the production process needs to be subordinated to the constraint.
Is it pull request reviews? Is it the QA process? Is it ambiguous tickets? Are questions not getting answered?
Boy, is this right on point!<p>> I really believe there is one, but I have never seen a single engineer happy about their company Scrum implementation.<p>Yeah, I think that's an example of good idea but too easy to badly implement. With cargo cult and all that, people try to take it ready-made and don't event try to understand why things are done a certain way. Result is unavoidable garbage. I've never seen a good implementation as well<p>> One is on sick leave and the other has a well-deserved PTO or holiday.
Does your team still attend the stand-up meeting?<p>In my manager years, I've been using this as a metric. If I'm not there and meetings don't happen, it's probably a sign that the meeting isn't useful.<p>> Sidenote: I always disliked this religious term used to define these kind of meetings, but ok.<p>I've always read that as sarcasm though, precisely because ceremonies and masses happen religiously without questioning whether they should exist
I am using Scrum since 2006 and have worked with 30+ Teams so far. I don´t care for Scrum or any other framework, i only care about creating great organisations that empower teams to generate value.<p>In 2022 + 2023 i conducted about > 220 insight interviews with Scrum Masters, Agile Coaches and Product Owners for a product i am currently developing.<p>There was a VERY VERY clear pattern:<p>1. almost all teams where using Scrum or Kanban or some mixture of it
2. less then 1% of teams actually had a product vision, product goals or a sprint goals
3. nobody was actually doing "inspect&adapt"<p>My assumption #1: it is not the framework or the people<i>, the failure is within the system.<p>My assumption #2: every company is different, a company is a complex system and many many factors contribute to the outcomes, nothing is clearly black or white. Any framework needs to be adopted with the core concepts in place; with Scrum the core concepts are usually not implemented and therefore Scrum fails.<p>(</i>) Site note: training standards of people seems to be very low; a lot of Sscrum Masters and even "Agile Coaches" cannot explain even the basic concepts of Scrum and Kanban.<p>Example: What is the purpose of Daily Standup? How can you assess the quality of Standup? How can you improve the Standup?<p>So what is wrong with the system?
- company does not have a product strategy, only tasks like "develop feature X"
- company does not have strategy management processes in place
- there is NO collection of meaningful data regarding process health and performance and specially Scrum Master work against creating transparency (out of fear)<p>What is the solution? Implementation of a framework without robust performance monitoring is pointless and failure is certain.<p>The issue? It seems that Scrum Masters push the most against performance monitoring out of fear to become transparent. Also, being transparent in an company with low (psychological) safety might be professional suicide.<p>People forget that Scrum was developed by observing successful (senior) teams, but if they don´t understand how value and waste it generated it is meaningless to follow any framework.<p>Example: Having a lot of meetings does not generate the waste, it is only the symptom. The root causes of many meetings are inefficient management and communication structures. In order to avoid the waste you don´t need to remove the meetings, but first resolve the underlaying issue(s) and then the need for the meetings disappear. Removing the wasteful meetings might actually create more waste/harm, as the company might perform even more badly afterwards.<p>So yes, individual developers might get more working hours but generate less value over time. The purpose is not to maximize the working hours of developers, but to maximize the value generated by the team. The assumption that "more development hours = more value generated" assumes that alignment with product goals, teamwork and cross-functional collaboration is in place.
TL;DR<p>1. Clickbait heading<p>2. Lots of strawman arguments<p>3. Punchline: Don't be stupid (implicitly assumed you are). Do it my way instead!<p>4. Success!
Scrum sucks and much like HR it’s a made up field to get buddies employed for literally no ones benefit except their own department. Stand ups are never useful. Never. Not once in the history of the human race has an engineer ever though man I’m so glad I read out the state of a jira ticket to someone who doesn’t even know how to push a git commit.
Bullshit clickbait is bullshit clickbait.<p>Scrum doesn't inherently suck. Scrum can work if you do it right. It won't if you don't.<p>Just leaving it up to the individual team leads to the same result. If the team sucks at managing their work, the team will suck at managing their work. It doesn't matter what you follow if you suck at it.<p>This isn't as catchy and feel-good as the bullshit clickbait that reinforces what you want to believe (that the process is the problem, not you or your team). But it's accurate.
While some of the points in this post are valid most of this is just copy-paste non-sense stated in multiple articles. Of course "Scrum" cannot fix your problems if you have bad engineers who are happy to just "close" tickets or you have an organization where you do not know where to ask "who is knowledable about this business requirement". Scrum is a software delivery methodology which is ok in itself, it is not a silver bullet which will enable you to write great software which meets specification and runs for years without bugs, those things are completely tangential and require a specific set of skills.