Why 2023 is nothing like 2001
Summary
The agile manifesto is an excellent document that marks a generational shift from rigid development practices, to more lightweight, maker-centric principles. The idea was to restore balance balance and be less Dilbertesque *. But the 2020s bring their own baggage that impedes knowledge work. And so, I explain why we need a new statement to reclaim balance for knowledge working teams.
If you haven’t been watching this space, then you should know that the async-first manifesto is in its second draft now. It’s a collaborative exercise - everyone can comment and if you want to co-author, introduce yourself to me and I’ll share access. If you’re curious to know about how I started with the idea of a manifesto, you can read this explanatory post, or watch the video below.
But all this said, why do we need a new manifesto? Isn’t the agile manifesto enough to describe how knowledge-working teams should collaborate? I want to address that question in today’s post.
Snowbird hosted a generational shift
I was only a student of computing in 2001 when the agile manifesto came into being. None of the textbooks I read at the time had a word about agile. We learned instead, about the software development life cycle - i.e. SDLC. Of course, you only had to jump onto an open-source mailing list, to hear murmurs about software development countercultures. At the time, we read about curiously named frameworks like Scrum, Crystal or XP. I can assure you though, that when I started working, soon after the Snowbird meeting, agile software development wasn’t mainstream. In fact, I would have my first brush with professional, agile software development, only when I join Thoughtworks in 2007.
When you read the reflections of the 17 men who authored the manifesto, back in the day, their vision was to free makers (the developer community) “from the baggage of Dilbertesque corporations”. As Jim Highsmith wrote back in the day, the idea was to restore balance.
Jim Highsmith
“We want to restore a balance. We embrace modelling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely used tomes. We plan, but recognise the limits of planning in a turbulent environment.”
Indeed, the manifesto was a revolutionary document back then. And it marks the beginning of what some people call the agile movement. To paraphrase Ron Jeffries - the manifesto described a thing called “agile”. That thing grows and updates all the time and it’s up to us, as practitioners, to build the body of knowledge that the manifesto inspires.
We’re in a new generation now
The “Dilbertesque corporation” of 2023 looks quite different from its 2001 avatar. Back in the day, the makers’ battle was against “process for the sake of process”. Developers hated wading through voluminous, turgid and unclear documents, for example. They’d rather build software iteratively and cleanly, so the code can serve as documentation, and customer feedback could guide future development. Over the last two decades, knowledge workers have embraced the truisms of the manifesto so deeply, that we now see a different Dilbert story.
Misunderstandings of agile lead to new dysfunctions
The new Dilbert story represents itself in militant misunderstandings of the manifesto. Executives and managers who haven’t been hands on in years, foist broken notions of collaboration on people who build stuff. Return-to-office (RTO) mandates in the name of serendipity, collaboration and brainstorming reflect this archaic mindset. We, practitioners, are also not blameless. Many of us use the manifesto as a crutch to avoid written communication, protocols and process. This leads to a laissez-faire, hyperactive hivemind, where we’re always second-guessing ourselves.
We also recognise that society and technology have changed a lot since 2001. Let me list some good and bad changes.
We value diversity far more than we did two decades back. If 17 middle-aged, white men came up with a declaration about software development today, it would surely raise some hackles. So our models for collaboration must support high inclusion.
Communication technology has improved considerably since 2001. I argue that sometimes, modern communication technologies make distributed collaboration even more effective and inclusive than face-to-face communication. We must be cognizant of this change, and that communication technologies will only improve in the future.
Distributed teams are the norm today. This is a massive change from the time when I started my “agile” career with Thoughtworks. The concept of “distributed agile” was so novel even then, that I remember running a workshop about it at the XP conference at Trondheim, in 2009. A few years later, Martin Fowler wrote, “You will often get a more effective team by embracing some form of distributed model because it will widen the talent pool of people you can get.” Today, companies hire and staff teams from everywhere. Any model of collaboration should recognise this shift.
Social media has nudged us to seek shorter, more distracting content
And last, our attention spans have shrunk in the last two decades. We owe this shrinking attention span to social media - from LinkedIn, Facebook and Twitter in the early 2000s to Slack, TikTok, Reels and Shorts in the last decade. We all write less, read less and switch contexts far more than we did in the past. If we value deep work, then this is a phenomenon we must fight back against.
The status quo has shifted so much since 2001, that we need a complementary document to the agile manifesto, which describes effective collaboration. Think of it as another attempt to restore balance. That's my attempt with the async-first manifesto.
Unoriginal as it may seem, we are borrowing the agile manifesto’s approach to stating its values as tradeoffs. We’re also describing the principles that inspire these values. Like the agile manifesto took inspiration from many existing methodologies, we too take inspiration from existing, but promising models of executing and describing knowledge work. Deep work, TeamOps, DevEx and my work on “async-first” are only some sources of inspiration. This isn’t the only manifesto of its kind either. You’ll see many others who’ve taken a crack at this problem before (see here, here, here, here and here). So there’s a need to band together and build a statement that’s more than an individual’s opinion.
There’s no rush and no deadline, except one that we impose on ourselves. We can take all the time we need to feel comfortable with the document. I’d like to iterate through this statement with anyone interested to contribute. So if today’s post convinces you that modern collaboration could benefit from a manifesto, I invite you to join the conversation and help shape the document. Let’s imagine the future of work together!
* The references to Dilbert are not an endorsement of Scott Adams’s racist comments.