Hacker News new | past | comments | ask | show | jobs | submit login
I don’t believe in sprints (robinrendle.com)
337 points by threeme3 on Oct 5, 2022 | hide | past | favorite | 450 comments



This is nothing but a bad strawman from start to finish.

Sprints are not made to help organize things, they're a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability.

This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and that is the tradeoff. Plus: people actually seldomly take the optimum routes in the first place.

Nobody has to like it, this is probably not the best method and maybe it's not even good. But the author misses the point completely.


It's all about how everything is implemented. I've worked in places where sprints were hard deadlines and there was no acceptable reason for missing said deadlines. We worked 12-15 hour days, including working weekends to try and meet our release schedules.

Run into a blocker? Too bad, should have seen it coming during our scrum meetings and follow-up refinements.

We engineers had two business analysts, a scrum master, and two managers that resided "above" us in rank all working to keep the "flow" of the sprints alive to help ensure we meet our deadlines.

It was the most stressful tech job/environment I've ever been part of and everything was micro-managed by said 5 people to the point that they were blockers to our progress - scheduling multiple meetings everyday that would easily consume 3-4 hours.

Our backlog would grow everyday as everyone scrambled to finish tasks and our architecture was a patch-work of systems that only one person truly understood because he had been with the company since it's inception.

I was hired as a senior engineer along with three other mid-level engineers - all three quit within four months. I left after six.

Sprints/agile/scrums are generally a good thing IF and ONLY IF you have a capable manager/scrum master leading and organizing the team who truly understands time management and finnicky nature of software development. Otherwise, it quickly falls off the rails and leads to churn and burn.


> Run into a blocker? Too bad, should have seen it coming during our scrum meetings and follow-up refinements.

One of the things that usually happen when they push and push and push for some feature to get rolled out in the next quarter is that it often turns out to be a gigantic flop. Engineers are forced to spend hours they can't get back at the whim of management for something that was a complete and utter failure. I could imagine few things more demoralizing than this.

Agile is really meant to be about self organizing teams that take ownership of their own work and deliveries. The scrum master and product owner are just there to facilitate that.

When a team hits a blocker on a tight schedule -- particularly across third party teams, it's up to the management to figure out a solution -- even if it means gasp delaying the release by one sprint.


I'm currently studying for the PMP exam, which has made me realize just how far the promise of Agile is from how most people implement it.


This sounds like an organizational failure rather than sprint/agile/scrum. It works beautifully when lead in/by tech teams.


> It works beautifully when lead in/by tech teams.

What software development methodology does not work well under these circumstances?


Fair point. Too much managerial bandwidth is a red flag in a tech org.


I love how they pay people by the hour to massively waste that time with this kind of Peter's Principle nonsense. Like that's gotta be a major bleed on the bottom line at every company which acts like this.


Jaded conspiracy theory:

I believe some people within certain organizations are aware of the waste at some point or another, but it's the price said certain organizations chooses to pay in order to implement a great micromanagement system.


And because you have sprints, you create lots and lots of small tasks, then focus on them, and then team members forget the "big picture" of how everything should fit together in the end (if they were ever aware of it). And when all of those small tasks are done, you notice that the sum of all those parts is not what you set out to build initially, and you need more time to shape it into something that resembles what you wanted to have.

To avoid this scenario, it takes really dedicated project managers, product owners and lead developers, and not everyone has those...


What would be the alternative without sprints?

What specifically about not using sprints would help the team if they lack good planners and people capable of seeing the big picture?

Isn't such a team screwed regardless of how they allot work?


A more fluid "here's what we're prioritizing next" approach. is that 'kanban'? (I think so?)

Worked on a small group (2-3 people?) and .. 'agile-2-week-sprint-estimate-tickets-with-points' wasn't working well. This is 'startup/mvp' area, and we migrated to just a simpler task board. Owner moves tickets up and down in a "to do" queue, and someone (usually me) takes current 'to do' tickets, and does them and releases. The '2 week' time box wasn't really helping anything - we can 'release' multiple times per week.

For larger teams working on established product, there's more value to the '2-week-sprint-give-points-to-tickets' approach that's more popular. Worked in a group a few years ago like that, and... while there were some issues, they weren't specific to sprints or agile, more just growing pains of that company.


Kanban is also fine, for the reasons you mentioned. I wonder if TFA favors this methodology?

Do note Kanban can devolve into "do everything, all at once, and we need right now. Stop doing what you're doing, do this thing instead!". It happened to my team, and we had to ditch it because the stakeholders weren't onboard with no fixed cadence of deliveries.


> "do everything, all at once, and we need right now. Stop doing what you're doing, do this thing instead!"

Hum... Since the single main stated goal of kanban is to minimize WIP, it's safe to say that this is not kanban.

Of course, it won't stop bad managers from implementing it. But nothing will stop bad managers from implementing it anyway. Anything can devolve into that, trying to implement something different won't save you.


> it's safe to say that this is not kanban

But that's the problem with agile.

Nobody can or wants to pin it down. When it fails, "you are not doing it properly". The stated goals are iterations, early feedback, people over processes... except when they aren't.


Hum, no. If you go calling some infinite WIP generating process by the name that has as the one most important principle "no matter what you do, keep WIP down", it's you that are bastardizing the language.


> Hum, no

Um, yes.

I'm sorry, but the "Agile works, it's just that you are doing it wrong" line of argument is weak and unconvincing. The theory of a methodology means little when there is no buy-in from stakeholders, as is often the case. They reinterpret it to mean whatever they want it to mean. If you haven't struck this wall, then congrats! Most of us in software have to deal with it, though.


> WIP

Do you mind defining this?


Work In Progress, I think they're referring to.


Yep, work in progress.


"Work in Progress".

"Strict" Kanban is about minimizing in flight stuff that you don't have bandwidth for. (Strict "traffic limits" based on team size in any specific column.)


Thank you for the clarification, but I am afraid you lost me at this part:

> "Strict" Kanban is about minimizing in flight stuff that you don't have bandwidth for. (Strict "traffic limits" based on team size in any specific column.)

What is "in flight stuff" and "traffic limits?" Are you saying strict Kanban minimizes the number of tasks that are in progress in order to prevent overloading the team i.e., there is an upper limit set to curtail the amount of simultaneous tasks?


If you're interested learning more about Kanban, I thing Eric Brechner does a great job of describing it - https://www.youtube.com/watch?v=CD0y-aU1sXo


Right, Kanban comes from "just in time" factory needs where you've got scarce supplies that feed scarce resources (particular stations). It started on physical index cards representing "parts" that needed to flow through stations. Each station would pull cards representing the parts they need, but weren't allowed to pull more than they could work with at a time. When "parts" run out new ones need to be ordered. Putting it on a central board was all about finding: what parts are needed where, visualizing which ones run out first, and visualizing where the bottlenecks are. (A lot the parts are stuck waiting on a particular station to pull them and maybe that station is blocked for some reason.) At any point if there is too much in any single column "something is wrong". You are missing a column or work isn't flowing right.

Not all the factory needs apply to Software Kanban, but it's still a useful analogy in various ways. Plus not all software for working with Kanban style boards is great at some of things "Physical Kanban" is better at. (Some of the best times I've worked in Kanban board software was eschewed altogether and it was done in index cards on a whiteboard. There is something to be said about physically moving cards around that the software boards don't quite capture.) While the "raw parts" in Software Kanban are generally considered to "backlog items" (features/stories) and are plentiful rather than scarce (and this is one place where the analogy to factory operations kind of breaks down a little bit), in "strict" Kanban each column or "station" is expected to have somewhat strict limits to keep from overloading the team. Only so many tasks in progress in development at once (often capped at one per developer), only so many tasks in progress in QA testing at once (often capped at one per QA person), etc. You can visualize bottlenecks: if there are too many tasks in Development and not enough for QA, maybe the stories are too big for a steady cadence (Development is your bottleneck); if there are too many tasks in QA instead maybe QA is your bottleneck and you need more QA resources. If you need to scroll a column there's probably a bottleneck to fix (or a column/"station" you are missing).

Setting bandwidth limits, finding your "stations" in your column designs to help find and visualize your bottlenecks, is a lot of the art of Kanban. That and Kanban's focus on "pull" rather than "push" are big differences between Kanban done right and Scrum.


Yes, WIP (work on progress) limits are a key feature of Kanban.


>stakeholders weren't onboard with no fixed cadence of deliveries.

Can the fixed cadence of deliveries be weekly or semi weekly status update of cards on the board? (Note: the view of the board should always be available to stakeholders, they may need to hold their breath for a week until a more in-depth status meeting of current cards on the board...)


Yep.

Also I've never seen a Kanban operation deliver everything to Production as soon as it hits a "Done" column and there's no reason not to "time gate" (once every fortnite, just like Sprints are supposed to be, for instance) a Production column "pull".

I think that's easily missed in Kanban versus Scrum discussions: every Kanban column is supposed to be "pull" rather than "push". Production "pulls" finished UAT stories when it is ready (which maybe is a biweekly schedule that keeps ops happy and gives marketing time to prepare materials, etc). (I also think that's why a lot of micro-managers dislike Kanban versus Scrum, because they want to "push" everything and dislike people making their own "pull" judgments based on their current bandwidth and ability.) The failure case of "Production pulls finished work" is that Production sometimes wants to cherry-pick finished work ("I want these three but not this fourth one") after they've been already merged for UAT testing. I've not seen a good Kanban software that visualizes that "state change" of stacking cards together as they become bundled together/releasable units.


Ah yes! I forgot about the "pull" mechanism of kanban. This also helps identity bottlenecks and discover where more "resources" (::barf::) are needed or where re-allocation of "resources" should occur.

I need to reread the following books:

Kanban: Successful Evolutionary Change for Your Technology Business

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency

The Goal: A Process of Ongoing Improvement.

The Deadline: A Novel About Project Management


But again, sprints can also devolve into that. Structure becomes valueless when people subvert it; there's nothing particular about kanban which makes it more susceptible to this than scrum.


Totally agreed.

From the outside, though, kanban looks more like "no methodology". If people who aren't on board look at both 2-week sprints and kanban, kanban looks a lot closer to "we can ask you to do whatever, whenever". It's wrong, of course, but in my experience they understand better that it's discouraged to insert new requirements in the middle of a sprint.

People will subvert whatever they want, though. Probably the biggest shortcoming with agile methodologies: "you are not doing it right" -- yeah, well, real people in the real world never do it right.


This is what we've been using for some years now, despite the general Scrum-y pressure in the organization I work in. (It is not a mandate, note we get no blowback for what we do as it is under our control, I'm just saying most of the rest of the teams definitely do something more Scrum-y.)

