I definitely have a love-hate relationship with Agile. It’s not that I’m a fan of the Waterfall methodology. Far from it. But that’s a black-or-white logical fallacy. There are more than two ways to do things. And it is hard to fault the actual Manifesto for Agile Software Development, as it accurately addressed the problems of the time it was created, which was over 20 years ago.
The manifesto isn’t the issue, but rather it’s the Agile Industrial Complex – as one of the manifesto authors, Martin Fowler, coined it – that is to blame.
Agile wars, dark agile, faux agile, Agile in Name Only (AINO), Big-A Agile vs little-a agile, lions and tigers and bears, oh my! To paraphrase Mahatma Gandhi, “I like your Agile, I do not like your Agilists. Your Agilists are so unlike your Agile.”
Now I can’t say I’ve ever worked on a true waterfall project, where a team threw requirements over a wall and then went away. But I have worked on large consulting projects where documentation happened simultaneously with development. None of our customers were ready to throw down a million for documents alone and then have work begin.
Still, it was a big-bang approach, with a delivered product at the end of a one- or two-year engagement. Occasionally, we delivered early functionality along the way to gather feedback and validate requirements, but only in terms of delivering milestones without the intent to revisit. So…was that faux waterfall? Pre-agile?
From there I moved on to iterative faux Rational Unified Process (RUP) / Rapid Application Development (RAD) projects and then a dalliance with Extreme Programming (XP). You gotta love the extreme radical 90’s. All of which was before the manifesto’s creation.
When I led my own team, I blended Agile concepts into development as much as I could. But I couldn’t change company policies, and still had deadlines to meet. Later, when I joined a Scrum-based company, with customer advocates instead of customers themselves, I fled as soon as I could. Another company later mandated Lean policies until it broke almost every employee.
Finally, I landed on DevOps and DevSecOps, with a lot of hand-waving to the actual Agile practices themselves. It led me to wonder if this is a post-agile world.
I have given a lot of thought to how to do software development. A focus on actual agility, smaller iterations, shifting testing and security concerns upfront, direct feedback from the customer, continuously automating everything you can. These are all vital things that can be traced back to the manifesto and its movement. Strict adherence to a non-changeable process, zero forethought to the overall design, assigning tasks with no concern for an individual’s skill set or career path…not so much.
I resist blaming the Agile Manifesto’s authors, themselves, for giving a loaded gun of ideas to children who just want to know how to do it. With hindsight, it seems inevitable that the existing industrial complex would ignore, ridicule, fight, subvert, and then begrudgingly accept some distorted version of its truth. And then get bored with it and move on. You gotta love the millennial age of cynicism.
All of this is why I was skeptical and delighted to find a new iteration of Agile in Agile 2. Agile 2 looks beyond mere software development towards agility in, “all human endeavors that require multiple people.” Clearly this time they did not skimp at looking at how Agile can or cannot scale.
And like the original manifesto, as I read through the six values and 43 principles, I thought that these ideas are powerful and accurately address the issues of the day.
But how do I do it? Maybe, I’m the problem here.
Agile 2 answers the, “how to do it,” problem with the only true answer in the universe, “It depends.” Agile is not a single, by the numbers process where one size fits all. Agile 2 recognizes that all frameworks and methodologies have elements of validity for given circumstances, and all of them need to be tweaked and redesigned to meet the unique needs of a given project and team makeup. It’s not the simple answer we want, but it is the simple answer we deserve.
Agile 2 also reemphasizes the need for multiple forms of benign and effective leadership across all levels of the organization, which is something that the original manifesto barely addresses. It addresses the need for data design, which had been completely overlooked. And it addresses the need to work with individuals as well as the team.
Individuals who work, communicate and collaborate differently. Individuals that might not all be outspoken extroverts who enjoy combative collaboration in an open floorplan workspace, but rather thrive when reaching a flow through quiet, noise-canceling headphone-wearing, uninterrupted meditative states.
Agile 2 gives me a new hope for agility if for no other reason than taking it out of the hands of zealots and returning to the importance of values and principles upon which to build your own process. I recognize that as humans we want the answer handed to us. We want things simple and “catchphrasable.” It’s not that we don’t like thinking, we just have limited bandwidth in which to think about things.
But if you believe in agility, and the need to test theories with the ability to pivot early on when things go wrong, then apply that to your own Agile processes. Agile 2 gave me a lot to think about in extending agility beyond software development and into business management where it is needed to make the cultural changes necessary to thrive.
Explore it for yourself before the Agile Industrial Complex gets ahold!
