A friend of mine who has ADHD recently began taking medication for it. When he described his before-treatment symptoms – the inability to maintain focus, the ease & frequency of distraction, the dissociation of present situations from the past – I realized he might as well have been describing the behavior of some companies I’ve encountered.
Evidently there’s an institutional variety of this ailment, what I’ll call Organizational Attention Deficit Hyperactivity Disorder (O-ADHD). The salient features of the syndrome are similar to its human analogue: Too many things to do; No clear determination of priority; Obsessive but incoherent attention paid to second-, third-, and fourth orders of work; and consequent inability to deliver customer value in the time required. Sound familiar?
For people with ADHD, taking amphetamine (aka ‘speed’) – a stimulant that in high doses can spin typical brains into fibrillating overdrive – paradoxically has a calming, focusing effect. Like amphetamines for humans, limiting Work-In-Progress (WIP) is a counterintuitive yet effective treatment for companies suffering from O-ADHD, actually allowing them to get more work done.
Most agile approaches include WIP limits among their regimens. In Scrum, limiting WIP is accomplished in a number of ways: By having one Product Owner who prioritizes the work (instead of many individuals with competing priorities); Fixing that priority for an agreed-upon duration (the sprint & sprint backlog); Prohibitions on performing work not included in those agreed-upon priorities; and the team ‘swarming’ first on the highest priority items in the sprint backlog before moving onto the lower priorities. With Kanban, limits on WIP are often explicit in number – the team, for instance, may agree to take on no more than 3 items at a time.
This ‘less is more’, ‘slow down to speed up’ technique is highly effective at increasing teams’ productivity. Why? For the same reason it works for individuals; Limiting WIP cuts through the chaos of priorities surrounding most development teams and allows them to do what they do best – build working software – by focusing everyone’s attention on a near-term, achievable goal and minimizing the productivity lost to fractionalization, task-switching, and dashed motivation that come from trying to do too many things at once.