I don’t believe in sprints

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.

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

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

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

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.

We don't do sprints. We don't do Scrum. We don't do story points. We have predictable, reliable software delivery on multiple products with an ever growing product development team of 65 people. It's all about measurement and mindful planning.

We are strict about structuring epics vs. stories vs. tasks, and make the largest deliverable an epic. Epics set the scope of what we want to achieve. Then we describe user behaviors / experience we want to enable in terms of stories. The engineering, deployment, and design activities needed to enable those behaviors / UX are structured as tasks.

We say when we want to be done with the epic and try to determine if the scope we have outlined for the epic is reasonable given the self-imposed deadline. Then we measure the growth of tasks in epics week to week. Tasks are expected to grow fast in the first 20% of a project and then start to taper off as more and more of the engineering takes shape.

If we're not following that curve, we hold a retro. If we add stories or change the scope of the epic, we hold a retro. We adjust scope downwards or we change the estimate. We communicate the changes to estimates out to customer-facing teams early in these cases.

The last large-scope new feature we built on our product was scheduled to take 4 months. They were behind by less than 2 weeks, and half the team were rookies. Oh, and no-one was asked to burn the candle at both ends to get us there. No saturdays. No 10pm conference calls between engineering managers and the dev team.

There are better ways to do reliable, predictable software planning than sprints.

For me the biggest problem with sprints is that they force a continuous flow into discrete boxes. An extreme example I've seen was when as a mid-level developer I was told not to pick up any new tasks, because everything we start needs to be finished by the end of the sprint, and if I start a new task now, testers won't be able to complete it before the end of the sprint.

Of course it was an abuse of the concept, but I hope you see the point - we shouldn't try to start every sprint with an empty board, because software development is continuous, and the fear of tasks "spilling" to next sprint, which I've seen multiple times, is just ridiculous.

To the author:

You don't like sprints or backlogs? Okay. So what's the alternative?

Take step back, think about the problem that agile tries to provide solutions for. Now start thinking about new solutions .. spend some time; then write an essay that makes a difference.

What is important however is some type of shared vision or general plan. Not all teams are lucky enough to even have that. Some people treat their job as a job. Some people treat their job as their life's mission. Much of this definition gets lost in translation in the middle.

In theory a team full of product-minded engineers / self-managing individuals don't need much to be impactful because they will know where to add value and make progress while being looped into the industry/customers.

As an engineer and an engineering manager I have worked in strictly controlled water fall, "no process", well structured sprints, kanban, and scrumban. They all have their pros and their cons, their costs and their benefits. It's a question of what works for the team.

Personally, I developed a preference for scrum style sprints as both an engineer and as a manager, because I prefer to work collaboratively where everyone knows what everyone else is working on and everyone gets a chance to have a say. Sprints with a heavy planning component work very well for that. But that's just my preference.

Teams should decide what method they're going to use and commit to making it work. They should also be open to recognizing when it isn't working for one reason or another and be willing to try something different occasionally.

The only piece of process I will always insist on is some sort of regular check in where we can introspect about the process and determine what aspects of it are and aren't working.

But the backlog is useful. I find it amazing how what seems like a great idea when I think of it looks utterly pointless when I see it still on the backlog 3 months later. It's a useful tool to deal with our tendency to fall in love with our ideas.

Without agile ceremonies, the quality of tickets can really vary depending on who is writing them. I think there's something to be said for a group of devs looking at a task and deciding if there is a clear AC and discussing how difficult that task is. Without these sorts of ceremonies you can get into situations where you work at a task for days, put the PR up and then get told "Oh we probably shouldn't do this". This has happened to me multiple times at my current and last job.

I also think that for certain types of people, the model of committing to a certain number of tickets for a certain block of time makes it easier to structure and plan that time. Certainly it does for me.