I am a big believer in "true agile", since "Agile" (note capital letter) has become heavily corrupted. "True agile" can really be summed up as "try some different things, keep what works for you". My team has a large number of independent projects, more than one per person. Because of that we tend to have one person working on a given project at a time, as that is a cheap way to avoid coordination overhead if you are able to get away with it.

What we found for "sprints" is that we couldn't plan anything with them, because the variance in how much time we were actually going to have to work on a project was too high. We might have the full two weeks to work on what we said we were going to work on. We might have a fire on another system that pulled that person away for literally 3/4ths of that "sprint". We might have an emergency feature request that could do the same thing. We found this variance to dominate the rest of our time planning, which resulted in our "sprint planning" being a bad joke. Nor could we just "git gud" at sprint planning, because the variance in the amount of time we had to spend on it was far, far too pathological.

I do not present this as evidence that "Sprints" are bad for everyone, only that there are cases where they really don't based on my experience as well. This has been my personal working mode for most of the last 10 years, and they've never worked for me. We've switched to a much more Kanban style of planning, which gives us the flexibility to deal with our issues without wrecking all our plans. I personally take the brunt of a lot of the highest frequency switching in our team, and my primary goal is that on a given day, I am working on one project, with a secondary goal of trying to keep it chunked up by week. That latter often fails, but I definitely try to avoid switching projects mid-day. (Which also fails, sometimes due to fires, but I've noticeably improved on this metric in the past couple of years.)

We've tried at least twice to switch to a more Sprint-y method of organization to better match the rest of the organization, but failed both times. I'm fine with the attempt, I'm just very glad we've also retained the flexibility to admit it was a failure, and that it isn't mandated from above that we must do the Sprint approach.

The vast bulk of teams in the rest of the organization I work in does have 3-7 person teams all working on one particular system, and while nobody ever escapes from the possibility of fires, they have a lower variance on the impact on that for all sorts of reasons. (Most notable being that 3/4ths of a week for one person out of 3-7 is a lower impact than 3/4ths of a week out of what was effectively zero people, which means it was actively drawing against what was nominally another project's time. That's a really big difference.) Sprints work much better for them. I'm sure they fail them sometimes but they generally seem to work for them.


> "True agile" can really be summed up as "try some different things, keep what works for you".

I would argue that is more common sense than "True Agile." ;)

However, I think you hit the nail on the head with Sprints. I understand why organizations want estimates, planning, etc.. However, if I could predict the future, I would be working on Wall Street and not doing Agile. In my jaded experience, few things ever go to plan. I do think one should still plan, but I do not think plans should be immutable nor estimates turned into deadlines.

Sprints, to me, seem to be the antithesis of Agile. I find sprints turn Agile into a series of mini-Waterfalls.


How bout, plan enough then just build the thing until we agree its usable and correct. What the hell is the point of the short time framed boundaries? I'm not a fucking horse I don't need cadence OR blinders.


Plan enough is sometimes 3 months of work. "Here's all the stuff we need to do to create a MVP." After 3 months, its not done and you are trying to do the last 90% on a task you thought was already 90% done. The hard things were put off till the end and now the optimistic "it should be done in 3 months" is getting up to directors that you don't have anything that runs at all.

The sprint forces a "this is what we're doing in these 2 weeks" with a deliverable at the end. If, at the end of the first sprint, you only got half the things done because of challenges, ok that's what it is. Next sprint you pick up only half as much work and you get that done.

Now, the PM can look at all the work that needs to be done and the rate of work that needs to be done and the amount of work and realizes that instead of the initial "yea, we can do this MVP in 3 months" that you're closer to having it out in 8 months if everything remains the same rate.

That is something actionable for project management to say "nope, can't have the MVP in 3 months with this scope" after only 4 weeks and the project can get canceled earlier.

Sprints try to make management realize overly optimistic estimates and timelines and either have things get adjusted (staff, scope, or time) or have it canceled sooner. Having a sprint based project canceled after 4 weeks rather than embarrassed and dragging out at 12 weeks is good for the organization to not spend resources on things that won't get done in the required timeframe.

The goal of the short framed boundaries is to force this decision sooner.


Hot take: If you take three months planning, either it's incredibly complex or you're holding it wrong. If your directors aren't able to recognize either case well before the 3 months mark, get yourself new directors. (Source: I am one of those pointy-haired monsters. The sinking feeling in your gut starts at the end of month one, the latest)

And the third paragraph kind of lays bare the problem with sprints: The PM can only look at all the work that needs to be done if, well, there was a discovery phase to list all the work that needs to be done. That discovery looks suspiciously like planning.

That's why agile focuses on continuous delivery of value. It's excellent for projects where it's hard to estimate the full scope, but there are many intermediate targets that are valuable to the customer. You go along until enough value is delivered, and then move on. Not all projects work like that. Some things only generate any value at the end of a long slog. Some things can be delivered incrementally but require a predictable end date. (Hello, Black Friday!)

And so, you get to adopt methodology to the problem at hand. Sometimes, you really need to spend the planning up front. Sometimes it's enough to sketch it out on a napkin. Sometimes you can do things sprint-by-sprint. Sometimes, you have larger checkpoints and sprints in between. The idea that any single methodology works for every problem is an idea favored by the consulting industry, but not a reality. And it predates agile, by a lot - I've been a process consulting victim way back in the early 80s. (And the mass of miracle methodologies directly led to "No Silver Bullet")


Exactly this. That is why the Agile Manifesto said to favor "Individuals and interactions over processes and tools". The problem is that approach only works when you have a team of experts with clear goals and enough space to address them. It doesn't necessarily lend itself to being quantifiable or standardized across multiple teams (depending on the problem), so the bean counters and middle managers get nervous. This is an environment ripe for agile consultants to swoop in with the siren song of the silver bullet process du jour.


I believe you misread my "Plan enough is sometimes 3 months of work." which was referring to the wording of the parent comment "How bout, plan enough then just build the thing until we agree its usable and correct."

Plan it out - be it a napkin or post it notes or whatever. That isn't three months of planning.

My point is one of that if you do a "just then just build the thing until we agree its usable and correct" often doesn't get a first milestone until a month or two down the road.

Sprints, being frequent, are there to help people identify issues with planning sooner so that issues with timelines earlier.

Often the "then just build the thing" gets down a month and the customer or business realizes that you're not building the right thing... or that you're doing a demo of what was built and get a "oh, I thought you'd be further along by now - there's no budget left for this work."

Sprints are designed to make projects that fall into those situations fail sooner. The fail fast part of agile is often a hard pill for people to swallow. https://www.agile-academy.com/en/agile-dictionary/fail-fast/ and https://www.ibm.com/garage/method/practices/culture/failing-...

Planning up front or as you go or how much isn't at issue with sprints. It's making sure that the project doesn't go too far off the intended goal or is too far behind what the budget allows for - and making those issues visible sooner so that the appropriate changes (less scope, more budget, more timeline, or just canceling it all together) can be done sooner in the process.


That can be seen as a large enough sprint that encompasses "the thing". If, like in the scenario I was describing, the team lacks good planners, lead devs and people with the "big picture", what you are describing is a recipe for disaster. What will happen is that at the end of the long stretch, they won't have achieved much or worse, built the wrong thing.

When done well, any iterative method is meant to provide early stakeholder feedback at each stage, provide some measure of progress, and have earlier warning signs that the wrong thing is being built.

> What the hell is the point of the short time framed boundaries?

It's easier to estimate a simpler and smaller thing than a larger and more complex thing. If you cannot achieve the small thing, you absolutely won't be able to do the larger one.


If developers x, y are developing UI and API endpoints and developer z is developing backend to a 10k+ page spec, 2 week sprints need not apply to developer z.


With sprints, the work of developer z would get broken up in more manageable chunks. The backend project would be very high risk otherwise.

More in general, coordinating between related but separate projects is a hard problem in software engineering, and it's orthogonal to whether you use sprints, kanban, waterfall or whatever methodology.


The work is to read and synthesize a 10k+ smorgasbord, how do you break that into 2 week sprints?


Agile means everything is up for being changed as makes the most sense, so in the (rare) event that you really have a task with 0 sensible deliverables you would indeed likely do longer sprints or no sprints. If that's not mutable because of some management mandate your not really doing Scrum, your doing "process inspired by Scrum" and saying you are doing Scrum.

That said your description of "read and synthesize a 10k+ smorgasbord" is nowhere near descriptive enough to answer your question or have any kind of estimate on how easy/hard this work is. It could be anything from I'll have it done in a couple hours this afternoon to a year long effort by multiple devs.

The best I can say is in the real world it's pretty rare to have a huge task that doesn't have sensible subtasks. In the case of ingesting a large mess of data like you are describing this could mean identifying and ingesting the data from system X, or processing event Y. These are steps the developers is going to go through anyway, and in many cases are even going to be deployable and useful on their own! Even if they aren't individually deployable they represent useful landmarks allowing for the understanding how work is progressing, readjusting estimates as necessary, and determining if the entire design needs to be reconsidered due to violated assumptions.


Bingo! It's nuanced and process shouldn't rule people. Unfortunately process often rules people and those shops will insist to their dying day that they are agile.


> The work is to read and synthesize a 10k+ smorgasbord, how do you break that into 2 week sprints?

I don't know, your problem statement doesn't allow me to formulate an answer. I suspect whatever the project, it can be split into a series of more manageable chunks.


It does not work if none of the chunks produces value for the customer, yet is necessary from engineering or bureaucratic point of view.

And sometimes you do hit a brick wall or bite something you cannot chew yet must digest.


Oh, to clarify: I don't believe in Scrum's "you must be able to release to the customer at the end of each iteration". That's a piece of fiction that I think almost nobody believes in anymore.

It still makes sense to have intermediate deliverables for internal milestones though.


Well yes it does require some dedicated PMs, owners and leads. If you are a smaller operation that does not have this, sprints might not be as beneficial. But if you are working for anything at scale as a developer, sprints aren't necessarily to track every hour of your day, it is to give you a structured path of things to do without having to know every detail about the bigger picture/compromises with product/prioritization. Also as a developer it gives you leverage because you were given certain tasks for the week so when someone comes along and tries to inject "high" priority item X, something else has to give.

I found before I was on the planning/lead side, it was hard when you did not have this structure. People would still shove in "small" tasks without a sprint structure and then months later it is hard to explain why a big project did not ship on time. So if done right and not abusively by oversubscribing devs, it is a great too for both sides.


> if they were ever aware of it

This is my biggest pet-peeve on my current project. I am a solo dev on my current project at work, and for some reason, we are still choosing to use agile/scrum with sprints and all that jazz (seriously, your guess as to why is good as mine).

Regardless, one of the more difficult issues I have encountered through out my current project is the usage of proper abstraction and avoiding redundency. I seriously have little idea of anything I build will for the project will ever be used again in a different part. Since, everything is given to me in sprints, I literally have no idea what is coming down the pipes.

