The four most common agile fig leaves
Summary
Mindlessly following agile practices can hurt your agility. In this article I describe four agile fig leaves that I’ve often observed.
Using “self organising” as an excuse for planning.
Pairing without a commitment to deep work.
Recurring standup meetings with no common view of work in progress.
Retros as a panacea for deep-seated dysfunctions.
Note: This post is not an endorsement of Scott Adam’s views outside his comic strip. It’s possible to disagree with a person politically, and yet admire some of his work.
I can’t think of a more influential movement in knowledge work than agile. Here’s what Jim Highsmith, an author of the agile manifesto, an ex-colleague at Thoughtworks, and one of the movement's most loved thought leaders, wrote about its history.
“In order to succeed in the new economy, to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies. This freedom from the inanities of corporate life attracts proponents of agile methodologies and scares the bejeebers (you can’t use the word ‘shit’ in a professional paper) out of traditionalists. Quite frankly, the Agile approaches scare corporate bureaucrats — at least those that are happy pushing process for process’ sake versus trying to do the best for the "customer" and deliver something timely and tangible and "as promised"—because they run out of places to hide.”
That quote is from 2001. The agile movement was less widespread at the time. Jim said it was about “a developer community freed from the baggage of Dilbertesque corporations”. In 2024, the agile movement has grown beyond software teams to all kinds of knowledge-working teams. That’s both a bug and a feature.
At its core, agile is a simple concept. That’s its most important “feature”. It’s about high-quality interactions between skilled individuals. It fosters a calm work environment that respects work-in-progress while working in short cycles so people can respond to change. People have autonomy over the outcomes they must achieve. The process is important but not sacrosanct. People improve their process every cycle by reflecting on it and making small tweaks to it.
I suspect the pioneers of the agile movement knew a thing or two about psychological safety well before Amy Edmondson wrote about it. Agile teams were to be egalitarian environments where managers, customers, and techies were equal partners. You can probably sense how nostalgic I am as I write about this utopia.
You’d think that 20 years on, knowledge workers would be free from the clutches of Dilbertesque corporations. Yes, Scott Adams and Dilbert kind of got cancelled, but the Dilbertesque corporation is still alive and kicking. Agile practices were once a tool for combating dysfunction. Today, they’re often tools to propagate the same inanities Jim lamented. Managers, companies, and teams, especially those in non-tech teams, confuse “agility” with blindly following agile practices. That’s the bug.
When teams and managers forget about the values and sentiments driving the agile movement, practices become convenient fig leaves to cover up the “inanities of corporate life.” I've observed four such fig leaves most often.
“Let’s self-organise” - the ultimate cop-out
Agile teams self-organise in multiple ways. You can trust them to decide how to solve the problem right or the right problem to solve. You can also trust them to figure out an effective process for their work. However, self-organising can be an insidious pattern as well.
What happens when you surprise a group of people who already have a full-on job with a new pile of work and a deadline someone picked out of thin air? Oh yes, they can “self-organise”. But how? You know, by working backwards from the deadline! But when? Errm, they won’t get any slack from their jobs, but smart people can figure it out, right? How flexible is that deadline? Crickets. How do they flex scope? Flex? What flex? How will they work together? Smart people will figure it out, dummy!
Jokes aside, this is a typical problem in big companies, especially post-covid. The problem is even more prevalent in cross-functional work. Back in the day, when a company identified work that people from multiple functions had to complete, there was a forcing function to make them slow down. Remote work wasn’t as prevalent, so the natural first step was to get together physically to define the scope and build a lightweight plan. The in-person meetup was festina lente at play - pausing to reflect so you could then build momentum from your learning.
But the pandemic flattened our world. Today, when geographically dispersed teams and individuals have to achieve an outcome, the shortcut is to get them on ad hoc video calls. People wear back-to-back meetings as a badge of honour, so one more meeting doesn’t hurt, does it? Shallowness breeds more shallowness until a group of poor foot soldiers find themselves with a mountain of poorly defined work, a hard deadline, and no plan. Oh, and the pointy-haired boss says, “Let’s self-organise.”
“Let’s pair on it” - the one-sided dance
While most of our work can happen asynchronously, there’s value in deep synchronous collaboration with another team member with complementary skills. Such partnership is most valuable for creative tasks, where we benefit from novel perspectives. Two heads are better than one. Pairing stimulates what Cal Newport calls the “whiteboard effect”, and that’s why I remain a staunch advocate of the practice.
But pairing isn’t just about making two people responsible for a task. Pairing works when both individuals are deeply involved in solving the problem and aren’t context-switching between activities. Even when they divide and conquer the problem, they hold each other accountable by completing their tasks to an acceptable standard, using design patterns they both understand and within a reasonable time frame.
The pairing fig leaf looks like this. On a Zoom call, Suman says, “Hey Zoey, I’ll pair with you on that presentation.” Zoey’s excited. She remembers pairing being an intellectually stimulating exercise when she was a developer. Zoey enjoys figuring out the storyline for a presentation before building slides. Before she realises it, though, Suman has copy-pasted a couple dozen slides from older decks and tagged Zoey through comments on Google Slides. Wait, what? Zoey seeks Suman to discuss how they could do this better, but Suman has already moved on to his next meeting. He’s free to chat the next day, between 1415 and 1445. Zoey has two choices - choose an approach she finds sub-optimal or twiddle her thumbs until Suman can have that chat. I’ll let you imagine how this story unfolds.
Pairing is as effective as the least invested member of the pair. It fails when people don’t have common design patterns and ways of working. Ad hoc, shallow contributions to each other’s work are the polar opposite of what pairing seeks to achieve - two people joining forces, almost full-time, to tackle a complex problem.
“Let’s do standups” - recurring doses of nothing
Standup meetings are the pointy-haired boss’s favourite activities. You can almost guarantee that if you work for an “agile” company, you have a bunch of standup meetings on your calendar. In most of these meetings, a bunch of dazed-looking workers try to figure out why in the blooming hell they’re on the call in the first place. There’s no agenda, and people talk because they already have the meeting, right?
Standup meetings are a lightweight approach to share status updates and a way to flag blockers and get help. To do any of this well, you first need a shared understanding of the work in progress. Software development teams are good at this discipline, but only some teams maintain an up-to-date wall of work outside that set of knowledge workers. Many groups don’t even have a wall of work. So, most “standup” discussions are just random interruptions that eat up time without moving the group closer to their objectives.
I don’t believe that in 2024, the world needs standup meetings. We need real-time transparency, which any tracking tool can provide. But if you still care about standups, I recommend also caring about what makes them effective — a shared wall of work!
“Let’s retrospect” - the sticky note spectacle
When the proverbial shit hits the fan, the Dilbertesque corporation has a cure-all solution. Tada! A retrospective! You know, a bunch of people on back-to-back meetings will get on yet another call and use sticky notes to solve big, hairy dysfunctions that have built up over the last several months. Sticky notes! How cute! Isn’t it fun and easy to solve problems?
Yet again, the pointy-haired bosses forget the patterns in which retrospectives are successful. Effective agile teams reflect on their work every cycle. Yes, every cycle! When looking back at a week or two of work, it’s easy to be specific about instances and examples of things you’re doing well and what you must improve. Lightweight facilitation techniques, such as using sticky notes for affinity grouping, work well in such scenarios. After all, you aren’t carrying as much emotional baggage. Regular retrospectives make it easier to identify and eliminate new dysfunctions that haven’t yet become a deep-rooted malaise.
How many teams conduct regular retrospectives, though? Most managers think of them as a process annoyance they must endure every few months if only to pacify their dev team. After a bunch of pointless retrospectives, developers lose faith in such box-tick retros because, no, they don’t lead to positive outcomes.
Non-tech or tech-adjacent teams are even worse with their retrospective discipline. I’ve noticed teams doing retrospectives once a year! The problems they discuss are so deep-rooted by this time, that shallow sticky notes stand no chance against them. But why not add a dash of colour to the sticky notes you’re using? How about conducting a lovely icebreaker and a fun closing activity? And what about that nicely formatted retrospective “deck”? Ooh! Wouldn’t it be nice to show the bosses? When everyone has a good time, who cares about continuous improvement?
Sorry to burst your bubble, but I must spell it out if you didn’t know this already. Hairy problems demand deep thinking. Your sticky note extravaganza won’t cut it. But who has the time for deep thinking when their calendars are full of back-to-back meetings? Damn it, let’s do the retro!
Being agile and doing agile are two different things. However dramatic, my article's examples illustrate how agile practices can hinder true agility.
Self-organising is nothing without worker autonomy, sustainable pace and the space to plan and negotiate scope. Pairing wastes time without a commitment to deep, uninterrupted work and an agreement to basic design principles. Standups help people progress towards a team goal and build awareness of their current state only when everyone has an easy way to refer to work-in-progress. And retrospectives are effective when they’re regular.
The Dilbertesque corporation implements agile practices while ignoring the values of the agile manifesto or XP movement. These pointless rituals do precious little to further the movement, let alone improve our work. As for the fig leaves - they reveal more dysfunctions than they hide!