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:
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)
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