Any feature I implement becomes an internal debate of how much abstraction is necessary vs. YAGNI.

I've since given up on even trying. Once the project is more or less finished, I'll properly just run back through it and then properly abstract, refactor, etc.. You know -- spend more time doing something twice than properly the first time, but whatever.


> Since, everything is given to me in sprints, I literally have no idea what is coming down the pipes.

So you literally don’t know what the end goal of your project is? I would say then definitely not a “self organised” team, or in a sense, you’re not in the team?


> So you literally don’t know what the end goal of your project is?

I know the end goal of the project in a general sense (like any other CRUD app), but I do not know what is takes to get to the end nor when the project will be considered finished. I'm also the solo dev, and I've been working on this for almost a year now. I'm so stressed and burned out because of this bastardized process (not real agile, but my org's "agile"). I know the only way things will get better is to find a new job, but I seriously cannot muster up the willpower to improve my situation.


If you have subpar project managers, product owners, and lead developers on your team would you really be better off without structured sprints?

I guess, I'm asking, is there something specific about agile that makes a subpar team worse?


It can make them believe they're good.


In what sense? If they keep missing the planned sprint so that they must take less and less work each following sprint, isn't this telling the company there's something wrong somewhere? (Not necessarily the developers, mind you).


> In what sense?

In the sense that they're 'doing' the 'industry standard' practice. "There's gonna be problems with anything".

If you missed estimates without agile/sprints, and now miss estimates with agile/sprints, you may think "well, at least we're doing industry standard practices now - estimates are always gonna be missed anyway, but now we're more agile".

But now you have the attendant overhead of planning/meetings which is using up time that could be better spent somewhere else.

Something not necessarily mentioned too much that I see, is that if you actually have all those people (PM, PO, tech/dev lead, etc), is that they all have to be good/skilled and generally on the same page. If two are good and one is bad, it's all bad. The system is only as good as the weakest participant.


> In the sense that they're 'doing' the 'industry standard' practice. "There's gonna be problems with anything".

This is true regardless of whether they use sprints or not. Such a project is doomed regardless. I don't think any methodology will fix a project where most of the team is coasting, don't want to do the real work, or do not believe in the end goal.

> The system is only as good as the weakest participant.

I agree about this weakness! I think this is a reality of any software development endeavor.

How would it be better without sprints, though? One thing agile proponents claim, which I think has at least a measure of truth, is that agile doesn't make projects succeed, but it does make problems visible earlier. I think we can all agree visibility is a good thing?

So let's take the perfect project: all devs and stakeholders are stars, they never make mistakes, their customers understand their own needs perfectly, the budget is just right, no errors at all anywhere. This idyllic project needs no "methodology": no sprints, no managers, no nothing.

The problem is that the above project doesn't exist. Back in the real world, where people are fallible, mistakes are made and misunderstandings abound, how can we surface those problems as early as possible, when they are less costly to fix? (when possible, of course -- some projects are doomed regardless)


> How would it be better without sprints, though?

kanban, deliver something when it's done (even incremental when possible), fast feedback...

The notion of "here's what we'll do in the next X weeks" takes a certain amount of planning which (imo) is often better spent just doing first. As/when issues/questions come up, they need to be addressed then, not waiting.

You surface the problems early by some planning, then some work, then some feedback. "Sprint boundaries" don't seem to help in any of that. They help other people who want to know when something might be 'done', but it doesn't help me get feedback or clarify misunderstandings any faster.


Kanban is good for some situations, but in my experience the problems of a weak team (or lack of vision of the big picture) only get exacerbated with this methodology.

Again in my experience, in some environments kanban is an excuse for having the team on a constant death march to burnout.


And... in my experience, 'sprints-point-cards-planning-estimating' can also be a recipe for having the team on a constant death march to burnout. Doesn't mean it always is, but... find what works for the team. Let the team decide. I'd go further and say "let the people doing the bulk of the code work make these decisions first". Make process adjustments after some baselines are established to see if those adjustments are worth it or not.

Death marches can happen regardless of the methodologies used to get there. I've seen death marches up close before the word 'agile' was even a thing in the software world (and have seen it well after, in 'agile' organizations). If the team decides to not do any work for a day because. they're exhausted.... let them have it.


Agreed, but is anyone arguing that the team shouldn't decide?


Being the person to say "let's stop doing X and do something different" has generally not served me well in team settings. Whether or not others on the team agree or even care, they often don't want to be vocal about stuff, and would rather just punch in and do some work and go home.

The psychology around "team decisions" is a weird one, and I don't think there's always as much 'group buy in' or consensus as people might think.


My experience from my previous $work was that things never quite got completed. I really tried arguing for a more sprint-based approach but they didn't like what they expected to be undue overhead. I disagreed since ... well, you can't have a conversation about overhead if $thing is not even done, can you?


But what if it takes even longer to not do what we're already not doing?


I understand the feeling, but isn't everything eventually broken down into small tasks?


Yes, and sprints are a tool to prioritize between them and create predictable schedules for the part that has been broken down already.


There are a number of fundamental pieces of Scrum that are needed so all the pieces fit together.

In the Sprint, one of the fundamental elements is having a "Sprint Goal". This allows the team to see the big picture and add/remove work during the sprint to get to that goal.

Without a clear sprint goal, then of course it's easy to loose the essence or "big picture" of what the team is trying to achieve during the sprint.


> forget the "big picture"

Even if they remember the big picture, the tyranny of the sprint deadlines make it impossible to take the big picture into account - whatever gets the task done faster, no matter whether or not it creates problems down the line.


If your regularly running against sprint deadlines something is broken in either your planning or estimates. Either your trying to cram too much into a sprint or for some reason your regularly estimating tasks as significantly easier than they are.

I'll also note if the response to an underestimated task is "well either pull some extra hours or rush it to get it in anyway" an important step of scrum is being missed.


You're supposed to be integrating everything and evaluating the big picture every sprint. You run into the mindless sub tasks if you don't look at the big picture, sprints or not.


architecture has to be done first


I've worked in places where the cycle to integrate work was more than six months. In a situation like that you often don't really know how to build the product at all and the six months can stretch to anywhere between 8 months and 18 months.

It is true though that springs bring in their own problems. For instance I worked on one project with two week sprints where it took a 2-3 day batch job to generate a database/a.i. model. This had a bit of Gannt chart character in that it had to be managed in terms of calendar time instead of punchclock time. If you didn't start the database build early enough you would predictably blow the sprint.

At the same place there were a few different teams with their own sprint schedules and the system was able to turn a 1 day delay into a 4 week delay as one blown sprint caused another blown sprint.

Another problem is how you organize work that has a pipeline structure. Is a tester expected to test work in the same sprint it is being developed in? What does a developer do when a feature is under test?

What really kills teams is a lack of trust. With the six month build cycle you can put off conflicts that a sprint cycle forces you to confront every two weeks. I think sprints are popular with some because it gives developers some space to be inflexible, but it is harmful for the business. Sometimes there is a feature the business needs right now and it could have it right now if you add 2 days to the sprint.


>> could have it right now if you add 2 days to the sprint.

Unwillingness to modulate the length of a sprint is one of the strongest "cargo cult" indicators in my exposure to Agile/Scrum.


I kinda feel like this shows the weakness of the concept. I’ve worked in a purported scrum model for years, and this is the first time I’ve ever heard of the idea of variable length sprints. Is there a hidden core that most people don’t implement properly, or is there no “there” there and agile consists entirely of calling the planning procedures you like “sprints”?

I’ve grown increasingly skeptical of whether adopting agile even prevents the waterfall model rather than making it less legible when it happens.


I could care less if a team is ‘agile’ but I do care if it has practices that are effective for the group and the work that it does. If anything a good process is not about using good methods but avoiding the bad ones that predictably blindside people every time.

For instance, I think the kanban concept is more basic than estimation. That is, teams that keep starting new work without finishing the old work are working very hard but get very little ‘done’. Thus you have some limit on how many tickets can be open. I know a very well run cafe where that’s the main management practice they use, only taking orders when they are running low on work in progress.

My beef with estimation is that the model that ‘task A has N subtasks and you can estimate the individual subtasks and add them up’ (which works well in a certain sense) is often less correct with the model that ‘the developer sends a work unit to the tester which may or not be sent back to the developer’… in which case the most important factor for how long it takes to do work is how many times you send it off to the tester.

Sometimes I dream about working with a ‘tester’ in a much more closely coupled way than I do. I always have to ‘test’ something myself to convince myself it works to avoid the embarrassment of sending something to the tester that is 100% busted. I frequently spend a huge amount of time setting up tools and environments for testing. That includes the traditional unit testing (which runs quickly) but also processes like building a full text search index for a system with a few million records, testing to see that a machine learning model builds automatically and works properly, that a full text search engine gives relevant results, or spending four hours building a database so I can run interactive queries against it.

If somebody was helping out on that kind of stuff and could test stuff I do with a turnaround of minutes instead of ‘fill out a lot of paperwork and wait 2 days to 2 weeks’ I’d spend more time thinking and coding. (W/ the caveat that thinking about testing can lead to a better design more often than it leads to Test Driven Design Deformation.)


Do you "modulate" a sprint's length once a year, once a month or once a week?

I've seen open sprints named after a pair of calendar weeks multiple months in the past. And for some reason those were still called "sprint". I'd call unwillingness to modulate rather low on the cargo cult scale.


We modulate sprint length based on resources available. There is no point to keep a strict 2 week sprint if during one week most of the team will be on vacation (ex: Christmas), so we make the sprint duration to 3 weeks.


I am curious why you would change the duration rather than changing the workload. Sprint velocity is a ratio of both components: either can be adjusted to preserve it.


Yes, changing the workload would be the normal approach. Same for if people are going to be on training courses, or the team decides they need to spend more time on training in general, so they're going to lower their workload permanently by 5%. I can imagine it becoming really hard for the team to track their velocity if the sprint length varies.


Sprints are meant to correlate with frequent releases. Yes, sprints are a bit weird when we are talking about such large horizons. That sounds like a square peg, round hole problem.


Yeah, I've tasted all of those pain points myself. At $work our app developers expect a working API with all the new routes and endpoints from day 0. We manage this, of course, since we're all adults by simply talking to each other. But... yeah.


Day 0 is presumably agreeing the API contract, day 2 is mocking that, day 3 is implementing tests, day 4 is coding? Hopefully they know that? :D


> Sometimes there is a feature the business needs right now and it could have it right now if you add 2 days to the sprint.

You can just ship 2 days into the next sprint if you need to. You don't have to only ship at the end.


Pretty much every rant like this is a straw man rant overfitted to the writer's worst experience of what someone called "agile" in one of their companies once.


One of these days we might even hear of an example where following "agile" actually panned out. The question is - before year of the Linux desktop or after?


