Two very interesting questions arrived today back to back. Some others on the internet may enjoy these questions, and possibly even my answers:
– How to “scale” the MVPs/solutions coming out of sprint teams. How does the MVP get transferred to the line and implemented? What’s the mechanism/support structure?
RESPONSE: this is what many groups call operations, or ops, and is ideally completely and robustly automated for speed and quality control reasons. This became so popular software organizations gave it the name “Dev Ops”, or connecting dev directly to ops, with a focus on automation. It’s the same in hardware, as you may remember from the Tesla examples, and the same in organization restructuring, as you may remember from MetaScrum.
– Release management: How to decide what to scale and when (this is basically the backlog of scaling – how to prioritize the right things based on value, what populations will be impacted, bandwidth of front line employees, etc)
RESPONSE: The bandwidth of front line employees piece, in my mental model, is irrelevant compared to how excited the front line employees are. If they are giving this initiative an NPS of 9 or 10 they’ll do it regardless of other load or simply (and rightly) de-prioritize the other load. To the other points: Most companies have more initiatives then they have teams, resulting in multi-tasking, and we’ve seen the negative dumpster fire of productivity in the course exercises. (I really just wanted to say “dumpster fire”, but yes 75% of time at work being a complete and total waste if there are 5 projects on deck for one team qualifies as that horrible). So value based prioritization is, was you eluded, the entire name of the game. And THAT is the strategy for which top management is responsible. I’ve seen many clients inspect and adapt their way into an excellent strategy, I’d love to learn more tactics for getting the strategy right or closer to right the first time, too.