If the outcome is the behavior change that creates impact, and the output is the work that creates the behavior change, then you can think of this as a chain of hypotheses. You’re betting the output will achieve the outcome and you’re betting your outcome will provide impact. Agile distracts from this when it says the best measure of progress is…
“ This is the problem with the commercial world. All too often they will jump onto a buzzword and think that being seen as buzzword-compliant will mean something out there.”
It’s clear you’re misinterpreting the post. We are saying the same thing.
“ Companies that still use development and delivery methodologies with bureaucratic practices and processes” … most agile transformations do not get you out of this bucket. “Waterscrumfall.”
Scaling is almost a sort of Trojan horse. It’s a very odd topic. It’s typically approached completely backwards. Really you should only scale something after you’ve totally nailed it. Notice that’s not what most orgs do. They’re looking to “scaling” as a general fix to the way they work. Makes zero sense.
100% agree with that last statement. Excellent post btw.
Scaling is an odd duck. IME it seems to largely pertain to efforts with way too many people involved, where org is designed around the number of players who need roles more than the number of players actually needed.
Changes in technical direction are important. I’m talking about pivots at a higher level than user stories though. Typically someone is still dictating to the Agile team what will create value. Call it “X.” The team’s iterations are more about how best to implement X. They’re not about saying “Maybe we should do Y or Z instead.”