Essentially every project I've worked on in the last 9 years has been agile, most of them Scrum, and almost all of them succeeded in achieving their goals. There's a clear correlation on all of them between the skill of the project manager at applying the agile approach, and how difficult the delivery was.

Prior to that, I worked (as did most people) on waterfall-style projects, and the success rate was only about 50%.


Usually when agile approaches (kanban or scrum) fail it is because there's an unsolvable bottleneck. Typically too small team, lacking knowledge or skill for the scope, problematic environment (development or socially) or someone is pushing "done" work causing skyrocketing development debt that quickly comes to a head - typically a prototype remains in production, switching too early to maintenance mode for business reasons.

Waterfall cannot identify those risks without huge experience. Scrum tends to exacerbate some of them. Kanban with sufficient number of phases tends to expose the problem, but not necessarily fix it.


Most of my career has been working at places using scrum/kanban. And the vast majority of those projects delivered valuable software to customers at the estimated pace.

The ones that didn’t were easily attributable to outside factors or specific problems like an exceptionally bad PM.


It pans out more often than not, which is why it's the default. For now. Eventually something better might come along, but until then, this is working for many, many, many productive teams. Including mine.


Strict Scrum is really not the default in tech. "How Big Tech Runs Tech Projects and the Curious Absence of Scrum" is good reading here & matches my experience.

https://newsletter.pragmaticengineer.com/p/project-managemen...


The category error of thinking scrum is the same as agile is a big contributor to the complaints.


Who said anything about scrum? The comment was about "agile," of which scrum is only one possible implementation[0]. Sprints are not only found in scrum, but also in other agile approaches, like kanban.

Two-week sprints seem to be the default in tech, although I've worked at a company that very successfully used one-week sprints. That's completely separate from how strictly companies try to follow "scrum," if at all. I've run into kanban more often than scrum, personally.

0. https://en.wikipedia.org/wiki/Agile_software_development


I've worked at 3 different companies now where the system worked well and teams moved quickly and created great software.

Unfortunately, that story is incredibly boring and goes against the tech blog hivemind.


Was it Agile that made this possible, or perhaps the organizational abilities of the companies that made this possible? In other words, if the same organizations used a different methodology do you think the results would be completely different?

I am a firm believer that one, "does not get chicken salad out of chicken shit." Thus, well ran and well organized companies would produce similar quality of products regardless of methodology, and in the same vein, poorly ran and disorganized companies will produce garbage regardless of the methodology.


This, boring things don't tend to be reported on as much.


The tale of the project launch that wasn’t missed because the client was onboard with iterative delivery?


Agile is a nebulously defined cosmic aura surrounding all software projects in the world that go well.

Scrum/sprints are kind if like the bureaucratized and ritualized version of that. The Catholic Church to Agile's Christian cult.


And every rebuttal is about how well it goes in the (seemingly rare) case that everything goes as its supposed to. Both are overfits of a sort.


In the same way that few ReST implementations are truly ReSTful, few agile implementations are truly agile.

The Agile Manifesto came into style, then predictably a cottage industry of small companies grew up around it, with the business model of charging Fortune 500s huge amounts of money to train their Engineering departments. I've sat through such training before, and I can say without doubt that the day our company took "agile training" was the day we stopped being agile.

We overlaid an efficient process with a ton of bureaucratic busy work. We came out the other side of it with an army of PMs (read: Jira configuration experts). Engineers had less time to engineer, with constant flow-interrupting meetings where they became trapped in a morass of Gantt Charts, "deliverables" spreadsheets, etc.

We had many employees for whom English was a second language, and interestingly none of those I talked to realized that "agile" was an actual word, meaning "nimble, quick, dexterous." Nothing about the new process conveyed any of those qualities. It was basically classic waterfall, with stand-up meetings thrown in. Rigid project management methodology is definitionally opposed to agility.


I tend to think of communism as a comparison. Aren't proponents of "agile" similar to those saying "we've never had real communism"?

Both have manifestos.

I think there are certain systems that make sense and can be executed properly but human nature eventually mucks it up.


Well put... Animal Farm is really about Agile.

All engineers are equal, but some are more equal than others!


No one's saying we've never had real agile.

Philosophically, agile is more like democracy/capitalism: it decentralises control to teams, where the information and expertise are. Failures in agile are things like "I didn't like using story points".

Waterfall is more like communism: it centralises control away from the people doing the work. Failures in waterfall are things like "we spent millions and got nothing out of it".


Yes, sprints on paper are what you describe, but in reality, they rarely ensure deliveries or predictability, they even tend to hinder productivity as they narrow the body of work of a whole team. Think about it, after a week, what is usually the distribution of work of your team? For me, it was always very unbalanced, where people where working overtime and others (best case scenario) would be looking for some work to do.

I understand the author's heated post, because I've been there so many times, and I think THIS IS THE POINT of this article, the point that you are missing. Good manager shouldn't rely as much on a set tools that are broken or unfit for their team.

I my opinion, not enough people question Sprints and their viability and benefits. And he's right, backlogs are by far just a list of the things you wont do.

If your tool cannot fix your issues, the manager should. Use post-its, emails, spreadsheet, large whiteboards, hang a TV screen in the room, pdf, discussions... There is endless possibilities, be creative.


I guess all will agree that every successful product is an outcome on number of iterations and to perform progressive iterations there has to be a way / tool which can be one language across the board. That's why these tools such as Sprint exists. And I am sure if you are a good manager ( a future self ), you would sure not giving yourself a suggestion of using "post-its, emails, spreadsheets, large whiteboards , hang a TV screen, pdfs" as the preferred way of managing iterations.


I'm a manager, and post-its, tv screen in the room, extremely large whiteboards (all 3 walls) and spreadsheets have been my secret weapons for a long time... that and going on a long walks with my engineers 1-on-1 to discuss ideas and problems.

Tools and methodologies are guardrails, use them at the beginning as you learn the craft, get ride of them as you grow and always put meaningful conversation above all


> backlogs are by far just a list of the things you wont do

Scrum even has a ceremony for fixing this: backlog refinement.


I have never been in a company that was able to deal with backlog. Albeit I have not worked at all companies, there's got to be some that successfully deal with backlog... but how many?

Is Scrum a solution that really works, or merely a great concept?

