In the spirit of that second paragraph - focusing on outcomes, not specific implementations - here's a rewrite:
Original:
> So…what’s the way out? It’s a smart focus on clear outcomes, not output, with roadmapped outcomes replacing planned milestones, with trusted product teams, not project teams, empowered to vet assumptions and discover the minimal path to value.
Rewritten:
> So… what’s the way out? It’s a focus on clear outcomes, not output. There should be dates for when specific outcomes should happen. Teams should be empowered to find the minimal amount of work needed to achieve the outcomes.
It's a really wordy way to say what any good leadership class would tell you. Focus on what you want more than how you get it, and let your subordinates decide how to get it. Both good product teams and project teams are capable of working that way.
This kinda sums up my problem with endless agile vs. waterfall vs. whatever discussions. The interesting parts aren't really new ideas and the extra buzzwords add nothing.
Interesting, I’d interpret “roadmapped outcomes replacing planned milestones” to mean there should not be predetermined dates and deliverables (planned milestones), but rather, a sequence of value-delivering outcomes (roadmapped outcomes).
A relative order of outcomes could also work, yeah. You'll have a date in there somewhere, though, even if it's not driven off the amount of work. Could be "and if we can't achieve this outcome by X date we give up on this whole outcome".
Original:
> So…what’s the way out? It’s a smart focus on clear outcomes, not output, with roadmapped outcomes replacing planned milestones, with trusted product teams, not project teams, empowered to vet assumptions and discover the minimal path to value.
Rewritten:
> So… what’s the way out? It’s a focus on clear outcomes, not output. There should be dates for when specific outcomes should happen. Teams should be empowered to find the minimal amount of work needed to achieve the outcomes.
It's a really wordy way to say what any good leadership class would tell you. Focus on what you want more than how you get it, and let your subordinates decide how to get it. Both good product teams and project teams are capable of working that way.
This kinda sums up my problem with endless agile vs. waterfall vs. whatever discussions. The interesting parts aren't really new ideas and the extra buzzwords add nothing.