Assuming the originator of the concept of a sprint is Scrum (and it's a big assumption; normally I'd check, but I am lazy and somebody is clearly wrong on the internet), then the purposes of sprints are:

    - to set a regular cadence/rhythm to work, and to set up periodic checkpoints for inspection of the done product and adaptation of the work that follows
    - within a sprint, to produce a done increment that brings the team closer to the product
    - by the end of the sprint, to allow stakeholders to inspect the done increment, to observe if anything is being done wrong or in the wrong order, to collect the feedback, and adjust, if necessary, the plans against the reality
    - and then to repeat the same over the next iteration, and the next, and the next

This is all hard to do IMO if there's one running backlog.

The benefits of sprints I see is they're a useful time container for planning purposes. Eg:

- we can allocate larger pieces of work to upcoming sprints. This is done very loosely just to get some idea of what we can take on, and when

- we can allocate a fraction of each sprint to tech debt or platform improvements etc

- set a goal for each sprint which is some observable step forward. This has taken practice to break down the work into appropriate chunks which can be verified done

- record velocity across sprints just so we have a rough idea of what we can get done in a sprint (it will vary of course)

Yes, there is overhead from the planning meetings. But this helps all of us get involved with incoming work, which I think is better than tasks coming from nowhere without context.

I think the right methodology depends on the context of the business. If product teams need to work together towards something, or if there are competing project priorities, then sprints can help protect focus and provide finer structure than just "Q4".

Anyway, with a QA function, you need some kind of release cycle. I don't believe in prescriptive sprints where either developers are stressed to hit an arbitrary end of cycle deadline or developers sit on their hands because the phase of the sprint dictates no new work (which I've heard of happening in some particularly agile-diseased companies). I think a reasonably regular cycle that aims to ship what's ready fairly often is a good middle ground that keeps quality high, keeps the product evolving, and maximizes developer keyboard time (and of course you also need the ability to hotfix production occasionally.)

The only thing that comes close is "every efficient and productive team I’ve worked on has ignored the concept of sprints altogether".

Okay, but why don't do scrum meetings, pointing, retros, or keeping Jira up to date, work. There's nothing in the article to address that.

Great teams do not need additional processes to deliver value and they usually are more of an obstacle. Clear goals and a vision are much more important, as well as having an environment where the decision makers are the one implementing the solution.

My solution to this is waterfall, and charging for a rigorous requirements analysis process up front, which I, in turn, estimate the cost of by having the client submit their requirements (as they know them so far) in detail in writing up front.

I've been surprised in (the practical version of) agile how often time is wasted revising the same feature 5x that could have been done once if a modicum of time and thought was put into business and technical requirements.

I am however a believer that people do things for a reason, it does probably have advantages for R&D or inside technical product companies.

Note it's not useful in all (most?) scenarios or in all stages of a product's development.

When you are in support mode for a product that's stable, standing up something from scratch, working on a POC or experimenting with frameworks or libraries - it's not useful, use kanban or something else.

But when you are working on a/b tests or adding features to an existing product it's extremely useful.

When done correctly: You get a two-way promise between leadership and a dev team. The dev team commits to getting stuff done within that <sprint-length> time - therefore they must carefully decompose work where that makes sense. Leadership commits to LEAVING THE DEV TEAM ALONE for that <sprint-length> time - no priority changes, no "Product Manager Chad had a dream if we implement X we get 1000% more revenue!", none of that nonsense. This means for bigger efforts, you get <sprint-length> chunks of working code "done" at time. This in practice means the devs drive how much they can get done in a certain amount of time - if a PM wants an earlier date out the door, that's <x> fewer sprints of decomposed work that gets done.

The tricky thing here is the use of the term "correctly" above. Sprint-based methodology isn't a tool for management to dictate or predict performance and it's not a tool to micromanage tasking. If leadership DOES have this distorted view of it, then it is useless overhead to no benefit for anybody.

It's also not useful at all if only the dev teams practice it - everybody has to respect the commitments required to do sprint correctly - if they don't, use kanban or something else.