I agree with and swear by the agile manifesto (it's really amazing) but IMHO, all of its byproduct methodologies fall short in the real world, with no exception.


You can't fix organisational issues with any process, but if people agree to do it, it's pretty good. And it has a retro in it, which is the most important meeting, where you can change the process to something that suits your needs better.


I’d go further, sprints are defensive for devs. Don’t bother me or tell me to do something new during a sprint. I’m doing the work I said I’d do, leave me alone until the sprint is overs.


I love it when something needs to be done to unblock a large group of testers but the dev team says “the sprint is closed. Come back in three weeks and we will consider it”. Truly Agile.


Testing should occur within the same sprint as dev where possible - if you're throwing all work over a fence to a distinct QA team, you're doing it wrong.

If testing in "real time" is not possible for some reason, the following sprint should have testing support baked in as an explicit task.

And, IME, sprints work well for mature products where there's a steady flow of defects and enhancements that are relatively easily articulated. Sprints work less well for greenfield development with new tech - you just end up with long strings of spikes/analysis/PoC work (it can still work, but you tend not to have concrete deliverables each sprint).


“ if you're throwing all work over a fence to a distinct QA team, you're doing it wrong.”

That’s how it works in an industry where product bugs can kill people. The devs do their own testing but there are large testing teams that take a deep look at at everything the system does.


Fair enough, that's why my second sentence is there. The scrum master/manager should be building in QA support. If they aren't, they'r failing at their job. A individual developer should never be put in the position of killing a sprint in order to support a QA team for work the dev team did last week.


As a senior dev I hate this. Of course I'm going to drop everything, if what I do stops making sense on an org level. Why would I do anything else.


Maybe you've never had a project manager whose whims change with the wind, and interrupts the sprint to add yet another high priority bug in the middle that absolutely-needs-attention-right-fing-now... every sprint. Scrum tries to stop that.

Of course, if your project management listens to you and trusts you, you don't have this problem, so I understand your take.


Sounds like you've had an awesome career with no experience of people slamming unnecessary work into your workload, or trying to design in detail things that won't be implemented for 6 months, and will have been redesigned 5 times in that time. For everyone else, sprint backlog is a useful tool that you decide when you should violate it, and by exception only.


> Why would I do anything else

Because you'll get fired if you don't...?


Love it. Lots of agile benefits for devs. Less hand-wavy requirements. You get to say how long your work is going to take


We have vastly different agile experiences, my friend.


i've seen a lot of ppl do it wrong and claim it doesn't work. it's like not obeying the rules of the road and getting mad when things get chaotic


In my experience, the “predictable deliveries” delivered by agile are based on behavior changes induced by the methodology. Specifically, focusing on stable point velocity per sprint focuses the team on creating sprint plans that safely deliver. This reduces the potential accomplishments of the team - they reduce throughput and delivery to a level that can be safely accomplished every 2 weeks.

I have yet to find a startup that successfully launched using agile. I am sure there are examples, but most seem to be focused on the true goal of software development: releasing features to production.


Linear.app is an example of a startup that "successfully launched using agile" and focused on "releasing features to production", while working with 2 weeks cycles (not "sprints"):

https://linear.app/method


Right, this is exactly what GP is talking about. When you prioritize "doing predictable sprints" and a stable point velocity over releasing features to production, you reduce your team's throughput and productivity. When you prioritize shipping features to production over "predictable sprints", then things can be successful. You're proving GPs point, not contradicting it.


You're contrasting two different types of thing. If part of something being "done" is deploying it to production, then it will be useful to have the "deploy to production" bit of it managed by a sprint process that tries to account for all the work needed to do something.


Yes, people like predictable.

Tell management every project will take a month, and meet that expectation, then management will be happy.

While someone else who takes the same work and says it’ll take one week then is consistently 2 days late will be viewed as less effective.

So, by squeezing people into a guaranteed timeframe, in a mini death march aka sprint, you are forcing people to make [very] conservative estimates.

For larger companies this might be preferred, but I would argue, smaller companies should try to move faster.


My read of this is agile is primarily attempting to maintain the emotional state of the management team.


> you are forcing people to make [very] conservative estimates

My experience is that once developers make conservative estimates they are ignored because business side of things would rather prefer to imagine they'll get the system completed this decade, not when estimates show. So instead of working according to estimates everybody is crunching and cutting corners and project gets delivered in some useful form in less than a year.


This is a strange law of human groups. Only caring about negative slip. That's why everybody inflates everything to shield themselves from the backlash.


That's a good reason why sprints work well so often. They limit the amount of inflation that is possible.


I think sprints (I've almost never used this in work and am not anti) are lacking something, limiting scope is one thing but do they ensure framing the problem / solution / design well too ?

The few times we've used sprints it was just issue dispatch and see you later, not really a guarantee of anything, but maybe I'm missing some information.


> do they ensure framing the problem / solution / design well too ?

In my experience with a complex product, they do not. You need an earlier, separate layer of preparation for defining and refining implementation tasks until they are ready to be scheduled in a sprint.

Although in the ideal workflow, you should be able to split those definition processes (user research, writing requirements, etc) as tasks for the team members involved, so their output can be included themselves as deliverables in previous sprints, so that later ones use those completed definition tasks as input.


Thanks a lot.


The issue is management rarely is looking 1-2 months out. They are looking 1-2 years out. On those scales it is impossible to estimate anything.

"Oh, yeah, the rewrite will be done in 1yr, no worries"

One year passes, and you haven't started!


I wish it was the norm for management to be looking 1-2 years out. Sometimes that tries to happen at the C level, but even then it doesn't seem to work its way down to line managers who are almost always focused on the next immediate deliverable. Future looking managers are the exception, not the rule in my experience.


I'm not saying it is good forward-looking. Can be bad.


Why do we need predictable deliveries?

Let’s boil this down to first principles. Nothing about building software, especially innovative software is predictable.


Many (most?) software projects exist in environments that demand predictability. Businesses need to be able to make promises to clients and potential customers in order to make sales and garner trust. In any remotely competitive industry these are two absolutely essential ingredients to success.

I mean, think about the software you use. Of all the shops that produce that software, which ones do you trust more than others? I'd be willing to be it's the ones that delivery predictably. At the very least the ones that deliver updates reliably - as in they do what they say.

Granted, every industry is different and some rely on trust and predictability more than others. Building an organization that is good at that is very difficult - and that cost has to come from somewhere doesn't it? In my experience it's at the cost of time spent building the product. A tradeoff between reliability and quality, if you will.


> I mean, think about the software you use. Of all the shops that produce that software, which ones do you trust more than others? I'd be willing to be it's the ones that delivery predictably. At the very least the ones that deliver updates reliably - as in they do what they say.

Of the software I use (slack, cloud infra, vim, Jira) exactly none of them tell me precisely when a feature will be delivered. They work hard on it and release it when it's ready.

A deadline like "in a few weeks" is acceptable. A deadline like "in 17 days" is asking to be missed.


Communicating hard targets to customer is always a mistake, because software is hard. For that matter, many other industries similarly try to avoid communicating hard targets, and for similar reasons.

Internally, though, Slack et al have targets and expect to deliver feature X by the end of sprint Y. They just don't tell you in case it slides by a sprint, and to avoid laying out a product roadmap for fast-moving competitors.


Most good software that I can think of has the luxury of being delivered whenever it’s ready. It’s not estimation that improves the quality of the product but good cost/benefit analysis, although you can get one from the other.


There is nothing unique about software - building almost anything has a certain amount of inherent unpredictabilities - would you hire someone to build your house with no commitment of when it would be done, what it might cost or what it might look like before it is completed? I doubt it.


If you give 2 builders a set of blueprints for a house, they will build essentially the same house.

If you give 2 software developers the same software spec they will give you 2 completely different pieces of software.

The code is the blueprints.

If you’re building a new innovative house that is different than what currently exists, the design phase is very similar to software development, and is likely to take an amount of time that is unknown at the beginning.


Unless the construction blueprint includes the construction workers skill set, and the bill of materials, I doubt it.


Construction blueprints do indeed include a schedule of materials and finishes.


And as we all know they always deliver on time with top quality.


I’m not really sure what your point is.


That construction work is just as bad as software delivery, when the same shortcuts in quality are taken.


That's fair. A builder could build a terrible house from the same blueprints as another built a great house.

However that's not really what I'm talking about. Assuming some minimum level of quality, 2 houses built from the same blueprints with the same materials and finishes, in similar locations, and by similarly skilled craftsman will be pretty much indistinguishable from each other to the end user.

That's not the case with software.


More analogous to software development is the design of the house with the blueprints as output, and regulations, client review, and architect creative inspiration as the software specs. Nobody complains about blueprints being delivered too slowly. They just happen on a competitive landscape where two people are racing to deliver to the client so the slowest person loses.

I like kanban, a stack of tasks with predefined dependencies determining if a card can be picked up, and sorted in priority order once they can be picked up. When something critical goes wrong, the entire team stops and works the problem individually, competitively , until the problem is solved, and the team then resumes their prior work. CI/CD delivers to production, features are enabled when they are ready and the customer is ready. Feedback goes immediately back into the stack and delivery leads constantly manage the feature flags, the stack priority, and inter team communication. The devs just dev and stop the line. The team tech lead, product lead, delivery lead, architect, and program/product lead do all the negotiations and priority setting. There are no estimates. You deliver constantly. You need strong leads and architects to run this way, and you should probably coach your client to expect slow change at first, and rapid change after the first release.

Done this at several clients, for several different domains, with lots of interdependent teams as a consultant, and it is highly productive. The one time it failed, we didn't get buy-in on feature flags in production and the client insisted on batched release branches and long-term maintenance branches for those cut releases.

The other, minor failure, is that it is very prone to momentum. That's when teams get overconfident that they can fix problems in-band with tasks (because they've been successful for so long), and are resistant to stopping the line. This can be spotted by a person not delivering a pr for more than two weeks, or not transitioning a card to done for more than two weeks. Tech lead calls a meeting, determines the issue, decides on stop the line or not.

It works. It's iterative. It keeps the number of communications channels and decision stakeholders low. It cross-polinates through linked dependencies. It ensures product cohesion thru feature flags. It evades critical missteps and bugs via stop the line. And it works well with our modern SSO dev/platform ops and integrated toolsets (Atlassian/clickup + ci pipeline of choice where docs, features, delivery can all talk to each other and reports can be generated for leads that pull from the integrated tools). It doesn't fix Conway's law, but I am not sure that actually needs fixing in truly large development houses.


Yes all large projects have risks, however it's ridiculous to say there's nothing unique about software. How often does a nail in one corner of a building become a dependency for a bunch of elements clear on the other side? How often does a dog house have to scale to a skyscraper because more people suddenly want to use it? How often do materials and laws of physics change in the real world? How often can you not get a clear answer on whether a specific requirement is necessary?

Software is arbitrary logic which many stakeholders expect to be magic. It's not the same as any kind of construction project.


>>How often does a nail in one corner of a building become a dependency for a bunch of elements clear on the other side?

Thats like asking 'how does naming my local variable X instead of Y have any dependency on code in other functions? and assuming that summarizes the complexity of writing code.

I take it you have never built a large custom house from scratch.


Seriously? Is this the nit you're going to pick on to argue my thesis?

Yes, I have been privy to the pain of custom home builds and remodels. The difference is, when someone says "oh damn the plumbing isn't working as well as we would like", when the contractor says that's not feasible to fix without gutting the house back to studs at the cost of hundreds of thousands, people understand that intuitively. They don't say "can't you just drill some holes and run some new pipes diagonally through the living space".

Software is malleable, opaque, and ever-changing. Construction and maintenance costs of physical infrastructure can be explained in a way that a reasonable lay person can understand. That is not true of software at scale.


And with the same result, you can't expect someone building your house to finish it on time, on budget, the same way you expected it to be built going in to it. Construction projects in the real world end up the same way software projects end up -- with ~ ~ unforeseen ~ ~ delays and complications.


> Nothing about building software, especially innovative software is predictable.

This is basically exactly the point. It's incredibly difficult to predict building 'large software'. So, lets try a few things to help make it a little bit more predictable by trying to predict smaller increments.

> Why do we need predictable deliveries?

Say I'm building a piece of software - maybe an app the audience would use - for the Superbowl. It's very handy to be able to estimate our progress to see if we'll actually land that date. The Superbowl isn't going to move because of our app, and our app isn't very useful the month after the Superbowl.


This argument comes up a lot but this is a very narrow case. Neither you nor I are building software for the super bowl, and if we were building something with such high stakes we should start way, way early and concentrate on core functionality first. There's no real deadline for the feature we decided we needed last week.


It's not the Superbowl, but I built software for a national sporting event during my time working on VOD for a broadcaster in Australia.

I think this sort of thing - where what you're building has external hard-to-move dependencies - comes up more often than you think. Those election visualisations on NYT didn't build themselves. There's often a bunch of less-hard-but-still-inconvenient dependencies as well - you're building software for hardware, or there's advertising campaigns in planning/motion.


If you’re post-launch, you need predictability so that you can ship the new code often. Otherwise your HEAD might be unshippable for weeks, which would be bad from the “written but unshipped code is a waste like excess inventory” standpoint.


Apple comes out tomorrow and announces the new iPhone 15. "We do not know when it will be ready. It might be tomorrow, or just as likely it will be in a hundred years."

Who will hold their breath? Who would invest in this? Software needs to be used by people. Software deliveries that cannot be estimated cannot be relied upon for planning. It may as well never be announced!


But they wouldn’t announce it until it’s pretty much ready.


> But they wouldn’t announce it until it’s pretty much ready.

Now you understand sprints


Apple doesn't come out and announce a new iPhone 15 until it's already 90%+ done and working, and therefore can accurately predict some kind of reasonable release window.

And software that can't be estimated is still useful, even if you can't plan releases around it yet. "Apple has been unable to accurately estimate any release window for the Apple Car or Apple VR. Therefore no one should invest in it." would be a pretty silly statement, right?


> "Apple has been unable to accurately estimate any release window for the Apple Car or Apple VR. Therefore no one should invest in it." would be a pretty silly statement, right?

That's exactly how it works though. Imagine Apple's stock price if they announce the Apple Car, without a release window. Now imagine that they come back the next day and say "oh by the way, we're aiming to release it in 2086." What happens to the price? It goes down. There was an implicit estimate used to judge the value of Apple.

Likewise, all software has an implicit estimate. There has to be! Without one, it's worthless.


OP doesn't care about building software (innovative or otherwise). He cares about getting his quarterly bonus, which is based off of meeting deadlines, because that's what can be easily measured. Delivering a quality product is much harder to measure.


Actually it is predictable, the majority of software engineers predict it at work every day (or every 2 weeks in sprint planning).

Why do we need predictable deliveries? Because if Bobby from accounting doesn't have your piece of software ready by the 31st of November the company will be slapped by a fine from the IRS so large that you'll need to update your CV alongside all your colleagues from the now bankrupt company you used to work for.


> Why do we need predictable deliveries? Because if Bobby from accounting doesn't have your piece of software ready by the 31st of November the company will be slapped by a fine from the IRS so large that you'll need to update your CV alongside all your colleagues from the now bankrupt company you used to work for.

Yep, at the end of the day, the whole world can't run if everyone is a professor emeritus just freely exploring random possibilities, even if it would be hundred times more efficient to just "get out of the way".


In what company is accounting moving to software which isn't ready, and where they will experience a large fine if it's not, guaranteed by a 2 week promise? Rational people just don't do this. Especially considering how often we're wrong even when we define sprint boundaries and point all the stories.


> In what company is accounting moving to software which isn't ready, and where they will experience a large fine if it's not, guaranteed by a 2 week promise? Rational people just don't do this.

You just have to sign a standard contract for building a project in 24 months, and wait 23 and a half to be in that situation.

Managers need a tool to avoid reaching that situation and renegotiating the terms in advance.


> Why do we need predictable deliveries?

Because your organisation answers to shareholders on a quarterly basis.


Because we have budgets


So the managers can powertrip.


Predictable delivery depends on the quality and not on the form.

Good quality planing, good quality execution will make a delivery predictable regadless of the projecy management style and how we break down a big task into smaller bits. If the breakdow is carried out badly or the big picture is formed carelessly then the chain of sprint breakdowns will also deliver rubish!

If one lives on and focuses on atomic deliveries only and cares no other then I agree.

But that is rarely a product, sometimes not even a feature.

Also complexity (symphony of small tasks) has to live somewhere and unpredictability of the big project will not go away with week based planning cycles.

But I too know better actually. : ) Except probably all the others if everything is done with suitable care and attention.


