MH WorkSpace
Main Website


WorkSpace | RecentChanges | Preferences | Random | Index | Search

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

See also:

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,”

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:


impact mapping - gojko adzic

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

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

 => 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

WorkSpace | RecentChanges | Preferences | Random | Index | Search
This page is read-only | View other revisions
Last edited September 27, 2016 12:46 pm CentralTimeUSA by MichaelHerman
© 1998-2020 Michael Herman and, unless signed by another author or organization. Please do not reprint or distribute for commercial purposes without permission and full attribution, including web address and this copyright notice. Permission has always been granted gladly to those who contact me and say something about themselves, their work, and their use of these materials. Thank you and good luck! - Michael