I disagree. There are, in fact, crappy teams. You might argue that it's a crappy manager that either allows that team to continue in its current form, or simply doesn't recognize that the team is crappy, and does nothing, but... there are crappy teams. There are combinations of personalities and skills that are simply not suited to solving the problem at hand, and nothing short of removing actual people and replacing them with different people will 'fix' anything. Again, you can say that's down to management, but it feels like a word game. The team itself is 'crappy' for the goals at hand - management/owners (crappy or not) need to recognize and fix that.

FWIW, Scrumban wasn't bad either, and it was way better for us than full Scrum would have been. The reason we switched was because we were basically operating like a Kanban team already, and the sprints were just arbitrary lines in the sand. We regularly had either a) tickets crossing over into multiple sprints or b) sprints we cleared out so fast that we had to start pulling tickets from the next one into the current one. And even after the switch to full Kanban we've kept the few Scrummy stuff that we like, such as biweekly retros.

I rank them as 1) Agile 2) Waterfall 3) Whatever it is this guy wants.

But to be fair, I've worked like this mostly in places that have also enjoyed a continuous deployment way of working, with possibly multiple releases per day. In other places I can kinda see the point for "this is the stuff that needs to go into the next release" kind of sprints, but even then I'm not sure it's an improvement over straight up kanban.

I kinda feel like Ockham's razor would cut the sprint from the ideal work method tbh.

You can’t talk about sprints unless you talk about the sprint demo: It’s the proof that the closed tickets actually represent completed work.

> … they’re designed for mangares 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).

That’s one take, but managers are just as likely as anyone else to B.S. their way through the tickets: “oh yeah that’s pretty much done”. The sprint demo clarifies what “pretty much” means.

> … When you’re on [an efficient team]… then it’s easy to see how everyone else mistakes the bureaucracy around the work for the work itself.

This is extremely true, and probably the main failing of any project management method.

> … the backlogs, the sprints, the points—is pure bureaucracy. It gets in the way of productive folks…

Again, we can’t talk about the sprint unless we talk about the sprint retrospective: It’s there to help the team identify tools and processes that are inefficient, and adjust incrementally through automation, elimination, or modification. One of the things that might get eliminated is the fixed interval sprint. Or replacing relative-size estimation techniques (“story points”) with something more rigorous.

That “sprints” are used mindlessly is frequently true, but we should not dismiss them mindlessly either.

This is the fundamental reason why sprints exist.

If you exist in an environment where all team members are highly motivated, consistent, diligent, and pulling in the same direction then yes, sprints are a distraction, but it is my experience that teams that are genuinely like that are rare as hen's teeth.

For myself, I'm the most productive when I

- Am able to influence what I work on, and choose how I solve a task

- Have tasks lined up in a front of me that I can choose to work on

- Am in a state of flow, where the tasks in front of me roughly corresponds to my skills.

In other words - to me - a good project manager makes sure that there are plans for what to work on next and that the tasks roughly corresponds with the teams strengths.

Now, that roughly corresponds with good "backlog grooming", but not sprints.

Basically, I think Kanban works much better.

When a sprint starts, what QAs people are expected to do ? When the developers finish, and QAs start testing, what developers are expected to do ?

It seems to me that this forced synchronization is just pointless and harmful.

Where I work, we handle "sprints" just like checkpoints. This is in developing stage, this is in testing, this is done. It's expected that almost everything spans more sprints.

Each tool should be evaluated (and periodically re-evaluated) to see what its 'leverage factor' is for your situation. For every unit you put into it (time, effort, money) how much do you get out of it? The best tools give you a 10x or better leverage factor. If a tool gets in the way (i.e. it has a 1x or lower leverage factor) then it should be ignored.

Some tools are just bad (they take more time and effort to learn and to use than they save you) and are generally weeded out. Some are great for certain situations but bad for others.

If sprints (or any other tool) are not helping you and your team, then try to figure out why. Is the tool just not a great fit for our situation (e.g. using a hammer to try and fix a car engine)? Are we using it wrong? Is there something better?

Too many companies and managers go for the 'one size fits all' approach. "This worked at my last company so it must work here too!"

