The agile art of being busy (most of the time)

My last agile function was called 'feature manager', which means 'manager of thingies'. But it could have been worse, like 'Tribe lead' or 'Epic owner'. It seems like these titles were invented by Lord-of-the-Ring geeks. And it doesn't get any better when we look at the names of the meetings, or ‘rituals’ as they are called. The name ‘Grooming session’ brings up images that belong in a documentary on primates. Some meetings also have a spiritual connotation. Daily stand-ups are sometimes called 'daily prayers'. There are retrospectives that bear resemblance to public confessions. The master of ceremony of all these meetings is a scrum master, a kind of master wizard who removes obstacles and keeps people on the right path. Reference is made to sacred principles, such as the agile manifesto or the 10 Safe principles, sometimes written down in a book such as the 'scrum guide'. But the strongest parallel with a belief system seems to be the emphasis on the agile mindset as the capstone to agile success. That mindset and the road to it is shrouded in mystery as if it were some kind of religious revelation that one may or may not be open to.

Yet this does not reflect the true nature of ‘Agile art’ as we know it. Agile is not an esoteric practice, instead it's a very pragmatic approach. She focuses on a problem with which IT has been struggling for decades: IT does not deliver enough good working software. In this article I want to show that these rituals and functions play a crucial role in tackling this problem. We have identified this problem in the article 'Failures drive Agile transformation' as the first failure: Failure to deliver.

?

The delivery problem is a problem of 'being busy'

Waterfall approaches assume that people are rational supermen. The business analyst uses his visionary gifts to write the new solution down to the last detail. He passes this document on to his IT colleagues who can translate it one-on-one into a system solution. Some mind-to-mind transmission seems apply here. The system is being developed by a diverse group of specialists who are all on the same page and after a long time deliver a system that perfectly meets the requirements.

Obviously long term projects do not implement according to such a plan. Project specialists have the tendency to play solo. The longer the project takes, the more the deliverables drift apart. In the end there’s no working system, but a grouping of functions that barely fit together. Inevitably this leads to a political battle of blaming leading the project to it's final phase of agony. Where did it go wrong?

The fundamental flaw in the waterfall approach is the assumption that we work as rational beings who can collectively follow a rational plan. That is, we would make a well-considered rational decision for every action we take. In practice, our decisions are rather unconscious in nature. Usually the work of the psychologist Daniel Kahneman is cited here (Thinking Fast and Slow). He claims that our rational mind is much slower than our intuitive and irrational mind. As a result, we take risks when the risk is high and we avoid risks when the risk is low. In this article we give the floor to a philosopher who – 50 years earlier – defended a similar thesis as Kahneman. Martin Heidegger argues that most of our daily lives are spent in an unconscious state. We do things without thinking about it and that in itself is not bad. For example, driving a car and opening the door is a process of unconscious actions. What's more, we spend the day in a series of routines: the routine of getting up, going to work, working, going back home, eating and going to sleep. Those routines are desperately needed in order to get through the day.

But that also means that most of our day is submerged in a slumber of mindless busyness. Being busy dominates our lives more than the question whether we are doing the right thing. We just move along, cope with the day-to-day problems following predefined routines without ever giving our actions a second throught.

How can we break out of this unconscious behavior? The philosopher is very clear about this. We awaken from this daily slumber only when a problem shows itself, not a moment earlier. For instance; I stop hammering when my hammer is broken. I then replace it with another one until it breaks again. And only then do I ask myself whether hammering is the right solution. To assume that we can suddenly see the light – possibly prompted by an enlightened agile coach - is illusory.

So the conclusion is twofold

1. We need routines in daily work
2. But those routines need to focus on problems that make us think

?

The agile art of being busy most of the time

Behold the description of the 'agile art of being busy, most of the time'

1. The agile art is an art of being busy – because we need routines
2. But only 'busy most of the time' - because we need trouble every now and then to think about what we're doing

Not all agile approaches go overboard in epic job titles, but they all have some sort of routine that more or less rigorously pours everyday life into a cadence. Even Kanban has daily stand-ups and a whole arsenal of planning and review meetings. Anyone who participates in an agile project looks like a monk who is regularly called to collective reflection. These are routines, but they are of a very specific nature, as they focus on problems. The daily stand-up confronts us with a status problem, the demo meeting asks the team about its end product, the planning meeting focuses on capacity and demand problems, etc… These meetings all have a high PIA-factor (Pain In the Ass factor).

To summarize : Agile introduces its own 'art of being busy' that focuses on problems.

Making fun of agile’s busyness

Yet, also in Agile practice this unique focus on problems can be 'forgotten'. In that case the Agile approach is just another set of routines that pushes the teams back in mindless day-to-day activities. Agile is not immune to this regression. Daily stand-ups become boring reports of individual statuses (What have I done yesterday?). In planning meetings, the team makes pointless commitments to avoid difficult discussions with the product owner. And the retrospectives turn into cuddle sessions where any discussion of numbers is taboo. In that case the problems are banned from the routines.

This shows that even an agile approach is subjected to the slumber of daily activity.

That is why we should continuously problematize agile practices and even occasionally ridicule them a bit. Maybe that's why the inventors of the agile approach created these ludicrous titles.