One time, I was on a team that had an impossible deadline. As the stress levels grew, the team realised that the normal way of working was not going to get them across the finish line in time. Actually the truth is it wasn’t just this one time. I have been on such teams quite a lot. The difference is in the way this team reacted.
This team did something radical. It threw away the rulebook on everything and just started doing the things that would obviously make them go faster. They started keeping a really good track of what they’d already done and what was still left to do. They started convening twice a day to ensure people were not stuck, to align on the approach and to coordinate the next steps. People would work on problems together in order to go faster. QAs were deeply embedded in the teams and though there was little by way of automated testing, the feedback cycle from the tester was fast enough to make a real difference to velocity.
Do you see what they did? The team had just invented Agile. Or better said, it re-invented Agile. Agile Programming itself was invented many years ago. So many years ago, in fact, that it had already completed its transition from “disruptive new methodology empowering teams” to “that damned process”. By the time this particular team found themselves in that age old predicament, Agile was firmly in the list of things that people endure because someone else tells them to.
And yet without adult supervision this team had organically arrived at the following
Standups ✅
Pair programming ✅
Velocity measurement ✅
Fast test cycles ✅
Given time to refine their approach I am confident they would have introduced a second planning cadence at a weekly or fortnightly level and evolved a more sophisticated way to measure velocity.
Why then is Agile or SCRUM so joyless? Why does it feel like one mindless ritual after another, a process that needs someone with the title of “SCRUM Master” no less to administer? What’s the difference?
the problem with Agile
The problem with agile, as with all processes, is that Agile does not exist in a vacuum. There is a context around Agile that was not written down in any of the textbooks. And it is this missing context that makes all the difference.
Observing this team made me realise what the missing ingredients were —
desire.
The difference between this team and the other teams that endured SCRUM is that this team really really wanted to go faster. The goal they were chasing was meaningful to them. The cost of delay was clearly known and avoiding delays was goal number one in this team’s mind.
autonomy
The team was free to choose their way of working and this made all the difference. There was a very clear ‘why’ behind every one of their decisions and every member of the team felt like they had a say in these decisions. Contrast this with the answer you get in the median org — we do this because we’ve always done this.
attention
Because these rituals evolved organically and were tuned to the needs of the team, there were very few reasons to be ‘checked out’ during the standup. The process lost the feeling of being a ‘mindless ritual’ and became instead a source of critical inputs into the life of every member of the team.
Rituals
Ever been to a pooja, say a grahpravesh or Satyanarayan Pooja? Do you see how the karta just does whatever the priest tells them to without paying attention? This is a misunderstanding of the ritual. Pooja as a ritual was originally meant to guide the attention to where it was required. The actions being performed there are not the main thing. It is where your attention is that is most important.
It is the same with our work rituals. They are tools for guiding the attention, not a checklist of action items. When this essence is lost, the ritual becomes a dead ritual and it is time to replace it with something more alive, more vital and energising.
The Marie Kondo approach to process design.
Without ‘joy’, all your processes are deadweight dragging on the attention and creativity of your teams. This mindless performance theater of ticking checklists and presenting burndown charts is not what Agile is about. Agile is about a focus on the goal and the desire to get to it as fast and smoothly as possible.
From time to time you have to do a Marie Kondo on your processes, throw out the things that do not spark joy, and allow the team the leeway to create their own process.
Isn’t this dangerous?
It can be. After all the tires on the car or the carburettor hardly spark joy but you can’t really throw them away can you?
There are processes in place to avert disaster. These processes do important work without sparking joy. A deploy checklist, for example, doesn’t spark joy but what it does do is avoid misery. Which is also a good thing. So how does one know what to keep and what to throw away?
A factory has a different definition of joy than a home. What looks ugly to the factory visitor might be the source of deep joy to the worker who works on it every day. Help your team to find that spark of joy even in the ugly but useful things, help them recognise the coherence, the design and the intent behind the process. And who knows, some team might even turn these into joyful activities.
what about standardisation?
What about it? Standardization of process is not as big a deal as you think it is. It’s perfectly fine to let teams design their own processes. When you want standardisation, it has to be as a response to a real problem faced, not an imaginary problem. When you face this problem, tell the teams that their processes are causing problems upstream or downstream and let the teams work together to solve those.
We’re ‘programming to interfaces, not implementations’ and ‘refactoring as we go’. You already know how to do this.
to conclude
The most lasting sense of joy comes from ‘a job well done’. Focus on doing the job well. The joy will invariably follow.