Thread by @tastapod

[another thread]

Great question, thanks @girba. I've been focusing on the supply side. On the demand side I talk about internal and external demand. External demand is stakeholder value. Internal demand is improving our ability to deliver. This is where the kaizen happens.

https://twitter.com/girba/status/1022424779759013888

@girba In most delivery contexts I see, the team has to fight for internal improvements, hide them among other work, squeeze them in the gaps or just not do them. From a product management perspective, the PM doesn't know how to assess the value of this either, so that's an unfair ask.

@girba Let's say I have a monolith I want to break into small components, which is a common scenario. Do we down tools for a bunch of time to do this? Do we set up a SWAT team to do it off to the side, and worry about The Merge later? Do we just gaze wistfully at Netflix and Amazon?

@girba Instead I frame the desired future state as enabling constraints, and plan to deliver the work in line with those constraints. For instance we know that if we can just pull out Component X it will make it easier to do work there, and there is lots of work coming up on X.

@girba Nothing really in the pipeline for Y though, so although we could break that out too, there is no benefit there (unless it reduces our Failure Demand by making it easier to reason about problems in that area, but that's a tangent).

So we describe two scenarios:

@girba 1. Do the work in X the "old way", which tactically might be quicker but means we aren't able to get the orders-of-magnitude speedup that a cleaner architecture would give us.
2. Do the work in X (but only in X) the "new way" which means some extra time in engineering.

@girba So I package these up as internally facing "features", where the stakeholders are developers whose lives will be easier, and external features which are your more traditional backlog items.

Now we have a choice to make. How much to invest in each? Back to quarterly planning!

@girba Each quarter we agree the proportion of external vs internal investment, before the teams self-select into the work (aka Big Room Planning or Delivery Mapping: ).

Some quarters we have to get stuff out the door for customers. That's ok.

@girba Other quarters, the customer is pretty happy and we can move the lever the other way. When I first do this with programme teams they often double down on the tech debt side, and go for e.g. 70% internal vs 30% external capacity planning.

@girba However, as @jezhumble says, this capacity is only /the capacity left after Failure Demand/. In other words, if 80% of your time is taken up firefighting, fixing things, stuck in post mortem meetings, etc. then it's largely academic how you slice the remaining 20%!

@girba @jezhumble So, you want a healthy mix of:
- identifying and reducing sources of Failure Demand
- external demand to delight customers
- internal demand to a) delight the team and b) increase your capability to do both of the above.

/end