Less is more agile

Perhaps it could be expanded upon with: Don't estimate, solve the problem.

Solving the problem may involve estimating, but blindly being asked "How long will this take?" without exploring the entire solution space, often without even being aware of what problem needs to be solved with that information, is when you get failed results. A time estimate may not even be the right tool to solve the particular problem.

If you are the one asking "How long will this take?" you have already recognized that you don't have a satisfactory solution yourself and need to defer to the experts, so why obscure useful context from those you are deferring to? While there may be some sense of pride in being the one to come up with the solution, such emotions aren't suitable for the workplace. It's okay to give someone else the 'glory' if they have the solution and you don't.

What a crock of poo. No security as ever. Fowler now bothers to mention Threat mOdeling. You engineers are rubbish. You are so lazy, and hate security so much. Even in healthcare and medical devices. Security is EASY! but alas, most of you and the management drones do not have a clue.

Agile has killed more people than Waterfall. Terrible. You should all be ashamed of yourselves. Do try harder! lol

Nothing has resonated more with the way I work than this.

Plan, act, reflect in practical terms. Build, measure, learn in lean terms. Vita activa, vita contemplativa, and sensemaking in academic or philosophical terms. Alistair Cockburn, Allen Hollub, and Bonita Roy in software terms. It’s all a cycle.

It doesn’t matter which page from which of those playbooks you take from on any given Sunday. They are remarkably consistent.

The observation I’ve made is that friends who succeed at this deftly avoid agile cliches and their teams are focused and efffective while checking all the boxes from crystal clear or spolsky’s list or accelerate.

This points to the fact that agile has become the cargo cult dogma it set out to replace twenty years ago.

The way I use these words goes like this.

Agile is what managers who have no clue about the agile manifesto do after they attended a mandatory, 6 hours long SAFe training. "Doing Agile helps the coding monkeys output three times as much as before? Gotcha!" When you prescribe the same sprint start day across the entire organization, that is Agile. If you have 6 weeks sprint commitment, that's Agile. When all teams need to estimate stories using Fibonacci, that's Agile. When the dev team needs to commit how much time they need for a feature that is planned for next year Q4, that's Agile. When the company needs an certified coach, that is Agile. When I need to create a Jira ticket and got it approved by three people to change the name of a small class, that's Agile.

I use "agile", when a company or product team understands that when writing software, you need to adapt to the things you find out. You don't know what you will do in 27 weeks and there is no point in story point estimating that stuff a half a year in advance. The company is agile when one team can use Scrum, another team can do Kanban, yet another can do whatever they come up with that works for them.

A lot of this really resonates with me as a manager of dev teams, but once again the very unhelpful advice for "how do you figure out when you'll be done?" is "refuse to do it". If an executive is asking me when we will deliver something this is a completely valid question. It's how everyone outside software development lives. If lean aglie can't give me a way to shape expectation of what we're building AND answer the delivery question we're stuck with BS agile, or we might as well go back to waterfall which (accurate or not) has always been very clear with a delivery date.