Done Done, Half-Baked or Pie In The Face?
Given a situation where a team is dependent on a third party to deliver some critical piece, like an API to integrate with. If we see ways to slice the work into two types of work, that which can happen without the 3rd party work being finished and the critical to value delivery integration bit.
Would doing so be good advice? (Or will I end up with pie on my face?)
That is. Given a work package that has a bit “A” dependent on some external delivery and some other bits “B” that are required but can reasonably be completed without “A”, would completing B and waiting for A before doing the full delivery be a sensible choice?
Would B really be Done? or would it simply be Half-Baked?
Let’s try to unpack the situation and a few of the “it depends” and see if we can find some guidance.
What trade-offs and assumptions are at play here?
Let’s look at the alternative approach and maybe some of them will crystallize in the comparison. The most obvious alternate route is to wait for the full completion of the required delivery before starting our own work. What needs to be true for that to be good advice?
- We assume that we need not influence the development of the thing we’re dependent on. It will be fit for purpose.
- Cost of Delay / Lead Time is not influencing factor.
Depending on the level of uncertainty one might or might not be important, and if it’s a true third party maybe our feedback as users won’t influence the direction much. We’ll just have to wait and be happy with what we receive.
The second factor is true if, and only if, we’re not associated with the critical path towards delivery a value generating product increment.
Given this perspective let’s look at the proposed alternative and the question of half-baked-ness.
If there’s uncertainty in what needs to be delivered working on ‘B’ can help reveal a better set of requirements for those delivering the service to us. Thus we’re reducing rework and might early detect misaligned assumptions that might influence their direction or make our own effort irrelevant.
We’re also actively working on potentially shrinking the total lead time. That depends on what alternative work we’re not doing instead. Is the Cost of Delay reduction for A+B more valuable than the alternative delivery C?
There’s an inherent risk in starting and shelving B in that the completion of the integration A might very well induce rework that wouldn’t need to happen had we postponed starting B until seeing A.
Thus the answer here becomes: “It depends”
It depends on the value of buying information to potentially feed forward to the builders of A, the alternative value of other potential work that could be completed to generate value and the cost of delay function for A+B along with the risk of induced rework.
My Thanks
This post was the result of a conversation with my good friend Marcus Hammarberg coach extraordinaire constantly challenging himself and those around him to question common gospel. His question regarding the appropriateness of the advice we both commonly forced me to go beyond “yes, that’s a good piece of advice” and figure out why I think it’s so. For that I’m grateful.
