Agile Principles

I often say that you can't do the dance if you don't feel the music.

In a discussion list now, there is a heated discussion about the principles that underlie Scrum. I hope no one hurts themselves. By which I mean to jest that we often have the biggest fights about abstract things ... about which we want, or at least tend, to disagree.

About concrete facts that all can see with their own eyes, it is harder to have arguments.

OK. Here are some principles that I see at play in Lean-Agile and in Scrum. Part of the fun of putting this list out there is the hope and expectation that you will discover for me yet better ways of expressing these or other principles at work. My list was done hastily, so you are welcome to complain. Also.

A quick list....
* all work-in-process is waste (and we want to eliminate as much of it as we can possibly imagine)
* two heads are better than one; three are better than two
* with our work, the productivity of the individual is fairly meaningless (no individual alone can produce the product); the productivity of a small group is meaningful
* bad news does not get better with age
* truth and love are the true foundation
* how hard we work is not important; what is important is making a few people's lives better
* we have failures in communication all the time; the problem is to identify the biggest ones as fast as possible, and correct them quickly
* the best way to communicate about this very abstract work is to make it as concrete as possible. And then get as full and direct feedback as we can bear.
* in theory there is no difference between theory and practice. In practice there is. Yogi Berra. One Meaning: In our minds all our ideas seems to work. In practice we all always see many mistakes and problems.
* knowledge creation is what it's all about
* "There are many things one doesn’t understand, and therefore we ask them: why don’t you just go ahead and take action; try to do something?" Fujio Cho.
* You learn fastest by small mistakes.
* Where there is no vision, the people perish. Proverbs.
* People are remarkably good at doing what they want to do. (Little's Second Law)
* I know it when I see it. Judge Potter Stewart.
* How does a project get one year late? One day at a time. Fred Brooks.
* You don't need to motivate them. You need to get the de-motivators out of the way.
* People work best when allowed to make small promises.
* Don't over-stress the system (the team).
* Because business and technology decisions are inter-dependent, business people and technologists must work together daily.
* There will never come a day when there are no impediments. We can always improve. We must work on the biggest impediment each day.
* "Depend upon it sir; the prospect of being hanged in a fortnight concentrates the mind wonderfully." Samuel Johnson.
* To predict is difficult, particularly of the future. (A Chinese proverb?)
* We are organic, transient animals. We are not machines nor are we constructs of the mind.
* There is a lot of variation amongst and between individuals. And perhaps more so amongst and between teams.
* Man is "a being darkly wise and rudely great". (Alex. Pope) Of a mixed nature. None of us will be perfect soon.
* Micro-managing workers never helps. A bit of coaching might help some.
* Pretending to be more productive by lowering quality is just pretending.

Your comments?

How do we know we have a good idea?

I was reading the new book by Bas Vodde and Craig Larman recently. Recommended.

In the beginning of the book, they give lots of ideas about "how to think". At first, I found this curious, although the suggestions were very good.

Only today did I connect it to what I think is our biggest problem.

This is how Yogi Berra (and Nancy V) put it:
"In theory there is no difference between theory and practice. In practice, there is?"

Or -- how do we know any idea is really any good?

We could assume, but as we know, that can have bad consequences.

In other words. In my mind, my ideas (and your's and your's) are always perfect. But only in reality do we find out they are always less than perfect.

So, how do we discover the stupidness in every idea? More quickly.

So, this applies each Sprint.
And this applies in changing from waterfall to Scrum. (Yes, Virginia, even Scrum will be a little rough around the edges when applied in real life.)

So, Vodde and Larman, at a high level, are helping you discover all the stupid "truths" you currently think are right. And helping give you a means to gently convince others that their strongly held truths are just plain wrong.

A respected colleagues says: Assume half of what you "know" is wrong. Seems good advice.

I think: There will never come a day when we are finished rooting out stupidity. In ourselves (so be a bit compassionate), in any one person, and certainly in the whole team and the larger firm culture. Toyota has gone further: they are rooting out stupidity in the flow of value from one firm to another.

Taiichi Ohno started implementing Lean at Toyota in the 1940's. He was not finished when he retired in the 1980's. I am thinking with Agile, while we can be a bit impatient, we also need to take a longer view. But maybe I'm wrong.

Is Agile useful now?

Why, yes, Virginia, the times they are a-changing.

You may have noticed a few not-entirely-happy things happening out there in the economy. It might even have affected you and perhaps even your place of work.

So, in what ways is Agile relevant? Now.

First, Agile is even more relevant now than before. (OK, just my assertion so far; see below.)

Second, for reasonable firms, it should be easier to implement Agile now, as there is a greater sense of urgency. (Yes, there are probably some areas with people running around like chickens with their heads cut off. Always some exceptions.)

So, in what ways is Agile helpful?

1. The team is the best unit to manage. (Organize people into Agile teams, and measure the success of the team.)
2. Agile teams adapt faster. Probably pretty useful in your neck of the woods just now.
   
3. For the team itself: Assuming a strong Agile team, that knows its cost, and knows its "multiple" (now much Bus Value it delivers for its cost), it is far easier to justify its existence in the face of layoff. Anyone getting a 200% return on investment these days? Well, a decent Agile team (with a decent Product Owner) should be getting that almost at a minimum.
   
4. Progress. Both in terms of increasing BV (business value) and in terms of increasing Velocity (story points of size/complexity) the team should be able to show a record of getting better all the time.
5. Faster time to market. That is, we get new products to market before our competitors. Or we respond to competitors faster than they expect us to.
6. Satisfaction. This one is actually for managers. You might be noticing that some of your people are getting demoralized or are lacking in focus. A normal human reaction. Agile does not have a silver bullet, but there is a great deal of satisfaction in working together in a decent team, and the biweekly or monthly Sprints keep the team focused on delivering. Maybe useful in your area just now.

The transformation to doing Agile (or doing it right) is hard, yet cheap compared to the alternatives. Or so I think, and would be happy to prove.

There are a few thoughts. What else do you find?

Up the creek. Without a paddle

My friend Mike Vizdos has a blog with cartoons called ImplementingScrum.com.

His latest cartoon is titled "Up the creek. Without a paddle." See here. The idea is that, if you want a specific change to happen or even to stay, you have to keep paddling.

Very simple idea. Very true.

Agile (Lean, Scrum, XP, etc) is a change. A hard change, although also fun a lot too. If you do not keep paddling, then Agile will be viewed as "the flavor of the month". And things will revert to the mean (probably not good Agile, would be my normal guess).

If you stop paddling, things will continue to change. But not in the direction of better and better Agile.

To me, it is a shame to see people stop paddling in the direction of their dreams. Doing one's best is hard, but it is something to be proud of. Something to live for. It may not always be fun, but in a deeper sense, joyful. Every success you have is an example for every other person who feels partially defeated. And the customers around the world need the great stuff you can create. Real customers. Real people. Kids, grandparents, mothers, brothers, sisters, fathers.

(As an aside, let us admit that even customers are not perfect. Many can be pretty bad sometimes. But we still feed even the lesser ones despite their weaknesses. Let us not pray for justice, for who would escape whipping. Let us pray for more generosity than that. The wiser ones have told us: It is more blessed to give....)

So, I hope you will see the value of Agile (of Scrum, XP, of Lean, and related ideas). If you do (and of course it is your choice), prepare yourself for the relentless pursuit of perfection. Prepare for the long march (my phrase for it). Keep paddling.

And have fun doing it. We should enjoy even the struggle part, as it makes us better.

Your Business Case for Agile

My friends at Innovel have a blog entry titled "Build Your Business Case for Adopting Lean Agile". Take a look.

As you try to get a revolutionary idea adopted, remember that you must always be selling the idea (see John Adams to the right). (Note: You don't even need 50% of your countrymen to agree, if you would succeed.) Your idea may be brilliant, may even be one of the best ideas ever to appear on this planet, yet you must still sell it.

To start anything in business, you need a business case. And given that everyone has a say and an opinion, in fact you need to have a good feel for all the benefits involved, so you can explain the WIIFM to anyone. (WIIFM = What's In It For Me)

And given that change is happening all the time, you even need to keep your business case up-to-date, since Agile will always be challenged with some equivalent of "what have you done for me lately?" People change. People forget. Attention gets re-directed.

So, what is the case?

Well, coincidentally Israel Gat of BMC is giving a talk this week at Agile-Carolinas (and another at APLN-Richmond). "Leading the Disruption". The idea that for BMC, Agile was so successful that it was disruptive, particularly for downstream processes. Such as sales and marketing. In a prior presentation he had shown hard data that to me proved that Agile had given them double the productivity for a large IT shop, compared to essentially waterfall (compared also to what they were doing before).

There are many people to whom we must make the case. Let's assume for now, to a senior business manager (maybe the CEO?).

BMC so far has doubled productivity. Umm. Impressive. In fact, Scrum (the main flavor of Agile that BMC use) was built to increase productivity by 5x to 10x. And it has been proven to have done so with some teams (the community has data in various papers). We don't (yet) have the broad based data to show whether "some" really equals many, most, likely, X%, for certain types of teams, etc. , etc. Based on the anecdotes I hear, most teams are clearly better even when not doing "most" of Agile. And teams that adopt Agile well are typically very much more productive.

Let's look at this a different way. The multi-functional IT teams (including business people, etc) are producing: more, faster, cheaper, and better. All at the same time. As in, higher quality, more accurately what the business needs (not just what they said), faster time to market, etc. What's not to like?

Another benefit senior managers like is visibility. They can tell whether an effort is on target or having problems. (More on this later.)

As Jeff Sutherland says, the ability to change directions quickly, and to focus this fire hose of productivity on a competitor's new feature is very valuable.

As an aside: One thing not to like is people doing cowboy agile. That is, people saying they are doing agile, but who really are not. At the extreme, this means people whose definition of agile consists of "we don't do documentation". Cowboy agile makes your audience more skeptical of real agile.

OK. One more thing on this topic.

How do you prove this for yourself?

Take people to the Gemba; show them the team room, the team, the product owners of successful teams, the working software. (Gemba is a Japanesee word, famous in Lean, meaning "the place where the truth may be found.")

Also, gather metrics from day one. I will talk about other metrics later. Today let's talk about velocity. Gather velocity (the sum of the story points of Product Backlog items completed in an iteration). Show that it is reasonably consistent from sprint to sprint. Then show the velocity increasing. Remove some more impediments. Show it increasing more. Impressive. A blind man can see this stuff.

If the velocity increases by 50% and the business value of new stories is not diminishing, then clearly you've got something going on. All you have to prove is that Agile is a good investment compared to other investments. Not hard if you work at it.

Will every team succeed? No. (Actually even failure is a success with Agile...topic for another post.)

Can fairly good people generally show impressive progress? Yes!

Developer Abuse

Here is another video that talks about why we do Agile. These two (this one and the one just posted) were the top two vote getters (from a perhaps somewhat biased large audience) at the Agile 2007 conference.

It's a bit serious, I think.
Perhaps a bit overdrawn, but I do think developers have a better life with Agile.

My view is that in Agile, we are trying to make everyone's life better: customers, managers, team members, business guys, end-users, our own families. One would hope, that after all those people are helped, that society more generally would be better.

Being Agile is our favorite thing

Here is a fun video from Thoughtworks, titled "Being Agile is our favorite thing".

It might be used as some "evidence" to use to start a retrospective.

The Nokia Test (1): Iterations must be timeboxed

I will be doing a series of posts that discuss each element in the Nokia Test (see earlier post). In this first post, we will focus on the first element in the Nokia Test: "Iterations must be timeboxed to less than six weeks."

First, remember that the first section of the test is to determine whether a team is iterative. (The second section determines whether they are doing Scrum.)

This first element, the length of the iteration or sprint, in standard Scrum according to Ken Schwaber is one month. There are many Scrum teams now doing 2 week sprints. Or even less. Note: One version of the Nokia Test that I have seen says iterations 6 weeks or less. This is a standard in iterative or Agile, but not in Scrum (which is 30 days (4 weeks) or less).

The iterations are time-boxed. This means that the length of the iteration does not change from iteration to iteration. And we do not extend any single iteration (or sprint) because "we're not quite done yet".

Why are time-boxes important? First, "when a man knows he is to be hanged in a fortnight, it concentrates his mind wonderfully." (Samuel Johnson) It is easy for us to get distracted, and the time-box forces the team to face the real world. It forces them to cut through analysis paralysis.

Time-boxes are also wonderful is a slightly different way. You are no doubt familiar with the Pareto principle (aka the 80-20 rule or the law of the vital few). So, the team is forced to choose those "20" most important things to do and get done in that time-box, out of the wonderfully long list of "100" good things to do in their lifetimes.

And, by making the goalposts immovable, the team starts to see that the time-box has meaning. They must estimate better or work better or in some other way improve if they want to complete their work consistently every iteration.

The time-box also enables the team to reflect, on both their work product and on their work methods and approaches. And to get feedback, and make mid-course corrections. This feedback mechanism is not stated specifically in the Nokia Test, but to me the feedback is in there because it is such an important part of Agile and of Scrum.

We will come back to the usefulness of the time-boxed iterations as we discuss other parts of the Nokia Test. While, for the sake of small blog posts, we are looking at each element, it is really when the elements are together that the test starts to have real power or meaning.

The whole is greater than the sum of the parts.

Keeping with the Beat

Where would I go to find the latest information on Agile and Lean? What if I had a question and wanted expert advice?

Try these "boards". Sign up. They are free.

ScrumDev

Extreme Programming

Agile Project Management

Lean Software Development

Industrial XP

I am a particular fan of the last one. It's theme is applying XP in large, enterprise situations. Some very good conversations.

Advice: As with most things in life, you get more by giving more. Dive in, don't just lurk. Receive postings in a Daily Digest (change it at "edit membership").

Caution: There is some "inside baseball" or "inside the beltway" stuff going on. Bring your salt shaker. Sometimes a board or several boards will seem to become obsessed with one topic. There are many reasons for this, but if you need a discussion of a topic, search the history or ask a new question. Ask and it will be answered. Seek and you will find. Be selective. Use common sense.

There are some great people on these boards. Some of the comments are pearls beyond price. (And some are rubbish.) YMMV.

If you are interested in similar boards, tell me. There are others for more specific topics.

Business Value: Some useful links...

Here are some related links you may find useful...

Marco Abis sent me these links:

http://www.mythodology.com/technicality-business-awareness-now-what

http://www.mythodology.com/why-business-acumen

I like these principles of Lean, especially the first one, about specifying value:
http://www.lean.org/WhatsLean/Principles.cfm#specify

And I like this HBR article by Womack and Jones on Lean Consumption:
http://custom.hbsp.com/b01/en/implicit/custom.jhtml?pr=LEANER0503C2005030462
See what they call the 6 principles of lean consumption. I call 'em a pretty good summary of what people want.

You need to know about Net Present Value. Here's a start. Don't forget the shareholders. They are people too. As are other capital providers.

You need to know about Peter Drucker. Here's a start. See the last bullet in the list of basic ideas. The first phrase was revolutionary in America at the time.

You may also wish to review the first principle of agile, here.

"THERE IS AN OLD SAYING in the media business (at times attributed to David Ogilvy) that your most important assets go down the elevator each night." See here. Don't forget the workers either (and that includes the managers too). Without their many capabilities, nothing would be created.

Business Value: What is it?

On Wednesday, I will lead a session on Business Value in Charlotte, NC. That night the topic will be "what is it?" This is part 1 of the full session I will lead at Agile 2007. (Part 2 in Charlotte will happen on May 24th.)

My hypothesis is that we don't know as much about Business Value as we need to know. And that we are discovering business value all along the way, just as business value is changing. (What? Customers change their minds?)

In that session on Wednesday we will discuss these questions:

1. Why is Business Value important?
2. What is Business Value?
3. Which definitions of Business Value align best with which people?
4. What do customers really want? What did you buy today and why?
5. Does the Business Value of a project ever change? Why? How did you discover that change?
6. Which tools should we use to uncover Business Value?
7. In a project, who should care about Business Value?
8. Does Business Value seem easier or harder now?

To me, this all relates to what Yogi Berra said: "You've got to be very careful if you don't know where you're going, because you might not get there."

Do all the people on your team agree on the definition of business value? Is it tangible to them? Are they always driving toward it (and nothing else)? Or do they, like most humans, say after a few days "what was it you wanted?"

Lean-Agile Resources

We have put together some Lean-Agile Resources on this page. Please give us your feedback and suggestions.

Agile is like golf

I went to New York last week, to visit friends and to visit one of the greatest cities in the world. Wonderful energy.

A fairly well-known joke line goes like this: How do you get to Carnegie Hall?
Answer: Practice, practice, practice.

This is one of my main points as I watch The Masters golf tournament today from comfort in Greensboro, NC. These golfers have been playing under tremendous pressure and under very difficult conditions for 4 days. In a world full of duffer golfers, these are the masters of the masters.

And yet in Agile, it seems so many expect to be masters at Agile in 2 iterations, or 2 months, or 2 years.

In golf, one must practice putting, practice the short game (chipping), one must practice sand shots, and irons, and fairway woods, and one must practice tee shots. I particularly like Rule 13: "The ball must be played as it lies."

In Agile, you must practice getting value from released software, practice releasing faster, practice all the engineering disciplines in developing software, improve the TDD and continuous build process, improve the Scrum practices (including especially realizing the value from retrospectives), improve the use of user stories, and improve the definition of business value embedded in the user stories. And, along with all this, practice the communication within the team, and improve the leadership and motivation of the team. While all the factors around the team are changing. And the team must play it as it lies.

May your team reach the Masters.

Never send to know for whom the bell tolls

In my culture, this is the beautiful, daffodil time of year. When spring is sprung.

And when Passover and Easter come to pass yet again.

The long cold winter is over, and the stream of life bursts forth in joy. If just to be alive again.

With Easter, we see presented to us again, it seems for the millionth time, the mystery of death and re-birth. We learn again that we are not just matter, not just a bag of water and a few minerals, priced (I used to hear) at about 98 cents. We conquer death... for Christians, through our Savior. And, if I understand correctly, each of the great religions also conquers death.

Why do I mention all this is this blog? While I won't get too personal, some of these have been themes in my personal life for the last year or so. And even in the last few weeks.

But let's return to Agile & Business. So, if it will not seem profane to some, let us mention a few connections, although I think many more connections could be made.

First, Agile and Business are for the whole man. Not just his material wants, but all of his wants. Yes, it is concrete and limited; business does not stand awaiting perfection before trying to deal with some basic human needs. But business is involved in all of man's wants and needs. Business is involved with death. And with the new-born baby as well. Indeed, in some way with all of our hopes and dreams.

So, Agile tells us to see the whole man. In the customer, in the worker, in the shareholder. In each person we deal with.

Agile also calmingly invites us to little deaths. To small failures, so that we may learn, and in time have the greater triumph. Agile does not protect us from the awful truth; we still can die and we still can fail in a big way. But Agile shows us, if we watch and listen, how to have small failures and learn from them.

The title of this post is from John Donne, MEDITATION XVII. I urge you to read it. If you know Hemingway, you will recognize a title or two in Donne's works.

Donne observes that no man is an island. This is a lesson that Agile has incorporated by bringing all the people together. All of the technical abilities are brought together into a whole team. And the business side and the technology side are brought together to collaborate. Perhaps there are still a few projects that one man can still do, but they are few these days. So, Agile is a way to learn how we are engrafted, one to another, and yet at the same time free. A paradox it may seem, but still true.

Donne asks us also to learn from the afflictions of others. Perhaps you see others doing Agile not well enough. Perhaps you see Agile now waxing and now waning in one firm. While this may seem a borrowing of misery, yet if you learn from it, you will mine its gold. Be patient. With them and with yourself.

Life and Agile may seem to you far better ideas than their opposites. But everything must to some degree follow the patterns of life and of the universe, like the tides and the waves. If you are truly clever, perhaps you will help the people see that Agile is not just the latest wave (in IT, in project management, or in management nostrums). Perhaps you are helping them see it is more fundamental. But nonetheless, it will still wax and wane. Be not discouraged.

May the brightness of the new flowers (daffodils or whatever is near you) give you joy. And may you fulfill the promise of their hope.

Getting Business Decisions Made - 2

A few days ago I posted on this subject. This is a continuation of that post...

I had already discussed the first of Esther Derby's 6 steps. (Again, I am trying to discuss something different from what she was going at, so naturally there will be differences.) For her 2nd step...

2. Determine what’s important to the person who makes the decision.
First. decide who you think the decision-maker should be. Try to arrange things so that the right decision-maker is involved, or the right group of people is involved. Often, hearing intangible benefits from multiple people will make the benefits more real to the decision-maker.

Second. One model is a single decision-maker and multiple advisors. Another model is a loosely defined decision-making team. Think through what the model really is in your situation.

Third. Consider what you think ought to be important as decision criteria. If what you think is important is not congruent with what the decision-makers think is important...consider a short or long campaign to influence their thinking. Say something like "I consider A, B, C, D, and E as the decision criteria, and I weight them as 10, 7, 3, 2, 1. What do you all think?" A campaign can be that simple.

3. Ask that person who they consider credible sources related to the issue.
Esther's advice here relates to hard-to-measure benefits. At a higher level, you are asking: "What kind of information would it take to get you to approve my proposal?" Esther's hypothesis (generally valid) is that absent conclusive hard data, most decision-makers will accept one or a group of "expert" opinions.

In her post, Esther describes multiple things that the decision-maker valued, so naturally (and normally) no one person could be an expert in all those areas. Thus, you need a set of experts' opinions.

More generally, sometimes success is in finding a disparate set of information that, taken together, gives the decider confidence in making a reasonable decision. Maybe: (a) benefits, (b) risk reduction, plus (c) no better alternate course of action. Imagine how you would think making a chess move. Often business can be even more complex than chess in the number of factors that come into a decision.

Remember that you want the decider to feel you are helping her (or him). You want to checkmate the decision; pinning the decider might gain a different and more emotional reaction to your request than you are looking for.

4. Create a short interview protocol.
Again, Esther's advice is appropriate for her case. A more general step is "figure out how you will collect the information", whether by one method or five.

More general advice here is also not to make data collection too onerous. Ask the decider "if I collect this and that info, would that be enough to convince you? I don't want to get into a bigger effort if something smaller would be enough."

Often the decider will say "collect what you can in X days, and come back and show me what you have". Some remember how hard it is to come up with good data.

5. Interview the people the decision maker identified as credible.
Here the general advice is...collect the information. If you haven't done it already, make sure the information is credible to the decider. Or say "here is the info I have collected so far, this is what I feel the information says...but do you feel it is credible?" Be ready to receive input that is it not (yet sufficiently) credible. If you asked in the right tone, she won't be thinking "well, I can't trust the info he brings me anymore."

6. Summarize and present the results.
Sometimes it seems you only get to present once to the decider. Maybe true for one decision. But as mentioned, I am proposing that you not worry about one decision. You are trying to influence for many decisions. And you are trying to learn "how does this manager make decisions? And in what ways can I influence her?"

Esther's point is, of course, well-taken. Every time you present to the decider, think about the kind of presentation that appeals to her. Example: Is it summary first and then selected details? Or build and build details, and then look at the summary? (And lots of other variations of this.) Almost every decider wants a summary. Almost every person wants a summary that has no more than 3-5 bullets. And there are lots more aspects to "presentation" than this.

As a last suggestion. Each person has different kinds of information that they will find convincing. Decisions must be made even if the ideal data is not available. Sometimes a combination of harder data and softer data is convincing. Sometimes you only have 1 to 3 expert opinions. Sometimes you can get a decision if you say "Why don't we try this as an experiment, and see if it works?"

Let me repeat a key point: Costs should never be looked at in isolation. Always consider the benefits and costs together. (And if you want to consider risks as something different, then the upside and downside risks as well.)

Where there is a will, there is a way. You can get more business decisions to go your way.

Judgment Under Uncertainty

Tom Peters' blog has this post about Judgment under Uncertainty: Heuristics and Biases, by Daniel Kahneman, Paul Slovic, and Amos Tversky. They are psychologists. But Kahneman won the Nobel for Economics for prospect theory.

But the issue is making decisions in a world of uncertainty seems quite relevant to Agile. For the customer, for the business side, for the development team (including the Product Owner). Suffice to say that my bias is that people aren't always as rational as we sometimes think they are.

People have the idea that (a) a collect all the data needed, (b) I analyze it, and (c) I make the right decision. Most business people know this is a senseless model, totally unrealistic. As the head of Google said, he wants to get more "at bats" than anyone else. (This comment makes sense if you understand that Ted Williams story about batting averages. Ted Williams holds the highest career batting average in the majors of anyone with >500 home runs. It is .344.)

More on this later.

You might also wish to look up Kahneman and Tversky.

Customer Value & Lean

To discuss Lean and Lean Software Development is a long task. Permit me to start slowly, with background, and to start with some digressions.

There has been a lot of talk lately of the auto business. What will happen to Chrysler. Is there something there we can learn. (Hint: Lean is being used outside the auto industry.)

Lean, as you know, is mostly closely associated with Toyota and two men: Taiichi Ohno and Shigeo Shingo. They of course were strongly influenced by Deming and Henry Ford. When asked a question, Mr. Ohno famously said, "Oh, I got it all from reading Today and Tomorrow by Henry Ford". The story of the people and their courage and inter-relationships is interesting. I doubt that you can read too much by Ford or Deming. Or by Ohno or Shingo. (For myself, my grandfather was a GM man quite some years ago now.)

What has all of this to do with Agile & Business?

In my mind, the first principle of Lean is this: Value is defined in the eyes of the end customer. See Lean Principles at the LEI. This from Lean Thinking by Womack & Jones:

"The critical starting point for lean thinking is value. Value can only be defined by the ultimate customer. And it's only meaningful when expressed in terms of a specific product (a good or a service, and often both at once), which meets the customer's needs at a specific price at a specific time."

In Lean Solutions, Womack and Jones speak for all of us (as customers) when they say we want our problems solved. We don't want a product, we want our problem solved:

"Solve my problem completely."
"Don't waste my time."
"Provide exactly what I want."
"Deliver value exactly where I want it."
"Supply value exactly when I want it."
"Reduce the number of decisions I must make to solve my problems."

And, if you are younger, you might add: "And give me something that is waayy cool to be involved with."

When we are doing Agile, we are already trying to get close to the customers. To get frequent feedback from the customers. Even to collaborate with them. In Scrum, we have the Product Owner (and she with the whole team must be asking how well is she representing all the end customers).

The customers are changing fast. Are you working at it enough in your project today?

* * *

In the Agile Community, Mary and Tom Poppendieck are the ones most closely associated with Lean Software Development. See their site, here. I will be talking more about these Lean ideas in future posts.

Joe Little

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