Delays

Hello again. I was sick over the weekend and failed to get a post out on Monday. That has taken me on a tangent to thinking about delays.

So one of my projects is now effectively delayed because I was unavailable. I'm sure we will recover, I just need to make up for that keyboard time and we'll be back on track. But this impacts our delivery date. I now need to work some more hours durning the week to make up the difference.

Similarly, on another project we're running into a problem of stakeholder availability. A few of the stories we are working on have come to a halt because we don't have a complete understanding of the business needs or the technical details. Each of those stories has been delayed. An interesting side effect of this is that we are stretching our WIP limit because we're picking up other work to fill the gap. 

In the first case we have a pretty simple case of needing to just rearrange the only work schedule because of a lack of resources to do the work. It's a simple solve. Given more staff we could have just swapped in another developer to do that work. Since we don't have more staff, we just shift the schedule.

In the second case we have plenty of worker resources. The issue here is a lack of executable work, leaving worker resources idle. Whats interesting to me is that, as a result of having too many workers and blocked cards do to incomplete specs, we have pulled more work into the system to prevent idleness. As a consequence the load on the team, in terms of things to keep track of/manage is increased, but the productivity is unchanged as best and possible decreased if the cards remain blocked.

So this second case is whats most interesting to me. In an attempt to keep all resources utilized we add work to the In Progress list and mark other work blocked. In particular, because we're waiting on an external resource (Stakeholder) to answer a question. Back in the day we would have asked our product owner, who was sitting in the room, to help us get the answer and we would have actively pursued that answer until it was either found or determined to be unanswerable. In the later case we would discard all the work and move on to another card. 

We seem to have adopted a 'wait for the answer' posture, one that is even passive. That to me shouldn't be acceptable. Rather, we should work to engage the stakeholder in a manner that encourages them to give up the goods on demand OR have given it up in advance. 

In advance is a problem though. In my Shangri-La the product owner is in the room and ready to answer questions at all times, no advanced planning necessary; but thats not reality. In reality, where we actually live, the product owner/tech-lead team have looked at, though through, and triaged all the cards before the development team sees them. They have at least a minimum amount of information ready and available to answer the teams questions. [I'm not saying that info is necessarily on the cards, just that its readily available]

While this doesn't conform exactly to the 'A card is a promise for a conversation' ideal, if a card could be a proxy for pre-digested (by the PO/TL pair) answers to expected/common questions it will impart efficiency into the process of delivering the story.

I recognize that this is similar to the Definition of Ready that some teams use, but I see a difference in how it is applied. The DoR is typically applied as a gate keeper on the 'Ready' column for the team; if the check boxes aren't checked then the card can't be added. Rarely, if ever, do I see the Product Owner or Tech Lead using the DoR as a check list for preparing work; and when I have it's been an awful disaster. 

Somewhere between the DoR and a card with two or three words on it is an place where the Product Owner and the Tech Lead understand enough of the details of a card that they can answer reasonable questions about it without having to wait for an external stakeholder and/or a series of spikes to be completed. 

I'm way over my length goal here, so I'll save my thoughts on the realistic solution to this problem for another post.