Comment by eecc
5 years ago
I’m sorry if I sound harsh. The problem is not a matter of better or worse “alignment”.
It’s just poor quality planning and execution.
Your team is just improvising, figuring out as you go, what is exactly that you need to build.
It’s not even Agile. Agile is about tight loop upfront planning, and avoiding last-minute distruttive changes and meetings...
> 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)
> It’s just poor quality planning and execution.
Potato potato. If you can get away with "poor quality planning" in person but not in remote, it doesn't matter what you call it.
You get 11 weeks until Demo Day. If you spend it learning how to plan better you've already lost.
Well, that's assuming you still don't already know how to plan or even put your thoughts on paper.
If that's the case, you shouldn't be in the business unless you're in a junior/apprentice position (which is fine, one has to start somewhere.)