> Good quality planing, good quality execution will make a delivery predictable regadless of the projecy management style and how we break down a big task into smaller bits.

From some hard-won experience working with a variety of different teams, I have unfortunately found that good quality planning and execution are far harder to attain than you perhaps imagine. Some of these articles seem to paint software developers as magically perfect beings, with managers being pulled straight from Dilbert. The reality is far more complex. Sometimes one of the people on the team is being an asshat and hoarding knowledge. Sometimes they have overly-strong opinions on languages and frameworks that they're super familiar with, or go to the other extreme and work on only bleeding edge ones that were posted on Hacker News.

I strongly suspect that Agile is used at companies because it's a mildly effective way of curbing these dysfunctions in a team. If you spend time and money hiring the perfect team, then you probably won't need Agile. Think of a situation you do find somewhat commonly where you often have hackers smoothly churning out work with a team they selected perfectly for – early-stage startups. Good early-stage startups are often very picky about who they bring onboard, because an unproductive hire can literally cost you the company. It's possible to reproduce that on a team, but imagine telling your next boss at a run-of-the-mill that you're going to hire slowly over 18 months and very selectively.


Yeah as an ex-engineer and recent product manager I was very confused how the author expected things to get done in an predictable manner of nobody knows when it'll be done. Engineers also rarely interact with the sprint process. We do sprint planning with the engineers to make sure they know exactly what they're building, how much time it'll take, and give any opinions/questions they have on the ticket. That meeting lasts for an hour (maybe less) every 2 weeks. Our daily standup is 15 mins (usually like 8-10) and the point isn't to track engineers like an overlord. It's so that if you have any blockers we can reach out to the right parties for you so the engineer can continue coding without distractions. Plus, the product manager isn't your boss to be tracking you. Your engineering manager is your boss


I also sensed this piece to be an emotional criticism to sprints, backlogs and tickets, lacking structure, evidence and logical arguments.

For instance:

> (...) they’re designed for managers who don’t trust their employees (if your manager needs to look at Jira to figure out what work you’ve done for your review or what’s shipped lately then they’re not paying enough attention to the team).

I disagree. Visibility and documentation of work are important for having everyone working in a project on the same page in an efficient manner, and definitely not a sign of lack of trust on the team.

From checking the author's information I found that he's a "writer and web designer". So maybe he comes from a different background that led him to develop this pessimistic views on scrum.

I'm personally more attracted to Kanban than to Scrum, even so I can see value in Scrum when run in a disciplined manner.


May be a strawman, but his frustrations are real and I share his sentiment.

Sprints et al have been a mixbag for me, but the last 7 yrs (current team) have been plain utter BS. All the ceremonies too, retros are nothing but waste, because they only serve to praise undeserved credit with no product to show for most of that time period.

I credit the OP for his courage to raise his voice to shame those/any bullshitters behind the Agile movement.


Sprints are for middle management to keep projects from getting out of hand, they aren't for programmers or programmer freedom. When you understand this simple principal it all makes a lot more sense. It's really no deeper than that. All the stuff grafted on top of that as "support for" is pretty much all feel good fluff and unproven social theory.


Sprints, at their best, are interruption buffers. They provide a preset time before which, engineers shouldn't be interrupted from getting stuff done by whipsawing to new priorities.

That big new product is still going to take three months to deliver, regardless of sprints, but you don't get to pull the team off working on it for some new idea until next sprint.


> they're a tool to get more predictable deliveries

No, they're a tool to get the illusion of more predictable deliveries. As always, comforting lies are more welcome than harsh truths.


Nice way of arguing: “this is nothing but a strawman” - and 0 counter-arguments, 0 quotes, 0 attempts to be polite. Brilliant.


I suppose OP will be pleased with your comment. Imitation is the sincerest form of flattery, and all that.


Sprints are waypoints on your product delivery journey. They ensure you're not wandering too far off course.


You start with dismissing this out-of-hand... which is weird, because you pretty much agree:

> ...probably not the best method and maybe it's not even good

It doesn't sound like you believe in sprints either, but can't imagine something better.


I absolutely have to 'like' it because I have to do it. Scrum masters and Product Owners love to inflict Agile bullshit, but they do not suffer from it. They have little understanding of the process of software development and imagine themselves to be capable of 'adding value'. Agile is a failed experiment kept alive by people who have no skill other than working the work.


Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2 weeks.


Sprints and planning are useful for organizations that attach a lot of value to planning and deadlines. It creates a lot of additional work and pressure, as you say, but I can also imagine that for certain types of organizations that may be worth it (eg when doing client work on a fixed budget with strict deadlines).

Other than that, I fully agree that Kanban is a great middle ground, as it’s low overhead and focuses on prioritization and flexibility rather than planning and burndown charts and whatnot.


> Sprints are really just a form of pressure

I’ve felt the opposite. My team switched from “Scrum” to “Kamban”. Then after a few months the sensation of having an endless pile of cards, without a time frame, felt overwhelming.

In the other hand, having a short lived cycle used to help me manage my time. If for any reason one day I was not able to accomplish much, I knew I still had a few more days to compensate. The same was true for the opposite, I could be really productive a few days and then I could relax for the rest of the sprint.

That workflow really worked for me. With Kanaban I feel the pressure to always be “productive”, because I don’t have a clear reference on how “relaxed” I’m (or not), during the week or month.

Maybe I just need to find a different reference. I guess my point is that sprints don’t necessarily mean pressure for everyone.


Kanban is still better than sprints. You organize things that are most important at top, and what is done by the deadline is done and ships; what isn't done doesn't ship. Deadlines may mean you branch so can make the release stable, while feature work that clearly won't be done one time can continue if the team working on it isn't involved in the release.

It doesn't matter if you have sprints of kanban, if there is a deadline is project managers need to do the same work to verify things are progressing fast enough for the release. This work is estimating how much time remains, and if there isn't plenty take action. The plenty part is where most management goes wrong: they want everything done on time, but the only way to get that is have everything done early. That in turns means you need to have at least 20% (the higher the better) of the things planned for your deadline things that you are willing do allow to slip to the next release. Of course working against that is the human tendency to polish things until the last minute, but that shouldn't be managed by the deadline (even though it often is)

I'm against the web release early and often model - don't make your users your beta testers. I'm in favor of spending several months of test after the branch to ensure everything is stable even though this is a lot more expensive. I do agree with the web have automated tests for everything model, I just don't think automated tests alone are enough quality control - automated tests ensure that everything you can think of didn't go wrong, manual testing is about noticing things you didn't think of. (you will note I work in an area where my code can kill people)


Funny how whenever I've done kanban, top tech debt items always are eternally pushed down to #5 or 6 in the backlog, never to see the light of day.

I have my criticisms for sure, but sprints give more discretion to the teams to carve out space for multiple types of priorities held in balance, and lock that ratio in for a period of time.


> sprints give more discretion to the teams

when they do. i was part of an 'agile' team in 2019 (6 mo contract). I wasn't there long enough to have strong views on work items or priorities, but did watch the interactions between others. It was a decently organized team inside a (fast) growing org - lots of challenges there. But overall, there was a decent balance.

Worked on another smaller team longer - 2 years. As the company grew, it got far more process heavy. The 'sprint' stuff was "as tech lead, you get 5 points to use however you want per sprint!" (yay?). that got taken over by the CTO getting involved and using those '5 points' for constant infrastructure stuff. I was reviewing code I delivered, and it was full of cut corners to continually hit deadlines. I begged on a few occasions for more 'cleanup' time. It was always denied (except for 3 days over xmas, because... literally no one else was working, so they couldn't say no).

The project transformed in to "here's our strategic goals for 2022" with every quarter mapped and filled to the brim with work. 0 time for anything but bare minimum MVP. The thinking was "well... you've been able to work at that pace before, and we added someone new, so we can increase that". In 2019, it was MVP - test the idea. Speed to market makes some sense. In 2022, millions of dollars and hundreds of lives affected each month... we need to take a bit more time to clean up existing code, retire legacy code, adopt a slower pace to focus on clarity, testability, even performance concerns etc. This seemed to fall on deaf ears.

"discretion to the teams" tends to ring hollow to me based on recent experiences, and ideally I'll work with another group in the future with a healthier balance.


On a 6 month contract you haven't been around the code long enough to know what is tech debt and what is a good solution for a complex solution.

Though your point is correct - you rarely are given time to fix tech debt. If you switch to a long term employee, then you should intentionally slow your velocity a little to fix tech debt. By the time management catches on you will have fixed enough that an improvement is visible and so you have proven yourself, and thus will be allowed to do more of it.

Also note that a story isn't done until refactoring is done. Sure it works, but if the code is a mess your story isn't done and you don't move onto the next one. Many developers fail to force this, but as a professional this should be part of your code of conduct and thus not optional no matter what the deadline.

In any case the point is you will never be officially given those 5 points - but you can take them by force.


I think the answer here is to point your current tickets higher. When someone asks for estimates on time, or points, you give a higher estimate so as to not leave as much tech debt behind. In theory or course, may not work in practice.


Potentially, some, yes. However, when goals have already been decided, and 'missing' those goals is a 'bad thing', there's only so much you can do. We'd gone from collaborative to 'command and control'. And... FWIW, we got a lot more done under 'collaborative', but it was mostly just 'me' on the dev side and one other person on the product side.

At some point though, many of the original assumptions about problems are understood to have been fundamentally wrong/misaligned, and need some revisiting. You need to touch old code, whether to delete it, or to have it align with new standards or new ... whatever. Touching anything that didn't relate to an explicit 'agreed on' jira ticket was seen as wrong/bad. I ended up bundling in 'fixes' of unrelated stuff when working on 'new' stuff because... it had to get done, but was ignored or rejected during any sort of planning.

I've heard it said that "to go fast, do it alone. to go far, you need a team". I can get on board with that, but you need a team in agreement and competent. I have a colleague working on a small team and... they're mostly just completely inexperience and bad, but there's no self-awareness. Taking direction from the guy who was in high school last year, while ignoring the person who's lead multiple teams and has delivered high value software for 20 years... that's a bizarre imbalance that can't be fixed with 'sprints' or process alone.


Agreed.

As an aside, one thing just came to mind. Even if you're bringing tech debt tickets into each sprint, there's a possibility they'll get picked up last - fine, unless they keep getting pushed back!

Part of me thinks this could be mitigated by reducing the velocity expectation. But there tends to be an overarching sprint goal relating to product work, and this often invites extra scope due to unforeseen impediments. So 'background' work like tech debt is easily pushed back.

I don't know of a better way. Perhaps it comes down to human factors such as limited focus.


There are two ways management can handle getting things done on time: commit to taking only 80% of the teams capacity, thus ensuring there is plenty of buffer; or commit to the full thing, and accept that some things won't get done. If (as most do despite Agile warnings about it being wrong) your management wants you to get done 100% of what you commit to, then as a team you need to hide 20% of your capacity from management.


Do not let formal debt and improvements compete on the same ranking.

Either do 2 of this, 1 of that, or have separated time slots, or whatever. But separate them.


Yep. We used to dedicate 20% of story points to tech debt, when we had quite a lot of it.


You can value planning and deadlines and still not do sprints. The key is that whoever is managing the project, whether it's a dedicated PM or just the lead dev, needs to be fully engaged with the team and understand the work that is being done. Cards (beyond a basic todo list and record of who's doing what), points, sprints, standups, backlogs all of these are symptoms of bad communication and a lack of an overall understanding of the project. Unfortunately, or fortunately if you can put it in to practice, this means that the person leading/managing the team needs to understand software development as well as the current tech and tools being used. There is a place for non-technical managers but it is outside of the software development team where they act as an interface between dev and the other departments or interests in the company.


