Different people have different ideas about the current status of the “agile” movement in software development. Different people have different ideas about what “agile” even means. Having been involved with “agile” development since 2002, I’ve had the opportunity to observe an interesting trend: We’ve been gluing a lot of things onto “agile.” Now it may be time to pry some of those things off and get back to basics.
What is “agile” and where does it stand?
Some believe “agile” is just beginning to gain traction. Others believe it crossed the chasm years ago (I would say sometime in the 2007-2009 time frame). Still others believe it has run its course and is no longer relevant. And there are those who think it was never a good idea to begin with.
Some say anything that is consistent with the four values stated in the Agile Manifesto qualifies as “agile.” Others insist only an organization that exhibits most or all the characteristics, and follows most or all the practices that the community recommends are truly “agile.” Many organizations apparently (based on their observed behavior) think “agile” just means decorations on the walls and technical staff pretending to be enthusiastic, requiring neither cultural change nor improvement in delivery performance.
Some think of “agile” as a set of broad values and principles; a way of thinking about and approaching problems; an attitude; a basis for organizational culture. Others think of it as “snake oil” that consultants push onto clients to collect high fees. Others conflate “agile” with some particular process or framework, like Scrum, Extreme Programming, or SAFe.
In an interesting twist, one of the authors of the Manifesto, Ron Jeffries, wrote recently that “agile” is whatever people do who call themselves “agile,” in much the same way as Christianity is whatever people do who call themselves Christians, regardless of any advice Jesus may have for them. I guess that means anything can be “agile,” regardless of what the Manifesto says. Decorations on the walls. Standing up. Sitting down. Whatever.
I wonder if the reason people have difficulty understanding what “agile” is supposed to mean is that we, the agile community, have made the whole thing so complicated.
Sticking things together
Here’s an observation: The “agile” movement is like a katamari ball.
Katamari Damashii (塊魂, or “clump soul”) is the name of an old Japanese video game, marketed in the US under the name I Love Katamari. It was popular enough to lead to a sequel, Minna Daisuki Katamari Damashii (みんな大好き塊魂, “everyone loves clump soul”), translated as We Love Katamari.
So, you operate this ball, the katamari, and when it rolls over a thing the thing sticks to it. The ball grows and grows as objects stick to it. You end up with this massive ball of stuff that the king uses to repair the universe (yeah, well, the storyline sort of bogs down at that point; the key thing is it’s fun to roll the ball around).
The “agile” community is like that ball. Any time an agilist hears about or reads about a good idea, even if the idea was first elaborated thousands of years before the Manifesto, all of a sudden that idea becomes “agile.” The ancient Egyptians were “agile” when they changed the slope of the Bent Pyramid. There’s agile this and agile that. Agile requirements. Agile planning. Agile testing. Agile organizational transformation. Agile hamburgers. Agile roofing shingles. Agile pimple cream. You name it. If it’s any good at all, it’s “agile,” and don’t you dare suggest otherwise.
In this manner a set of ideas that began life as a straightforward, pragmatic approach to delivering high-quality software has ballooned into an all-encompassing philosophy of life; the umbrella term for All Things Good.
Pulling things apart
Armed with the belief that everything good is “agile” by definition, and that you’re just about to die unless you do All The Things from cultural change to management style to technical practices, when you hire someone to help you adopt “agile” development they’re likely to insist that you can’t be Truly Agile unless you transform every aspect of your organization, and every aspect of your soul. They’ll want you to unlearn and fail and all that jazz.
The funny thing is that many companies ask for help with “agile” because they’re interested in improving their software delivery performance. Just that. They really aren’t interested in changing their mindset, culture, structure, performance management process, use of remote workers, or assumptions regarding fixed budgets and timelines. They haven’t decided to Change The World. They’re just looking for some mechanical process improvements. They think that’s what “agile” does. The poor dears aren’t even aware of all the cultural stuff their “agile” helpers are about to unleash upon them.
Agilists will remind us that the client can’t achieve 10x or greater improvement unless they do All The Things. No worries; improvement of 2x or 3x would please them greatly. You see, if the managers who hire us have been in their positions more than, say, 4 or 5 years, then they created the problem or, at best, they allowed the problem to fester on their watch.
If they achieve improvement of 2x or 3x, they will look like heroes. Their superiors will think they’ve been observant and proactive about improving things. If we make it obvious that 10x improvement is possible, their superiors will think they’ve allowed the organization to deteriorate to the extent that it’s only 10% as effective as it should be. They are going to have a Bad Day. And they will be sure to share the love with us.
So, to help these clients achieve their goals (as opposed to our goals), we have to pull apart some of the things we’ve been sticking together all these years. We can un-stick all the cultural stuff from the process-related and technical stuff. If a client really wants to go all the way, that’s great; we know how to do All The Things, the proverbial Whole Enchilada, or any other metaphor we can mix in. If not, there’s still a lot of good we can do. It’s really up to our clients…not up to us.