Related to this is that sprints and their associated concepts mechanize and formalize something that may or may not need such. Applying something like Scrum almost always has one engaged in motions that are disconnected or even counter-productive to the local environment. That said, it sure is a lot easier to pick a methodology off the shelf than it is to engage in sober, thoughtful, and rational assessment of your situation's organizational needs. There's also risk inherent in that too, but one effective counter to that is to incrementally add/subtract process as needed.

Given the above, I consider process-heavy management to be a signal for prospective employment -- on the very much negative side. It tells me a few things, mainly about the way management's group mind works and also about what my future role in such a group would be (i.e., more part of organizational machinery than a creative agent).

The last point I'll make is that I just find the experience needlessly draining. A job typically lasts years. It's more of a marathon than a sprint. If it was a marathon with a few necessary sprinting periods, that might be bearable. If you really are sprinting constantly (the next sprint starting immediately after one concludes), that's a good way to generate burnout.

But a bad management style would still trump this.

I see them like CPU cycles, but for a team. They are a heartbeat keeping team members in sync. It's all about answering what's my next task when I'm done with the current one. If you I work alone, or in a very small team, with no external stakeholder, then I can answer that "just in time" and don't need cycles.

But if I work in a larger team and/or with external stakeholders, then it's not practical to do this "just in time", gathering everyone to decide what should be the next task, every time a team member completes a task. In that case, we need to batch the planning work. That's what cycles are for.

I agree with the author that too often the process feels unnecessarily bureaucratic, and I really dislike the "sprint" terminology, but I wouldn't throw the baby out with the bathwater. Cycles still have a purpose.

There are some great, as in large, problems with software development, as a result of having multiple parts developed by different groups, or even by one person at different times. The parts have to work together.

It is easy, and I have seen this happen in multi-million dollars companies (plural) for groups to go off, develop their parts and for the parts not to work together. Boom. A sprint is designed to ensure that detecting this failure happens early rather than late.

Can you have a sprint that does not help this situation? Yes. And if you do then the sprint is just foofaraw.

The other problem is that it is easy and somewhat natural to write 90% of the code. Which does nothing. 90% of the code is meaningless. What works is the issue. No one needs or wants code. They need or want functionality. I have written some really really cool code that does nothing. It was 90% of something, but unfortunately had to be rewritten in order to be functional.

The second use of a sprint is to show functionality. A sprint to have 92% code completed is nothing. Can you show (to me or yourself) that 90% of the functionality is there? The difference between 90% of the backend API's being functional (and being able to prove it) and 90% of the backend code being written is monumental.

There is a final use of sprints. As a manager you can appear to know what you are doing by organizing sprints, when in reality you have no clue whatsoever as to what you are doing.

If you want to be a good programmer, you will use sprints with yourself. I'm a sole developer and when I use sprints by myself I am much more productive. Much. [updated for spelling and clarity]

In an even earlier job, I saw an overzealous 'scrum master' certified engineering director trying to ticketify everything with Kanban boards and burndown charts etc. Engineering teams under them hated it. It was the least productive period for a division of 100+ engineers I ever saw.

Moral of the story: methodology matters a lot less than culture and talent.

Worse still some of the things that are advertised as 'agile' actually violate the principles. The card wall was supposed to be about as light a representation of ongoing work as you could get and facilitate the interactions with the teams. Unfortunately, tools like Jira change this to be an over-engineered process and tool (which violates point one of the manifesto). Remote work has not made this better.

Sprints and pairing become tools to keep devs on a hamster wheel. Always productive, in theory at least.

Leaving this to the side, I've seen sprints done well and badly. More often than not teams can't manage to point cards effectively. I've had a couple of teams where things just end up in a middle ground constantly (everything is a 3). The exercise of comparing this card to some previous representative card is too hard (and is itself prone to problems).

