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.

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.

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

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.

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

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?

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.

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.

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.

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.

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.

Do you mind defining this?

"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.)

> "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?

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.

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...)

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.

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

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.

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.

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.

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.

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")

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.

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.

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.

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.

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.

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

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

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.

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.

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?

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.

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

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.

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)

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.

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

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.

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.

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.

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.

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.

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.

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

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

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.)

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.

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

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

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.

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

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

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

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

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.

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

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.

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

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.

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

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

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.

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).

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.

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

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

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.

https://linear.app/method

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 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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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!

Now you understand sprints

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?

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.

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".

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.

Because your organisation answers to shareholders on a quarterly basis.

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.

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.

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.

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.

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.

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