I don’t believe in sprints

I feel most of the criticism towards Agile coming from devs misses an important point: how it’s used to show the progress of a project to the people outside of the team.

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.

I agree to a large extent.

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.

Sprints when used correctly are invaluable to a development team. Source: My own experience as a junior dev and a lead dev on teams working in this methodology.

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 time - therefore they must carefully decompose work where that makes sense. Leadership commits to LEAVING THE DEV TEAM ALONE for that 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 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 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.

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.