At a past job for a while we did Kanban with the sprint as a time box and it worked really well for the constraints we were working in. When we had work with deadlines, we'd flag that work as needing to be done in the sprint time box and put it on the top of the pile. Otherwise the team just kept picking up the next item, and we'd do a single review meeting at the end of the sprint to check in and see how everyone felt and what was accomplished. It was less of a retro and more of a temperature check.

It worked really well for a team that served a lot of different stakeholders and also had to field requests from customers since the priority of the work was always changing even if the deadlines for the work didn't.


If you place a lot of value on planning and deadlines, you should probably embrace that wholeheartedly, and not try to pretend to be “agile.”


In a job a long time ago there was a brogrammer in the team, always estimating absurdly short times because he was so good and fast (he wasn't bad, but he was 2-3x slower than he himself estimated). So I had picked up the habit of estimating 5x longer on tasks, to balance him out.

Also all the sprint planning and retrospective took basically 30% of our time.


Agreed. The differences of opinion during estimating are another form of pressure. Programmers work differently. I might estimate a task longer than a colleague, but I might be the type of programmer who tidies up and refactors along the way, or who spends more time communicating with the team on strategy and architecture. These are hard to quantify behaviors that Jira can't effectively track, unless you're going to spend half your day _in_ Jira writing down every action every day. Don't event get me started on the effect of context switching.

Managers are pushed to produce reports to prove they're managing. Reports require metrics, and that's a lot of where all this rubbish starts. The solution in my experience is to keep teams small enough that you don't need those sorts of layers of management (though the opposite is inevitable in larger companies).


How does something like this take 30% of your time? On my calendar it's two hours out of 80, or 2.5%. One hour per sprint for planning, one hour for retro, why would it be longer?

My team lead spends more time prepping tasks with the PM prior to sprint planning, but even then it's about 5%.

My last company, we had one-week sprints, but we didn't do official retros, so it was still 2.5%, one hour of planning for 40 hours of work.


Sprint planning today took 26 minutes.

The Retro yesterday was 30. So that's less than 1.25% of my time spent.


I find it challenging to estimate my own time in tasks. Part of every task is figuring out how to actually do the thing you are wanting to do, and sometimes that takes 5 minutes and sometimes much longer. So I am terrible at estimating my own time, and even worse at estimating someone else’s. It doesn’t add pressure to a person if you give them a time goal they know is basically arbitrary.


Software estimation is very hard.

This is what scrum (done well) helps with. Unless the software was horribly written, it’s usually easy to estimate effort for very modest, well-defined changes.

Take a large enhancement or overhaul, however, and estimates will be wildly off and it’s because of the iceberg effect of unknowns.

What scrum forces the inexperienced teams to do is start breaking down, plan and incrementally chip away at a ill-defined, large request by turning it into many smaller and better understood deliverables.

It’s what very good teams do, though they do it without the need for formality.


That means the task is underspecified. You should schedule a "figure this out" instead, and once the task is well defined it can be done.


You never know if you have really completed the "figure it out" task until the "get it done" task is completed.


A meeting to plan for the meeting. Instead of turtles, it's meetings all the way down.


I never said a meeting. That says a lot about you :p


Shouldn't that lead to a team discussion about why the estimates differ so drastically? In most circumstances, the reasons would be inaccurate assessment of scope or complexity. Clearing up misconceptions like that can be a great boost for productivity.

"Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach."


Theoretically, yes, but if you’re spending half of your time on process overhead there isn’t much left to do that well and most of the time there’ll be enough differences from sprint to sprint that it’s plausible that this time was late for other reasons, until you have a sufficiently long data set to show that it’s a trend.


It did. I said I would not stop doing it until he'd stop. So we just continued this way.


It inevitably does and then everyone slowly starts estimating everything at the middle point size in the agreed spectrum, with only 2-3 outliers


> "Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach."

Next performance review, your manager goes: It seems like you're not really aware of a lot of techniques of how to solve problems efficiently. Maybe you should do more pairing with the other seemingly much better developers to strengthen your skills. And now you've cornered yourself as a junior for the next 2 years, who was "hired on the wrong level".

All of this is assuming that the team members will prioritise the performance of the team higher than their own performance, of which there are no incentives. The incentives is to make yourself look as good as possible (don't admit your idea is inferior), and skew the playing field to your advantage (insist on using the tools you know best) etc.

People simply don't spontaneously cooperate and simply don't "just get along" in a situation like this.

Even in hippie communities where everything is voluntary and there is no personal gain to be had, it still falls apart because some people just don't cooperate.

So how do you expect that to happen in a situation with money involved, and competition between people?

Why do the software industry and scrum think they have spontaneously discovered how people always just get along, inside a basic weekly planning schedule? That would literally be a nobel peace prize right there.


Estimates should be made in abstract units (e.g. 'function points'), then converted to man-days or dollars or whatever using a scaling factor specific to the estimator. That way, the actual value of the estimate is moot; it's the consistency of the estimates that counts.


KANBAN is good at ensuring you do not have too many themes on your plate at the same time.

Producing effort estimates is one of the many approaches to start talking about a task, and not doing it may mean that somebody else's better idea on how to tackle it gets ignored.

Having sprints is a good way to coax people in fully finishing things, it is often needed as many developers tend to jump to the next shiny.

If any of these three things gets used by a bad manager to get fake importance, to put pressure, push people down instead of pulling them up... then get rid of that manager.


From my experience sprints ensure that stuff is "good enough" and pushed out the door. Like QA having idea that some icon is not aligned - but yeah it is end of the sprint close it and fix in next iteration and get to work on other thing that has priority now - not aligning some unimportant details.

So sprints are also good way to coax people into cutting scope instead of working till it is "perfect". Then pushing back on management to have breathing space and accepting changes only after sprint ends and not when they have a brilliant idea.

Sprints and ceremonies create touch points for business people to interact with dev team instead of constantly breathing on their neck or coming up with ideas. Business using JIRA and writing stories/tickets should make sure there is enough context in these so your tickets are living documentation "who,why,where".


Don't capitalize words that are not acronyms.

It's just a 5 letter word, it's not that difficult.


> It's just a 5 letter word, it's not that difficult.

Beware the careless pedant!


Instant karma. Thank you, phone keyboard.

I rate my comment a perfect 7/5.


カンバン then!


Yup, that was the overall vibe at my last place. Sprints are too micro and lead to tunnel vision. Got a lot of stuff done, but the hard tickets were always underestimated & dragged across sprints. And was it the "right stuff" to be working on to start with? Everyone felt like we were failing even as we got a lot of stuff done.

Additionally, despite the attempt at predictability, wider project management was lacking, which lead to cross-team long running projects running over by 100-200%.

Often this was failure to capture actual requirements, making generous assumptions that a vendor would provide a magic bullet, allocating little to know time for integration / cross team work, etc.

Each team worked on the tickets in their sprint, from their backlog, according to what product management wanted. The fact that none of it tied together at the end was not devs fault if you want to institute such a tunnel vision process on them.


> tickets were always underestimated

Teach the developers who estimate them to treat the process as the circle circumvent instead of the diameter and multiple by Pi. There you go - done.


Many tickets were also overestimated! They just don't stick out as a problem since they close early and make the sprint look good. Naturally, the ones that don't close are the ones that are underestimated!

If you overestimate everything then you end up idle at end of sprint & picking backlog items to bring in, so then product wants to put more points/stories into next sprint.

The system is seemingly designed to produce this outcome.


This folds in with the mantra of "Do NOT think about blockers and interruptions when estimating your story points, only think about the task in a vacuum"... and then not looking at blockers and interruptions when judging your velocity and results, either.

The system is to teach everyone how to lie and juke the system. It feels awful working in most sprint-based environments. Because even when you're highly productive it still feels like you failed in multiple places, and it always feels like you're being dishonest and have no real choice about it.


Yup the other stupid thing that kept happening was sizing the work to fit the model. Medium sized tickets were least controversial in 3 hour backlog refinement meetings. Therefore every ticket began to ranked at that level. Which then beget us chopping up anything larger into these medium sized tickets, and avoiding creating any too-small tickets.

So instead of "ticket: make pasta for dinner" it was like "ticket 1: purchase prego & pasta from instacart" , "ticket 2: boil water & get out the jar opener", "ticket 3: cook the pasta and sauce", "ticket 4: place the meal and serve".

Zero chance all 4 finished in the sprint, in fact they were rarely even all planned for same sprint.

It became impossible to express to users what they were getting at the end of each sprint. "OK, so you've.. purchased ingredients, when do I get to eat?"

This happened with multiple product managers, agile coaches and tech leads so it wasn't just a single person forcing stupidity on the process..


If you do scrum properly you shouldn't have a lot of meetings for "planning and ceremonies". We follow "scrum and xp from the trenches" quite closely. We have four meetings: - scrum planning (max 1h/week of the sprint)* - dailies (max 15 minutes per meeting)* - demo (we like to call it sprint review, because it's interactive, not one-sided). takes about 30 minutes - retro (takes an hour)

*most of the times we use a lot less

So we have 2h of meetings in the first weeks, 2.5h of meetings in the second week if you do a two-week sprint as we do. the rest of the meetings is rather "working together" than having "meetings". If you have much more hours in meetings than this (which can be attributed to scrum) you're simply doing it wrong.


I think the point of the OP is missed here. Productive teams don’t need any of this garbage; least of all a religious war about methodologies.

Productive teams are primarily hackers solving larger problems. This stuff gets in the way, causing the team to morph into developers instead.


So... developers aren't productive?

This is a weird take.


Yeah, good point. If productivity equates to value creation then hackers are more productive. If productivity equates to what software management can measure, then developers are more productive.

I’m making a pithy statement about the difference hackers and developers


I gotta say that your distinction between 'hackers' and 'developers' is pretty ill-informed - just out of curiosity, have you primarily worked in start-ups?


This has a real "no TRUE Scotsman" vibe


Every competent agile team i've ever been on ended up with vestigial sprints / iterations. There might be a weekly rhythm to meetings, but there is a continuous flow of stories, commits, and releases. Why on earth would you do it any other way?


Wrote extensively about this a few years back and it generated a great discussion here.

https://news.ycombinator.com/item?id=17154355


On my experience Kanban only works for IT kind of tasks, where each ticket is an isolated action, instead of a small step to a bigger goal.


After working with many methodologies, I think the most important thing is: regardless of which methodology you team is using, stick to the rules and deviate as less a possible from that, otherwise after some years, nobody understands the methodology in place, and people have real issues to follow it.


I get the hate for sprints, and the bastardisation of agile. I think however, the root cause of this is the way in which our society as a whole has been modelled, in a top down manner where control is wrested from the bottom, and perceived control is given to those in between. Each of these articles that make, valid criticisms in my opinion, always makes me think of Bullshit Jobs [1][2]. Most of our lives nowadays are inundated with menial bureaucracy, and each attempt to reform it within bureaucractic systems has simply lead to the red tape being rearranged. I think this stems from our hesitancy to have more horizontal models of ogranisation.

[1] - https://theanarchistlibrary.org/library/david-graeber-on-the...

[2] - https://bullshit.ist/bullshit-jobs-how-our-modern-bureaucrac...


I really like your views on this problem. Never thought about it that way. I had some experiences where what you described was perfectly illustrated. It seems to me that the agile framework allows for each level within an organization (that perceives some sort 'control') to send the responsibilities to the level above, while making the decisions for the level below. Of course there are the daily meetings where this feeling of hierarchy is mitigated since everyone is included, but at the end these meetings really just focus on implementation details of the framework; and not on decisions to make the overall product better.


I don't think hierarchies are necessarily bad, I just think that we tend to implement them in a crappy way where they become the playthings of people who are solely focused on gaming the system for their own benefit. Flat organization makes sense in small groups but that group still needs a leader who can act as the agent of the group when dealing with other groups. It's the representative democracy model which is needed when there are decisions that need to be made on scales larger than that of the group concerned. A leader can also and should act as a tie breaker and moderator when the group is divided or finds themselves unable to make a decision.

Problems arise when those leaders are unaccountable to the people that they represent, you need to have very strong customs and procedures in place that allow you to immediately recall the leader and replace them if they start acting in their own interest rather than the group's. This also requires the group to have good knowledge of what the leader is doing, transparency and a public record of the actions taken by the leader.


See also Yishan Wong's "Let process be implemented by those who practice it" http://algeri-wong.com/yishan/engineering-management-process...


I don't know that 'hesitancy' is the right word. It's just fundamental that people in power use it to seek more power. Even a small initial power imbalance will eventually lead to a large intractable one. Happens at pretty much at all scales of social (political, economic, etc) interactions.

The only solution I see is to set up systems that make power accumulation more difficult coupled with a constant struggle to rebalance when it inevitably lopsided.


I could not agree more, and I think this take is one of those mental jumps that the pro-Sprint crowd hasn't made yet, but would if they adjust their mental view of how organizations are structured to see it.

My long term pet theory (like, next 10-30 years) is: we have this cohort of "kids" growing up now in an environment where there's plenty of money to be made in non-traditional independent ventures; think YouTube, Etsy, Fiverr, or even professional consulting. Not millions for everyone, but a stable living. The internet unlocked this; it just took a couple decades for it to really blossom. Synthesize that trend with the growing "r/antiwork" "end stage capitalism" "quiet quitting" mindset that many people millennial and younger hold. Then you consider declining western populations. I think there's real potential that traditionally structured top-down companies will face challenges competing for talent in the coming decades; and we'll see an increasing trend of peer-driven organizations (you can think of this like worker owned or highly unionized shops, but its less about the ownership structure and more about the power structure and incentive/responsibility culture).


(I know I'm late) Even though your pov is very appealing, I think you are a bit optimistic on the ability of workers to unionize, in any kind of setup. I personally don't believe moving all services workers from being employees to being freelancers and independent is going to resolve the imbalance of power in between capital and labour.

Taxis and food delivery are two domains that are worse for workers now than they were before.

It works for tech workers because they can just go somewhere else in a desperate market.

I believe most content creators are by and large submitted to the market, just a different one.

On top of this mall the jobs you mentioned are not for the crowd.


> I think however, the root cause of this is the way in which our society as a whole has been modelled

Yeah, so maybe it would be better if "hackers" simply start working alongside the rest of society, and give up trying to force misplaced and awkward hippie ideals into their planning meeting, that makes their work completely incompatible with the rest of the organisation, and society?


Are sprints bullshit? Maybe some of them. But for teams to be effective, you need communication, knowledge sharing and some form of tracking progress. A good manager facilitates these items. A bad manager just throws tickets on a Kanban board.

Sure, if you have a team that can do all the above without sprints, that's great. But I bet they have some other method or social structure that makes team management effective. Most software teams do not have that without some type of formalized structure, especially when new devs rotate into the team.

So, I say stop criticizing the concept of a sprint and start holding your manager accountable for proper communication, effective knowledge sharing and realistic issue tracking. You wouldn't accept crap code, don't accept crap management. Do this and your sprints will add value (and the meeting will be shorter too!).


> Are sprints bullshit? Maybe some of them. But for teams to be effective, you need communication, knowledge sharing and some form of tracking progress.

The real problem, of course, is the word "sprint", which (whether you like it or not) implies something.

A sprint, be definition, is unsustainable.

It's Pythonic levels of hilarity that we adopted this word to describe software development. It's Shakepearean in the tragedy that so many defend it.

Choose another word, like, "jog", "amble" or similar, and you won't see the same level of backlash against it.


I also don't like "sprint". Many say "iteration".


I'm with you about holding management accountable and avoiding crap management, but I think it is orthogonal to sprints. Sprints might be a solution for some teams, but I have seen them fail far more than succeed. Actually ... I've never seen them succeed.


I've seen them succeed. I think the differentiating factors were 1. everyone worked on lots of different bits of the code; there weren't bits that were "owned" by someone, and 2. the end goal was pretty obvious.


10 years into my career I'm still waiting for this mythical "good manager". It's almost as if there's some intrinsic opposition between workers and employers, hmm...


There was some research that when MBAs were hired as managers for dev teams instead of other devs, dev compensation fell. Managers and devs play a different game.


Rich Hickey has a great joke about sprints, paraphrasing:

So how do we run a marathon? That's right, we run a 200m wind sprint! Then another sprint, and another, and pretty soon...

Of course no one does this, you'd die! We don't do this in software either, for the same reason. But when we talk about 'sprints' this is what we tell ourselves we're doing.


I thought "sprint" was dumb at first, for exactly this reason, it's not a sprint if it's week after week. But over time it's just become jargonized, a term of art for me. It's just a unit of organization.


My high school mentor loved to say "beware of inconvenient fictions!".

The most boring choice would be "section", and boring might be good here.

We could borrow from military strategy, not for the first time, and call it a "maneuver". More sporty, and pointing to the repeating nature, would be "round".

I wish the word "sprint" could be used for "this will call for an unsustainable amount of effort. we will be calling in dinner a few times. this isn't normal, and can't be normal, and everyone gets to rest after, but it's something we have to do".

Instead it's just a way of saying two weeks.


Absolutely, I completely agree with every point in this comment. Round would have been a much better and more neutral term for "one unit of agile work". "Sprint" is tantamount to "bursty and not sustainable".

Same with "ceremonies", that one bugs me too, though not as much.

I still don't know WTF a scrum is however (not even sure that's an agile-specific term).

> The fundamental unit of scrum is a small team of people, consisting of a product owner, a scrum master, and developers. The team is self-managing, cross-functional and focuses on one objective at a time: the product goal. [1]

Like, what? I feel like I know less after reading that. That just sounds like...a development team with a team lead and a manager.

1 - https://en.m.wikipedia.org/wiki/Scrum_(software_development)


Scrums are a bunch of lads violently fighting over a rugby football.

Baffling.


I liked the joke when I heard it. Reading it now, I'm realizing that "marathon" doesn't fit as a metaphor because we don't know the destination.

Orienteering, perhaps: https://en.wikipedia.org/wiki/Orienteering


Marathon works perfectly to show how bonkers the idea of sprinting is.

I like the idea of thinking of software development more as orienteering, if anything, it doesn't go far enough.

To deliver full-featured software in time (note I didn't say on time, but there is certainly such a thing as delivering too late) is 10% velocity and 90% dependency resolution.

I'm still looking for a tool which thinks primarily in terms of dependencies, and treats time as it is: fixed in the past and speculative in the future. I don't care if the person who put the information into the computer thinks something will take three weeks, I care very much if there are three projects which need completing before the main track can get past the third step.


I’ve always been confused about deps being an after thought in project management.


Better idea, just call it "software engineering". You don't see runners trying to find metaphors in order to organize how they work.

(Sorry, I'm a bit grumpy.)


Orienteering implies there's already a cartographer who made a map for you.


> doesn't fit as a metaphor because we don't know the destination

From what I have experienced, I think that is perfectly reflected in a lot of software too.


Right - I can't believe how so much of the programming community got suckered into spending their entire career sprinting like mad people from one deadline to another, as if it was a good thing!


Actually marathon runners are used to regular running. You might even skip the marathon and just run regularly. No need to be a superstar, just stay fit, with a steady progress. Same for software projects. Maybe the analogy isn't that bad.


Right but really, no one actually is sprinting. Devs aren't leaving standup to type as fast as humanly possible for seven hours straight. It's jargon that just means "week".


People do die. It's called burnout.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: