Agile Liturgy

In religious worship following ceremonies and rules by the book is known as liturgy.

Often, these rules of ritual performance persist over time and culture, even when the original context that created them no longer exists or is misinterpreted. It becomes a cult to the form over the content, a reactionary adherence to the practices even though the foundational values that originated them are long gone.

This tendency manifests at certain stages in the evolution of an idea, typically during a phase of mass adoption, when innovation ebbs and the core principles that drove the mentality shift are left behind.

Agile has already gone mainstream and along with that comes the corruption of the principles.

The overwhelming weight of methodology over philosophy leads to a black comedy - situations where many development teams are forced to strictly follow a set of practices that upset everyone and sometimes are self-defeating.

I call this phenomenon Agile Liturgy.

The corruption of Agile

Below is a chart of Everett Rogers’ innovation adoption life cycle:

Pioneers always have an extreme mindset within their own paradigm. The source of their ideas is the combination of their own geniality as individuals, a very specific context and probably a lot of experience.

Early adopters immediately recognize the value in the ideas of these pioneers and follow them in close steps. They have a similar mindset and, to certain extent, they are pioneers themselves, in their own context, as they have to convince those around them about something new and risky.

Both pioneers and early adopters make a lot of mistakes while learning by trial and error. However, since a strong background philosophy underlies their momentum, they are self-critical and constantly review their own processes.

If the geniality of the pioneers combined with the traction early adopters add up and triggers actual innovation to cross “the chasm”, the majority follow suit.

A pioneer/early adopter market is very different from a mainstream market:

• Most of the masses don't really share the original mindset and they are actually more attracted to the trend than understanding the actual philosophy.
• A strong commercial niche appears and along with it come training, certifications and snake oil salesmen (AKA coaches) hungering for luscious deals or even worse, trying to feed their ego and delusions of grandeur and guruism.
• In many cases, not even the “liturgical” rules are understood and perverted versions emerge that are convoluted to be sellable in certain not so agile environments.

The combination of these factors degrades into the terrible jest we mentioned earlier: a certified group of demotivated people, tossed into a post-it covered room, forced into an empty ritual called stand-up, painfully pairing with someone they hate and, eventually... playing poker to estimate.

The agile paradise of our dreams has been tragically ruined.

Look! The emperor has no clothes

We can’t be agile without agile people. We need to remain aware of that and resist the tendency of going with the flow. We must review our process, as the pioneers did, and ask ourselves: are all these practices and ceremonies really adding the value they are supposed to add?

As a matter of example and not trying to be exhaustive with this list:

Pair programming: It is a great practice to encourage quality of design and propagation of knowledge. The intent of pairing goes far beyond sitting together using the same computer. It requires purpose, a shared understanding and certain know-how.

When we do bad pairing just because "we have to pair", we pay the costs without getting the benefits and eventually, we risk frustrating some programmers. Not every combination of two people works and not everyone is able or wants to pair, and that is totally ok.

You don’t have to pair to be agile. You can do code reviews and design sessions to obtain a similar output (with strong emphasis on SIMILAR here).

Stand-ups: They aid a lot in syncing teams and short-term planning when they are properly facilitated, when members are focused and when the information being shared is relevant to everyone.

When converted into a meaningless routine, the cost is huge both in terms of the business’ time and in the team’s freedom of pace. Often we see stand-ups used as a management tool to enforce everybody to show up at a specific time or as an accountability tactic. This is terrible.

You don’t need stand-ups to be agile. Ad-hoc communication between team members when needed can serve equally, if not better, for this purpose.

User stories: They are very useful to capture users needs, define development boundaries and keep team members focused on small objectives.

Poorly written stories become a mere bureaucratic step we have to comply with before being allowed to actually get things done. It also encourages the creation of narrowly envisioned designs as opposed to the development of comprehensive well-thought-through solutions.

Sometimes it is better investing in lightweight up-front design and UI sketches for feature definition instead of writing long-drawn stories.

TDD: Hmmm...I must admit I am somehow dogmatic about this one. Unless you are spiking something out you must do TDD or suffer the deserved punishment for your sins!

I could keep on enumerating and pointing out examples of perversion for every agile practice but I guess I have already made my point here: if it generates waste and hinders the team’s flow, and we don’t fix or remove it, we are doing the wrong thing.

Hacking away the unessential

Bruce Lee may be an unlikely source of inspiration to help out with the “corruption". He was a person that defied the dogmas of his time and pushed away his art (martial) from fixed patterns (liturgy) into a framework of flexibility and mindfulness:

It’s not the daily increase, but daily decrease. Hack away at the unessential 

- Bruce Lee

If we hunt for the essence we find the agile manifesto. Its very first line says “Individuals and interactions over processes and tools”.

And later on, in the twelve principles, the role of the team is hugely emphasized:

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

“The best architectures, requirements, and designs emerge from self-organizing teams.”

People are a key part to the success of any project. No matter what organizational model we invent, if people are not engaged it won’t work (as with politics, but that’s for another day). Motivation, engagement, ownership and self-organization are the core values of an agile mindset. Agile team leaders’ first concern should be team morale. If team members are good professionals they'll know how to sort out any situation while in the right mood. If they're not good professionals... we have a bigger problem and it is not going to be solved by agile techniques or any other solution.

Tossing more process to an already dysfunctional team is not going to help out, it will only add to the mess. The key to success is doing more with less: less process, less people, less rules, less time to get things done. Let people do what they're here for - design and build - and free them from as much paperwork and red-tape as possible.

Any critical view needs an alternative proposal, so here is my recipe to avoid the liturgical trap and encourage actual continuous improvement:

• Always be mindful, question the necessity of the process: A good way to test how valuable a ceremony or practice is for a team, especially if you’re detecting a smell, is to make it voluntary. If team members find it valuable they’ll perpetuate the practice and all will feel its usefulness. If they abandon the practice, it’s time to look for alternatives. That is self-organization.
• Be flexible and try new things, in their fullness: Some of the agile practices need time and training to actually work. It’s difficult at the beginning and people resist change. As a team be disciplined when you decide to try out a practice, adopt it in its completeness, with full understanding of it for a period of time. You can then incorporate it in your process based on its proven effectiveness.
• Check on team morale often: Using retrospectives, one-on-one conversations, anonymous polls or whatever other way, ask people what they need to get things done. Find out their aspirations and expectations and take steps to increase motivation.
• Find your balance: When motivation fails, discipline and good practices help. But we cannot rely only on discipline to achieve success, as discipline has a price we pay in terms of team morale. Motivation has the same effect as discipline without paying this price.

One last quote from the master to close this post:

Adapt what is useful, reject what is useless, and add what is specifically your own

- Bruce Lee