You’re not agile (redux)

You might think your team does “agile development.”  You’re not agile.

At Infocamp Berkeley this weekend, I ran a session called “You’re not agile.” I fully admit it was inspired by my anger from organizations who claim they’re “agile” when they’re really not.  Here’s an alternate take on what I presented…

A long time ago, waterfall development was the process used to create software.  Executives would make requirements, designers would make designs with the requirements, developers would build software from the designs, QA would test the software, the software would ship, and the cycle repeat.  Software development was treated like factory work because that was the only model of production they had.  Replace “software” with “bicycle” in that explanation and you’ll see what I mean.

However, waterfall isn’t ideal for software.  Requirements change, customers have limited input, and software simply isn’t hardware.  Using waterfall for software is like cooking a souffle using directions for grilling a steak — worst souffle ever.  Similarly, using a process that works great for manufacturing physical goods is a bad idea for producing software goods.

What is agile development?

As a backlash to waterfall, teams began experimenting with new methods.  These groups started with the premise that there must be a better way to produce software in a corporate environment.

For example, waterfall process is obsessed with documentation as the interface between steps of the process.  However, producing functional software is a far more important business goal, even if you skip writing everything down.  Similarly processes and tools are useful, but you can solve problems with communication way faster than following a checklist.

These values and principles are codified in the Agile Manifesto — a document well worth your time to read and understand.  It was written by a group of agile practitioners looking to forge a group identity for their new vision of software development.

Sadly, it lacks a concise definition of what “agile development” means, so here’s my take:

Agile development is a set of values and principles for improving your development teams’ alignment with your organization’s needs.

That’s a dense sentence.  Read it a few more times to make sure you get it.

Take notice that my definition and the Agile Manifesto do not say anything about specific practices that will make you agile.  Rather, agility is a shared mindset that you and your team use to solve development obstacles.  A team with this as a motivating goal is a powerful force for creating kick-ass-ness in the world.

The cargo cult of agile

News of successful organizational transformation with agile development methods started spreading.  Success breeds imitators, and other teams tried agile for themselves.  They started doing agile practices — like daily standups, iterations, and product backlogs — but never gained the benefits.

They became the cargo cults of agile.

The term “cargo cult” refers to a group who imitates another group’s processes but lacks the substance which makes those processes work.  The term was inspired by the actions of Pacific island inhabitants in World War II.  U.S. and Japanese troops would set up bases on these islands.  With these bases came regular shipments of goods, visits from planes, and formation marches by troops.

After World War II, the troops, planes, and bases left too, leaving the native inhabitants without their regular deliveries of goods.  To bring back those deliveries, some of them recreated the artifacts and actions of the visitors — building airports with dirt roads, airplanes and radios from bamboo and coconuts, and marching in formation as best as they could.

Sadly, the natives were unsuccessful in making additonal cargo drops reappear because they didn’t understand the visitors’ airplanes, airports, cargo, and radios.

Similarly, many organizations put agile methods into practice without adopting agile values.  For example, a manager orders the engineering team to start doing daily standups. The engineers perceive this as “managers are spying on what we’re doing” and treat it accordingly.  By contrast, an agile team knows that standups are for the team itself — and not for the managers — because the team values communication, helping each other, and self-organizing.

Because the cargo cult agile teams don’t internalize the changes their making, they don’t get better.  As a result, there’s been a backlash against agile development from the people who’ve had bad experiences where “we tried to do agile, but it just didn’t work.”  They give agile development a bad name.

Lessons learned

In my session, I went over a few agile practices and how they represent the values and principles of agile development, but I’ll leave it up to you to find additional resources on how to be agile.  Instead, I want to touch on a few motifs that ran through the conversations and questions I heard at Infocamp:

• Agile UX — How does design fit into agile?  In short, agile UX means “stop drawing pictures and just start building.”  Organizations are very uncomfortable with this; many UX designers don’t have coding skills to build prototypes, and managers and executives are wary about committing development resources when designs are incomplete.  It will take a real sea change to make this catch on.
• Becoming agile — How do you begin agile development in your organization?  It takes lots of things — a willing development team, executive buy-in, strong values, reasonable tools, and a great agile leader to guide the team.  But what’s even more important is this — start small.  Do one project “agile.”  Remove organizational impediments one by one.  Bring in new practices little by little.  And one more thing — don’t be afraid of failure; just keep trying.
• Management skills — Most schools don’t teach agile.  Hell, most schools don’t teach management skills at all.  The people I know who do agile well learned it themselves or from someone who kicks ass at agile.  In other words, agile development needs better marketing and education to spread the word and knowledge.

Another way to paraphrase the questions is this — “How can I learn more about agile and apply it to my organization?”  I’ll give you three next steps:

1. Learn about agile development.  Read blogs and books about it.  Find people who know about it and pick their brains.  Go see a kick ass agile team and how they work.
2. Decide what you value.  Then start looking at how your team runs. What are you good at already?  Where are the biggest gaps?
3. Start making small changes and close in on those values.  Share your successes, and keep trying to get better.

It’s lots of work, and there’s every risk of failure.  But it’s better to try and improve your situation than be stuck with something that’s broken.