Our director of engineering is a great evangelist of Agile workflows, and always likes to remind us that “work in progress is a risk to be managed.” Basically anything that’s not done presents a chance of uncovering blockers that could throw off what we have planned for our sprint.

Because of that, we want to develop a good sense for how much can be accomplished in a single sprint. If the work is not completed, it lets us know that there were difficulties along the way, and maybe a much needed conversation never happened.

I was speaking with my product manager about hidden work recently, because we were concerned that some tasks on the sprint were running into blockers, but the POD was dealing with those blockers by completing other tasks that were on the backlog, not part of the current sprint.

In a small startup environment, work in progress doesn’t need to be managed as tightly. You likely don’t have product managers, and some fires can have the whole company thrown at it to get it resolved quickly.

Once you get past about 30 people, that stops being an effective strategy. Different projects and products can have updates running in parallel, often with overlapping parts. Because of this complex interweaving of tasks, it becomes more and more important to make sure things are running roughly on time, or that you know who to talk to when things go off the rails.

In this case, individual POD members were taking the initiative to realize that a task was blocked, identifying the work to unblock the task, and just doing it. The initiative is admirable, but it also caused some sprints to fall behind. The product manager and I discussed how we could make sure the sprints were still running on schedule, without taking away people’s autonomy. The answer came from another commonly repeated piece of advice, “as soon as there’s a signal that might indicate an issue, we should discuss it right away.”

In our case, the POD was progressing from signal to action right away, which was sort of cutting off the product manager and myself from having visibility on how much work we could accomplish in a sprint. If you consider the product manager and myself as stakeholders in the work, we need to at least be informed, and in some cases be the approver.

In the next POD synch, we discussed how we had been continuing this pattern of going from signal straight to action. It wasn’t necessarily anyone’s fault, but our old mode of operation was creating new complications given the way we structured our product development teams. To combat this problem, we reinforced the point that discussions don’t just happen in POD synchs. We have instant messaging for exactly that purpose.

Wrapping Up

When problems come up, we need to move from signal, to conversation, to action. That way we keep all the stakeholders updated on what’s in progress, how much risk we’re taking on in product development, and whether we’re still assigning the right amount of work for a given sprint.