Retrospectives, can be a useful tool, or they can be a back patting exercise. Showcases without a customer in sight (put your hand up if you're the "customer proxy").

Having said that, some of the behaviours can be really useful. Breaking down overly complex cards as a part of planning helps define the work. There are other opportunities to do this, but backlog grooming / planning sessions are one place.

Having the team discuss cards and talk about complexity often reveals unknowns. I've seen a bunch of examples where things will be caught because of a dev/designer/product manager can see something that wouldn't have been identified if someone just started working on it.

Imagine running a marathon without mile markers. Sprints are like mile markers they help you know and adjust your velocity and capacity to reach the end goal.

Without these sorts of tools you are just running without any sense of achievement or tuning to your teams performance.

Basecamp’s “shape up” method is a nice way to coordinate work when everyone has their own todo list.

Most of the time with the articles, the answer to "X done poorly" is to switch to "Y done well" but doing X well would have likely worked too.

Personally, my most enjoyable job as an engineer was when I worked on a project by myself in 1 week sprints. I spoke to my manager twice a week: 15-30 minutes Monday morning for "sprint kickoff" and 15-30 minutes Friday afternoon for "sprint wrap up" and how I spend the rest of the week was up to me. When a second more senior engineer joined the project it was even more enjoyable to work on it together in the same sprint format.

Having a great manager also helps a lot!

Sprints ARE a tool used for planning, but not just by managers. A team can use their historic sprint data to PUSH BACK against their managers and say "No, we won't get this done in time. Now go away and fix your plans.".

Other people mentioned this is a bad strawman...that's an understatement. But I think that's what the author wanted.

It's easy if there are only maybe 2-5 people involved, objectives are clear and not conflicting.

Usually though, you can't afford to implement every idea you have, you need to maintain old stuff while also making new stuff, teams have non trivial dependencies on each other's work, and time predictions are nebulous at best. Also software managers are generally software engineers first, not managers.

Is sprint good at these things? I don't think so (though I never managed a team with sprints, only saw other teams do it badly). But is there a better blueprint? I'm not sure either. It's a hard problem, and hearing about what doesn't work isn't so insightful.

Sprint.

I do not want to rush through the work and squeeze into arbitrary time period but do it properly in the timeframe necessary (and not more). The hastle and rush atmosphere surrounding this word is repelling to me. As well as the 'stand-up'. Are we on exam in the school or what? Not being adult coworkers but people in entertainment or support group to present to each other?

In other hand a flexible communication and progress tracking system - especially in a fairly unpredictible business like making a novelty product - is essential in teamwork and I know no better than something like this. But this childish naming makes me suspicious about the intention and goal of those coined it...

That said, they aren’t magical. They are often misused. Not every team and every project needs them or is faced with any of the problems sprints set out to solve. And there are lots of ways to build good software.

Unless you are part of a completely autonomous team, you need to communicate progress in a way that’s more informative than saying “trust me and leave us alone, it will be delivered in X months”.

Spending time in meetings or writing down and discussing what you think that should be done next indeed can create an overhead (even more when the frameworks is abused or done wrong), but epics, stories, sprints and demos provide a more detailed way of communicating and demonstrating progress to whoever it is relevant.

There are some general guidelines, there is some amount of this that can be taught (not enough to sell a course or certificate), but mostly project management outcomes are dominated by the terms of understanding the domain in detail and the people involved as holistic human beings.

Paul Graham said that the management of hackers for someone who isn’t a hacker can be summed up as “give up”.

Don’t shoot the messenger please, but I agree with pg.

I like the concept but dislike the rigidity. Perhaps it might help if sprints were retroactive, that is you get shit done, create jira,etc... and it will be reviewed as things done in the sprint, instead od micro-managing tasks, set goals like "complete feature X and bugfixes".

If you work at a product shop, you might well be able to do without them.

If you build software for clients, the planning is VERY important in order keep the client happy. Knowing ASAP that the project is going to miss a deadline/budget/feature is key to whomever manages the relation with the client.

This is why we do sprints and estimations: to know how the project is going so we can update the client ASAP (or find another solution) when things are off.

1. Maintain a To Do list for the project.

2. When a developer is available, he/she/it will pick the highest priority task to work on.

3. Use the To Do list when negotiating new features with stake holders. They have to decide where in the priority list the new task is added.

4. Break very large tasks into smaller step by step tasks that can be developed independently.

It’s simple. It works. I have delivered successful projects most of my career using that method. As a single developer and when managing large teams of developers.

If you want a well-reasoned discussion of where the waste is and isn't, I highly recommend Allen Holub's talk #NoEstimates [0].

[0] https://www.youtube.com/watch?v=QVBlnCTu9Ms&t=7s

Sprints and standups are degrading tools to enable extremely subpar management to maintain their role.

Tell me why a properly functioning agile shop even needs a manager.

I've worked with two-week and one-week sprints, and generally found them very helpful, but more helpful with better PMs.

But they are not the problem you are trying to solve, just a tool.

I like the concept of false idols in christianity: you must orient yourself toward truth and love (building something good and truthful).

That must be your highest value. Money, prestige, UML charts, Sprints, those are all false idols, they will lead you astray if you worship them.

Only worship truth and love.

like religion, I've seen Agile done poorly (extremely damaging and counter-productive) and done satisfactorily (not harming anyone with some mild benefit). theory is only half the equation, a big part of the equation is methodology and execution.

I agree. Most teams are mediocre though. A lot of processes have the goal to limit risks due to bad teams.

Looks like this Edsger Dijkstra's phrase never gets old :)

It boils down to needing a form of alignment, you can't have team members running around making it up by themselves as they go.

How you achieve alignment and shipping things customers love is irrelevant, just fucking achieve it.

Also helps that companies love to employ clueless people to organize the sprints and those tend to care more for jira to look good, than actual work.

I’ve worked in sprints. I’ve been a facilitator and an IC and now manager (aside from sprints).

A bad team won’t improve with sprints.

Similarly a good team might not always benefit from sprints.

Almost every team I’ve worked with has improved with iterations and interactions.

The best team I’ve worked with used sprints and communicated with stakeholders well… which in turn spoke true to the agile manifesto.

I want to see the code produced by this non-system; and to learn its longevity, particularly beyond when key early contributors have left. I want to see the applications produced by that code and to learn the size of the teams, departments and companies around the products. This article carries little weight without some of that context.

There's no meat to this article, just a rant about some management style the author doesn't like. The author goes so far as to say that only the managers can fail in software. This sounds unbelievable to me because we're all humans.

Sprints, and points, are not JIRA. Points are not Sprints. Jira is not Scrum. These are all orthogonal tools that can work well together, in my experience. They don't always work well together. If you're doing Scrum well, you'll inspect what's working and what isn't, and change it. It's possible to change so far from Scrum you've moved on from it... but I haven't seen that happen and yet still found it useful in most places I've worked.

People who dislike Scrum often complain that the defenders regularly say "well, you're not doing Scrum if you define it like that". They throw away the whole argument. Scrum that isn't Scrum, isn't scrum. You can't not-do a thing and then claim that thing doesn't work.

< / rant >

But how do you truly know WHAT you should on focus and deliver without having a clear understanding of the broader picture and without breaking apart work for the week, especially with a team where everyone is at completely different steps and working on completely different things?

All the ceremonies in the world aren't going to change either of those things.

It's just a rant from someone that thinks they're too good to be managed, probably that kind of engineer that has 10 conflicts a week with everyone in the company because they won't budge on their unfounded personal opinions.

If not, then chances are the team will need some guardrails, that’s what agile and scrum offers. It’s a place to start.

Just because you don’t believe in having a system to break down work doesn’t mean it isn’t useful.

Personally, I’ve seen the alternative in action and it always leads to burnout.

And if the work gets too much then I guess we just work harder to the bone —- because woe us if we should possibly have to grow and delegate, let alone in a scalable, organised and structured way?

You’re the lead of an 8-person team. How do you get everyone rowing in the right direction and shipping software? It sounds like you’d just leave everyone to sort it out themselves and believe they will build the right thing and ship it on time.

I don’t think sprints are a required practice. I’ve used them with teams simply to help shield them from micromanagement and get them used to iteration cycles. They were held up on releasing anything until a huge batch of features was perfect. Only every deploy into production was met with a week or so of overtime fire fighting because the amount of change they were introducing to the production environment was too large and their staging environments were always under provisioned and didn’t have the same load. Sprints helped them break down work instead of crunching for months at a time.

After a while they didn’t need it anymore. So you change things up.

Where it goes wrong I think is when people start copying the practice hoping that following the rituals will grant them good software.

You still need something though. A little planning goes a long way.

His ideal world works for a team of engineers that have no manager, no deadline, no collaboration with other teams, etc.

Basically it works for a personal project. That's it.

Use their crappy tools against them and make sure your projects fail. You’ll be getting another job next year anyway.

Of course its more convenient not to worry about sprints and time/points and "just work", and that is usually the case in startups or backend teams where the stakeholders are all always present in the same room, but once you add more layers to the organisation chart it becomes harder to track what everyone is focused on right now and that they are planning to do next without sprints or something similar.

"Spirits don’t help organize things, they’re not a useful organizing tool"

"Good teams don’t need spirits to get good work done."

https://youtu.be/f-ULT_Ic4qk

I absolutely hate useless opinion posts like this. They're incredibly vain. There is zero substance to the authors argument beyond "sprints are inconvenient".

I can only assume the person who wrote this lacks much real world development experience, because anyone who has worked at multiple companies will tell you there is no one size fits all way of doing development. Post like this are pure Dunning-Kruger effect.

https://www.youtube.com/watch?v=zPT-DuG0UjU

This blog post is my love language.

If I personally have to check with someone, each day, to get good work from them, then my preference is to fire that person and hire someone else who I can trust. If I need to check in with a person every day, then I'm micro-managing this person, and I have to wonder why they need to be micro-managed.

This is different from me being available, every day, to help them, when they need some specific help. If they are being blocked by something, they should feel free to reach out to me and ask for my help. But a daily standup assumes that they won't ask for my help when they need it, and therefore I need to force a moment of conversation each day. Again, it is easier to fire such people and hire someone else who I can trust. I'm working in the USA where it is easy to fire people. If I was working in Europe, where it can be difficult to fire someone, then I would instead seek to get people traded away from my team, and I'd see if there were others in the organization that I could get to move to my team.

With senior level software developers I find it is often enough to meet with them on Monday and ask "What will you accomplish this week?" and then chat with them as needed during the week, and then on Friday check in with them and ask "What did you accomplish this week?" If they didn't accomplish what they thought they would during the week, then we can talk about why. With junior level software developers, I usually have to check in with them more often, which is fine. Usually, with each person, I figure out what is the ideal level of support that is needed. Every human being is a unique individual with unique needs, which is why the daily standup is a bad idea. It's important to figure out who is working for you and tailor your support to the needs of that individual.

Direct, honest communication cuts down on the need for rituals and ceremonies such as a daily standup meeting, or grouping work in two week batches.

Often, when I speak to managers of tech teams, they say the main point of two week sprints is to offer transparency to the leadership above them about what progress can be made during those two week sprints. But again, direct, honest communication with the top leadership typically does a better job of explaining what to expect, as well as to explain why something is delayed, if something is delayed.

To the extent that two week sprints serve a mostly political goal, I'd rather address the politics directly. I expect people below to reach out directly when they have something to say, and I do the same to the folks above me.

None of this precludes tracking how much work is being done every week, or every two weeks. If the work is being tracked in a tool such as Jira, it is still possible to add up the number of points that are being done each week. Nothing that I say here suggests that I'm against gathering metrics and trying to improve those metrics. But many of the rituals that are currently advocated for Agile development processes waste time on meetings that could more easily be worked out informally in a series of quick one-on-one conversations -- a style that is actually agile, rather than burdensome and officially Agile.

In general, meetings that waste time should be reduced to a minimum. Conversations that have specific purposes should be encouraged. Large group meetings should be reduced, and one on one meetings should be favored. This style has worked well me over the last 20 years that I've been doing this. As to the details, and nuances, of getting the most from one on one conversations, I develop this theme in my book "One on one meetings are underrated, group meetings waste time."