Count Basie, a jazz piano player and orchestra director, was famous for being quite spare as to his piano playing, with great use of silences, and making do with as few notes as possible. As one member of his band said, “Count don’t do nothin’. But it sure sounds good.” Another jazz player, “Dizzy” Gillespie (known for his upwards bent trumpet and his puffed out cheeks) spoke in a similar way about what needs to be played and what doesn’t, and highlighted that it had taken him all his life “to learn what not to play”!

While maximizing delivered value through greater productivity is an implied goal in all agile methodologies, we can follow a path similar to Basie’s musicianship or Gillespie’s experience, and apply a rather surprising concept: “Do Less”… because sometimes, by doing fewer things, you end up doing more!

This idea isn’t quite new – and it’s actually one of the 12 principles of agile development! Most quality processes have a similar concept, seeking to avoid wasteful processes (or not doing things that aren’t actually needed) so “Do Less” could be interpreted in that way. Extreme Programming (XP) also has an akin rule: “don’t do more hours”. The “Sustainable Pace” practice requires that developers should not work more than 40 hours per week, and if there happens to be overtime one week, it shouldn’t be followed by another week with overtime. A key concept is that people perform best when they are adequately rested, and XP thus aims for a constant level of production, instead of a “crunch style” that tries to produce more with overtime, to balance lower productivity elsewhere.

Following the same train of thought, let’s focus in a core property of Kanban: limiting “Work in Progress” (WIP). The way Kanban applies it, is through setting a maximum number of cards that can be in progress within a given step of the flow at a specific point in time. This way, instead of having more cards in progress, the focus goes to finishing cards and “doing less”, which is actually better from a results’ standpoint.

Even if you apply other methodologies, you may want to consider limits per person, by group of people (say, all Business Analysts or all Testers), or by team. These limits do not mean that you can never go beyond the defined thresholds, but rather, that the team should be responsible for understanding what happened and why, and to look for ways to prevent the situation from happening again. If there’s a bottleneck somewhere in your process, this analysis will help you deal with it, so cards start flowing in a more fluid way, and your team’s productivity will increase.

So, when considering possible changes or innovations for whichever methodology you use, think of the “Do Less” concept, and see if limiting yourself in some aspect or other can actually help you become more productive!

P.S. Check out this version of “Salt Peanuts”, a composition by Dizzy Gillespie, played live by the composer himself, and check out both his signature trumpet and the way he inflated his own cheeks when playing!

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>