I don’t believe in sprints

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

The best class was a beginner's C class, and I was eminently suitable to teach it, because I was a beginner C programmer myself /s. By week 3, they were well ahead of me.

It's evidently possible to deliberately build a great team; but I have no idea how that's done. I don't know much about recruitment, and I certainly don't know how you can bring together a team like that C class.

I've literally had people say "you're doing agile even if you don't know it!".

You can't nail them down, it's always "oh that works? yeah, that's agile. Oh, that doesn't work? you're not really doing agile".

---

And now let me say, I don't like scrum because it's a shitty way to write software.

There's really only 2 ideas in agile that are useful.

1. iterative development, and

2. evaluate and change

That's it. The rest don't matter and are often actively harmful.

You don't need scrum masters, PO's, sprints, story points, ad nauseum.

Can they be useful? Maybe, it really depends on the scale and needs of what you're building, but I'm going to argue that outside of business analyst, these roles should be developers that take responsibilities. yeah yeah, inb4 "scrum master should be a developer!". Ask yourself this. What is the difference between a tech lead and a scrum master? answer: scrum master is considered a career, tech lead is considered a skilled developer.

The problem is creating these roles puts barriers between people. It prevents developers from developing an understanding of what they're actually doing. None of these roles are useful outside of QA and business analyst, and even the BA role can be done by developers if they have communication skills. All a BA is going to do is ask questions of the business.

I would argue the word phrase 'software development' should replace 'agile' in that sentence.

I liken it to boiling water. It's messy and chaotic. You'll eventually reach the goal, but until that happens you must be comfortable with a bit of chaos. Attempting to remove the chaos from software dev is like trying to tell mozart not to practice. You'll never get out of it what you think you will.