When Your Pursuit of Agile is an El Camino
The first time I heard about Agile was in a department meeting somewhere around 2010. At the time, I worked at a large, aggressively-corporate Waterfall organization. They prided themselves in methodically vetting everything from Open Source Software, to changing how often releases got deployed to production. This vetting process often took months, sometimes longer. So when they decided to change the way they developed software, of course it had to be fully vetted. For reasons unclear to me, the decided approach was to not go “fully Agile,” but to use a hybrid, WAgile approach.
It gave me a chuckle.
It’s not the first time an organization went down this road, nor will it be the last. Several years later, they went with Scrum(ish), but back then, the misguided hybrid approach reminded me of an El Camino. I remember seeing the weird truck-car for the first time when I was a kid. A friend of mine’s dad owned one, and I couldn’t help but think how ridiculous it looked.
“If you want the inconvenience of a 2-door car that lacks rear seating, and the ability to haul less than a tiny pickup truck, then I gotta car for you.”
In response to its main competitor, the Ford Ranchero, Chevrolet debuted the El Camino in 1959. But in 1988, its final production year, Chevy only sold 420 of ’em. That’s a far cry from its peak at 64,987 back in 1973. When charting the year-over-year sales for the El Camino, it kinda reminds me of a Gartner Hype Cycle, but one that never reaches a plateau of productivity.
This same downward progression is what tends to happen with El Camino Agile. To clarify, not all hybrid approaches are terrible. Scrum + Kanban (or ScrumBan) work well together. People tend to get into trouble when they don’t understand what Agile is truly about. It typically goes like this: folks are introduced to the idea of agility, usually with Scrum. They try to implement it, which inevitably clashes with their ingrained way of doing things, and to avoid rocking the boat, concessions are made to stop the boat from rocking. Scrum is forked, remixed, and modified to minimize organizational tension without addressing the real reasons behind it. Eventually, when the promised benefits don’t come to fruition, there are cries of “Scrum doesn’t work!”
“Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.” — The Scrum Guide
Here’s the thing. Agile is meant to be painful, and throw a monkey wrench into business as usual. Once wasteful processes, or practices have been called out, it’s your job to roll up your sleeves, clear the way, and dismantle dysfunction. It’s fundamentally about letting go of the old ways, experimenting with new ideas, and applying wisdom gained from failures. Yet so many wannabe Agile organizations refuse to try anything new, insisting that there’s no time for experiments, and that failure isn’t an option.
Change isn’t easy. After so many years of “That’s how we’ve always done it,” multiple layers of management, and large organizational hierarchies, the difficulty level in making real change can be insurmountable. I’ve heard people complain about how hard things can be, but what’s the value in only doing things that are easy?
Ask questions about change.
If development teams run in 2-week sprints, what needs to change in the organization so that working software can be delivered within that time frame? If a dedicated release management team oversee deployments to production, what needs to change so that development teams can do that for themselves? If QA sprints are the norm, what needs to change to make testing more efficient? If C-level executives aren’t meeting face-to-face, on the reg with development teams, what changes can improve communication, and transparency?
When Scrum is tossed over the fence at a group of developers, and nothing has changed at an organizational level, you’re setting the stage for frustration. I’ve been there. So have many others. The best way to avoid it is to ditch hybrid approaches. Get the basics down first. Make the hard decisions, stick to them, and put in the work to identify where improvements can be made. Make real, impactful changes.
I cringe every time I hear someone say “We’re agile now.” Any true agilist worth their salt will tell you that there’s no such thing. It isn’t a mountaintop to be reached, or a finish line crossed. It’s about constant learning, and change in baby steps. We must learn to walk before we can run. So, if you need a car, get a car. Need a truck? Get a truck. Use the right tool for the job, and leave El Camino Agile behind.
