← Back to context

Comment by ascar

5 years ago

> It’s not even Agile. Agile is about tight loop upfront planning, and avoiding last-minute distruttive changes and meetings...

That's an abomination definition of agile, probably influenced by scrum. In the agile manifesto it says nothing about "tight loop upfront planing", however it does explicitly say[1]:

> Individuals and interactions over processes and tools

> [...]

> Responding to change over following a plan

While that doesn't mean all planning is bad (it isn't and the manifesto acknowledges that), the planning is not the agile part, it's the leftover of the original traditional management, because it is necessary to a certain degree (e.g. for alignment but also for a lot of other business related tasks).

If you're running a pure kanban approach, you don't even plan in tight loops and I had much better experience with that (and a single team lead with a good strategic vision) than I had with Scrum. Scrum is just easier to handle for big (old) organizations and gives developers some protection from bad management.

[1] https://agilemanifesto.org/

> That's an abomination definition of agile, probably influenced by scrum. In the agile manifesto it says nothing about "tight loop upfront planing", however it does explicitly say[1]:

Sure it might be an abomination, but if we set the rhetoric aside for a minute we should consider the option that the context where Agile is applied isn't just RoR rockin' startups in the Bay. Lets call it dilution perhaps?

Besides, there's context. The Manifesto was drafted in a world still reeling in RUP and floor-wide teams marching towards quarterly releases.

That wasn't sustainable, but neither is "responding to change over following a plan" if that means moving targets every other day. That's a recipe for burn-out, and sprint commitments are sacred.

So yeah, context: respond to change means reassess every some sprint, not pivot 3 times a week.

/s (tongue in cheek people, life's too short for zealotry)