Friday, March 9, 2007

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


Unknown said...

At the beginning you mention Agile is a response to a problem..and imply that Waterfall is the problem (at least that's the way I read it). Is it worthwhile expanding on that? Does your dad, mom, brother-in-law know what Waterfall is?

Joe Little said...

Ummm. I look at Waterfall as a proposed solution to the problems, and being inadequate. (Perhaps better than where we were in 1969, but not where we need to be now.)
Are you suggesting that I should say more about Waterfall? My feeling is that most of these "newbies" often don't know waterfall, and if they do, our point should be...dealing with the real problems, not so much one inadequate solution. (Sidebar: Waterfall has almost as many variations as there are projects that use it.) Still, with some people, you do need to address Waterfall.
Make sense?

Kelly Waters said...

I think it makes more sense to discuss common business problems in delivering software development projects. These problems may, for some of us, be characterised by Waterfall, but in reality the problems agile development seeks to address are symptoms of other methdologies and many home-grown approaches too.

Kelly Waters

Unknown said...

I agree. When attempting to explain Agile to others outside of the software development business I find it helpful to put it in context to things people can relate to. Eg, methodologies like waterfall approach software development in the same way a basic manufacturing process is run. All tasks are well defined and can be scheduled and linked neatly together to produce the final output.

But software development isn't a well defined process...there are many uncertainties, unknowns, it's human centric, etc, and therefore attempting to manage the process in the same way a manufacturer would is not ideal. Enter Agile...etc.

Joe Little said...

Hi Cam,
Perhaps you are familiar with Defined Process vs Empirical Process, as Ken Schwaber talks about it.
What I find remarkable is how close the Toyota process for producing cars is to SW dev. You would think that cars would be mass production via a defined process. But they want quality and human-focus and adaptability and low inventory (and lots of other stuff), so they make it the Lean way. See the Poppendiecks, if you haven't yet. Regards.