Voluntary Complexity

Excessive work in progress, and too much multi-tasking, slow teams down and keep them from reaching their goals. Addressing WIP is a critical management task in any development paradigm. 

One agile approach involves a kanban board, and a limit on the number of simultaneous items that can be “In Progress” on the kanban board.  Parallelizing work as much as possible, and  team swarming on tasks can take the WIP limit down to one – with gains on communication overhead and multi-tasking losses. 

But these strategies often fail when the work is not completely confined to the team.  When the work depends on external resources that the team does not control, the pattern often becomes – start a task, wait for resources, put it on a queue of pending tasks, start another task until there’s an interrupt from a prior task or that task become blocked – until the people trying to get work done are overwhelmed with context switching and with the overhead of tracking it all. 

Let’s name these tasks that are waiting for external resources something different from WIP, “work in flight” lets say, as they are somewhere in the air waiting to land somewhere.  How can a team that’s highly dependent on others even hope to get this situation under control? 

1. A partial solution is to separate deep work time from task management time.  This doesn’t really solve the problem but it can relieve overwhelm on an individual level.  A manager can help by supporting individual time-management efforts by no-meeting days, or reinforcing the norm that ICs can decline meetings that will damage their productivity 
2. Redefine tasks so that units of work are completed at handoff points. For example, a design proposal has gone on to the compliance team for review. Lacking control over their work queue, the task may be considered done.  It may be a challenge in this model to keep sight of delivering business value rather than stops along the way.  However, this creates clean context switches that may keep you from the psychological toll of unfinished work. 
3. Invite others inside the box – get a resource from another team temporarily embedded with your team, or schedule a mini-project for in-depth collaboration on a time critical issue. There may be creative collaboration avenues available, if the organization is not extremely silo’d and inflexible. 
4. Make one person, perhaps a technical program manager, “air traffic controller” for work in flight. Such a pattern might look like:  Engineers work on tasks until blocked, turn over resolving the block to the TPM, and let the TPM know when they can pick up more work.  The TPM can track what tasks have been returned to the backlog to be picked up again, without interrupting the current work.  

Structurally, this WIP problem is an argument for creating cross-functional teams that include all the roles necessary for project success.  If you can effect change on a structural level, consider adding technical writers, program managers, designers, and testers, among others, to an engineering team.