The Good Sides of Busyness – Busyness and Urgency as Heuristics for Cadence

This is the third part of the series “Busyness, productivity and creativity”. The series consists following parts:

  1. Being creative and productive despise of the insane working pace
  2. Two organization anti-patterns: Urgency as Thread and Busyness as Heroism
  3. The Good Sides of Busyness – Busyness and Urgency as Heuristics of Cadence
  4. 120 000 Nails – Urgency and Busyness as Motivators

In the previous part, I claimed that there are four types of urgency and busyness. (1) urgency/busyness as a mechanism of manipulation, (2) urgency/busyness as a necessary part of the system, (3) urgency/busyness as a heuristic indicator, (4) urgency/busyness as a motivator. In the previous entry I introduces the first two. In this entry I discuss urgency and busyness as a heuristic indicator. I have now explaining the two most common ways why urgency is devastating and wasteful. Now I’m going to have a look at why and how urgency and busyness can also be a good thing.

The Significance of Cadence

In “Succeeding with Agile” Mike Cohn discuss why Scrum initially recommended four week sprints rather than six week sprints or even longer. They had experimented six week sprints and found out that they usually got nothing done during the first weeks because the deadline was so far away. Four week cadence worked better. I presume that nowadays the cadence in Scrum-projects is often even shorter, two or three weeks. Cohn is not the only one who had found out that relatively short iterations work best. For instance, Kanban (and the lean software development methodologies in general) recommends to minimize the cycle time, even if the increasing urgency forces you to do big changes to specification, quality assurance and deployment practices. In the lean methodology, ideally, it should be possible to go live at any day.

The reason why short iterations and cycle time works is not urgency per se, but cadence related to it. The mathematical queue theory explains nicely why short cadence works from one perspective – and partially. I’m not going to discuss that now. Rather, I discuss why relatively fast cadence works from phenomenological and psychological perspective. I argue that from phenomenological point of view, the cadence of work and cadence of music or dance (etc.) are very similar: very slow rhythm is approximately as hard to maintain as very fast one, while a relatively fast but not too fast cadence is the easiest to manage.

If the cadence is too slow, it is hard to keep the rhythm instinctively. Usually you need to start counting: 1-2-3-4-5-6-7-bang-1-2-3-4-5-6-7-bang. Etc. This is true in software projects also. If the deadlines are too far away or the cadence is otherwise too slow, you cannot just trust your memory, instincts and gut feelings but you necessarily need Excels and other helpers to keep on track. You may even need a role whose only responsibility is to ensure the cadence; ensure the milestones and keep track of the tasks. This kind of role is needed especially if there is no proper cadence. 1-2-3-bang-1-bang-1-2-3-4-5-6-7-bang and so on. The lack of proper cadence is waste of people potential and a recipe to poorly performing team: it’s hard to dance well, if there is no proper rhythm and it’s even harder to enjoy the dance – even the silence is better.

On the other hand, if the rhythm is too fast, you start missing beats and eventually the music turn into cacophony. Again the analogy to software projects is straightforward: if the cadence is too fast, you start missing deadlines and forgetting things. This is a well-known psychological fact (see e.g. David Rock, “Your Brain at Work). For some reason, this is not obvious in the project management. “The more challenging deadline, the harder and faster you need to work”, we tend to think. Eventually, a project becomes a big ball of mud.

If you want to do things faster, you have first learn to do things fast, and that requires a lot of practice. You have to start slowly and with small steps. The more complex is the choreography, the more repletion you need until you can manage the movement when the cadence is fast. If you try to do things faster than you really can, you will mess up everything. If someone whispers your ears “faster, faster” all the time, you probably will, indeed, screw up faster. This is very true also in projects and software industry. Actually, this is obvious in almost everywhere else where the cadence is crucial – music, dance, martial arts, and so forth – but not in software industry.

Busyness as a heuristic indicator

“Hey, wait. You said, that you are going explain, in what sense urgency and busyness is a good thing.” Yes and still going to.

Busyness and urgency are good as a heuristic of the optimal performance and as a warning sign of shoals. I’m saying that busyness is a great thing as long as it is nearby but not quite here-and-now. The best cadence for work is much closer to urgency and busyness than boredom and idleness. The optimum performance and productivity is achieved by working nearby the capacity of the organization.

I slow down a bit and start from the systems in which the cadence is paid no attention at all. Both (2) too fast and (3) too slow working pace lead not only to suboptimal performance but are the root cause for other kind of problems.

(Click the image to see bigger version)

There are studies that states that after two weeks of overwork the net results are lower than they was before the overwork. E.g. before overwork you completed 10 units of work per week, after two weeks of overwork you are able to complete only 9. The benefit of overwork is negative (see e.g. Mike Cohn, Succeeding in agile and Lister & DeMarco, PeopleWare). This Fatigue (1a) is devastating because it lower productivity per time unit, and also because it leads to the high level of defects and technical debt (=the solution become hard to change and maintain; 1b & 1c). Because of fatigue, lower quality and technical debt the net effort fluctuate strongly (4).

The too slow pace is less harmful than too fast. In addition to the fact, that you obviously get less things done (as you work under the optimum capacity), the organization’s ability to learn is severed. The reason is to this is twofold: (i) the feedback loop is longer and (ii) people easily become more passive if the natural activity is artificially pushed down (for sake of the process). In addition, maintaining the overly slow cadence usually requires quite a much management overhead.

Actually, in the overly slow organizations and processes, there’s a lot of similar with butoh dance. I’m simply amazed by the control of body and mind that the grotesque and often unnaturally slow movement must require.

Mark Kennaley suggests in “SDLC 3.0 – Beyond a Tacit Understanding of Agile” that maximally efficient organization can learn quickly its capacity via experimenting (1) by experiment. Once the optimum is found it just need to adjust the amount of work to it (2). According to Kennaley this is the optimal performance an organization can achieve in the ideal situation:

(Click the image to see bigger version)

I partly disagree. Kennaley underestimates the potential of learning and of the improvements in the system. I believe that the optimum performance is achieved by keeping the amount of work slightly under the capacity of organization. In this sense, urgency and busyness are a heuristic for the optimum, natural cadence and performance: first work so hard that you feel a bit busy or – even better – almost busy, then slow down immediately and reflect how to avoid that shoal of busyness you just faced.

(Click the image to see bigger version)

I’m not saying that people will learn to do the same thing faster. That would be naïve. People do learn to do things slightly faster, but that improvement is not important at all. I argue that the capacity of an organization can raise if (and only if) people are able to do more the correct value-adding things and they need to do less the unnecessary or wasteful things. Obviously, doing all the time better and faster anything, won’t necessarily add value at all, and thus it does not make the organization more efficient.

In short, slack is needed for reflection of those things the sufficient amount of urgency and busyness reveals and that would make us busy if we don’t change the system. Without urgency and busyness you won’t see what you should do more efficiently – instead you do random things better.


Next, “120 000 Nails – Urgency and Busyness as Motivators“.