why scaling doesn’t work - jez humble - GOTO 2015

https://www.youtube.com/watch?v=2zYxWEZ0gYg

See also:

• Lean Enterprise: How High Performance Organizations Innovate at Scale by Jez Humble and others (book)
• A Practical Approach to Large-Scale Agile Development - Gruver and others (book)

---

water-scrum-fall - one very common approach to agile is to drop scrum in the middle of a the same old waterfall process - long business lead-in: study + approval and then design + planning THEN do the development work in scrum THEN do the integration and QA and release and operations.

76% of survey respondents said they did no economic analysis at all when planning software projects. most planning time is spent on estimating costs, which have a very low value as indicators of project success.

the most important unknown variables in a development project are: will the project be cancelled? and will the product be used by customers? the cost of developing the product is not relevant!

because it’s so hard to get things through this planning process, the most important bits are gummed up with lots of other not-so-valuable things, in giant projects that then get cut back up into little pieces after approval, try to get re-assembled for release, and often don’t work.

“cost of delay” is a way to cut through to what matters. for each bit, estimate the cost of NOT producing it, the opportunity cost of not delivering, as cost-per-week or cost-per-month. LIKELY... a few will have very high costs, some others will be much lower, and many/most will be close to zero. source: “black swan farming using cost of delay, by arnold and yuce, bit.ly/black-swan-farming.”

the implication is that all the teams should rally on those few features that are MOST important, valuable, costly to delay. break the most important parts free of the clutter.

what we should do:

• don’t optimize for the case where we are right - all of normal project planning ASSUMES we are doing the right thing, but that’s NOT known, and often features have zero or negative value.
• focus on value, not cost =>
• create feedback loops to validate assumptions =>
• make it economic to work in small batches =>
• enable an experimental approach to product dev (and process improvement)

requirements

• users don’t know what they want
• requirements are the business leaders’ story
• don’t want requirements - want hypotheses!!
• if you write user stories without the “so that” then you don’t have hypotheses

impact mapping - gojko adzic

• work backwards from the outcome
• what is goal => who are stakeholders => what can they do to help or hinder progress toward the goal => the things you can do to support/prevent those things
• usually we pick one “thing” and that’s all the developers see, not the whole map
• value of impact map is not the map, but the understanding that comes from creating it
• THEN... what is minimum amount of OUTPUT to get the maximum amount of OUTCOME.

hypothesis-driven delivery (better user stories) - jeff gotthelf

• we believe that [building this feature] for [these people] will achieve [this outcome].
• we will know we are successful/correct when we see [this signal/behavior in the market/system].

experiments - user research - UX/design thinking evaluative vs. generative + quantitative vs. qualitative examples:

• surveys (generative/quant)
• a/b testing, analytics, key metrics (evaluative/quant)
• usability: hallway usability, concept testing (evaluative/qual)
• contextual inquiry, follow-me homes, mental models, ride alongs (gen/qual)

 => how can we get this data without building out the whole thing?

online experimentation at microsoft: 2/3 of experimental features ADDED NO VALUE

 => need to run experiments to prove out value - which can also be negative!

can use same experimentation discipline in product development as lean uses in process improvement

experiments => continuous delivery

need to understand organizational goals from the very beginning, then take an incremental process improvement same as product development - a practical approach to large-scale agile development by gruver, young, fulghum

four steps of the toyota improvement kata model (1-3 planning, 4 executing)

1. understand the direction or challenge
2. grasp the current condition
3. establish the next target condition
4. iterate toward the target condition

this practice = “gettng better at what we do” needs to be habitual practice (kata) - don’t specify the action plan... work incrementally, experimenting and testing for outcome... more like a daily scrum... what accomplished, what to do next, what in the way?

the plan for the whole month can be a short list of major themes and exit criteria we’re aiming to achieve