Explaining Agile to your brother-in-law

Lately I have been trying to explain Agile to friends and family. To my wife, to my mother, to my brother-in-law, to business people who have never heard of Agile. Let's assume it is their first conversation using Agile with a capital A.

Where does one start? What must one say?

Response to a problem
Lean-Agile is a response to a business problem. Or really a set of problems.

The basic elements or needs are these:

• faster delivery of business value (or at least incremental delivery)
• deal with the human, team issues (communications, motivation, etc.)
  
• respond better to change
• set up better collaboration between the business and IT
• improve the working situation for the delivery team (key element: sustainable pace)
• release more team creativity to deal with harder problems

Waterfall (with all its flavors) and regular project management are proposed as solutions (in fairness, their main advocates were not attacking this exact problem set), but have not gotten the job done. Agile is an alternative solution.

When to apply?
So, when should Agile be used? My answer now is any time you have a small team situation (7 plus/minus 2). Or, if you have a larger effort, just scale it up with multiple teams working together. And the team and the people around the team are willing to try Agile.

So, Lean-Agile is for IT projects and for business projects. And for work efforts that people don't call projects.

What are the benefits?
The benefits can be stated many ways, but usually amount to these things:

• Faster time to market
• More business value delivered per period
• More accurate delivery of business value (the customer gets what they really need)
• More transparency for the business (the business can see where their investment is going, and how they can help remove impediments)
• More satisfied customers and shareholders
• More satisfied workers

My general rule of thumb is that in 2 years a team should be 4x as productive as before Agile.

What's the catch?
None really.

There is no guarantee that every agile team will succeed. If a team will fail, you learn that early, which is a good thing . If a team fails on a project, usually this will be because that team (or perhaps any team) is not capable of doing the work given them in the project well enough. The good news is that Agile will make visible that mismatch, and the project can be re-staffed or canceled.

Becoming really good at Agile takes time. It requires a mental and emotional commitment to persevere. You will get some benefits immediately, and sadly too many people who come to Agile think that's all there is. They don't fight beyond the complacency of that first plateau.

Agile is a bigger mindshift than most people think. For example, it asks that people become comfortable with a high degree of visibility. This is hard, sometimes. We are human, and we often are uncomfortable revealing our imperfections.

So, what is agile really?
Presumably the problems or the benefits have grabbed you. So you have read this far.

To this point we have given one explanation of why Agile was created and why you should be interested, but we have not explained what it is. Or have we?

Jim Highsmith has said "Agile is a way of thinking, not a particular practice." While this is quite true and important, it is not a satisfying answer to those who ask, "Well, how would I know Agile if I saw it?"

Here, I think, one falls back to a few things:

1. List the flavors of Agile (if they might recognize any)
2. Mention the fours parts of the Agile Manifesto
3. List a few things, as I am about to do

The flavors of Agile are of course not usually satisfactory, since this group often won't know any of them. The Agile Manifesto is wonderful, but usually too abstract for this group. And too oppositional to Waterfall (which this group also often does not know).

So, here's my list. With Agile you...

• focus on delivering small slices of concrete business value frequently (1-4 weeks)
• work with a small team of people, to enable them to be as productive as possible
  
• use concrete, understandable results to allow all parties to adapt and move forward
  
• arrange things so that change and learning are benefits
• tell the truth, and make the important things as visible as possible
  
• minimize waste and extra effort; maximize customer value, don't impress with hard work

Some comments. This is a definition that I hope most ordinary people can grasp. It allows for software and business kinds of projects. While it has some reflections of the Agile Manifesto and Agile Principles, it tries to seem (at least) more concrete and less theoretical. Which I think this audience needs.

This is the least unsatisfactory response I have come up with so far. What do you suggest?

Thanks, Joe