Thinking for Yourself

Here is a good blog post about why thinking for yourself is important in Lean.

http://bit.ly/iH4tC

Poppendiecks: Designing a Lean Development Process

The Poppendiecks have a new advanced course (all welcome, but people already experienced in Lean-Agile will get more from it).

Designing a Lean Development Process.
Mnpls, June 9-10

Based on their new book (about to be released).
More info: See here.

Productivity Now

The economy is in a bit of a tailspin. Chairman Ben may have his way of helping us. But we can help ourselves. If you wait for the Wizards of Washington to help, you might wait for the wrong basketball team.

How do we get ourselves out of this jam?

We need a simple way of telling if we are productive, if the seemingly "brilliant" ideas are actually useful. And of telling whether this group of people or that or those is productive.

How? Measure productivity by team. The Team is the unit to be measured (not the individual, and not a larger group). There are many reasons to measure by team, but the main one is that only the Team can create enough useful knowledge to create (or produce) a (new) product. 7 people, plus or minus two.

Measure it in short iterations...a week, or two or a month at most.

And ask the Team to improve.

If the Team is not producing enough (say, compared to their cost), disband them and tell each person: "Go join or start another Team." If the same person is on two failing Teams, he probably needs to look elsewhere.

And all those other guys who aren't on the producing teams (or any team), why is it that we need them? What value do they add? (Yes, Virginia, they could join a team doing real work. Since they aren't used to it, we'll give them some time to remember how to do real work.)

So, some Teams can fail. But you will generally find that the Team gets creative and productive. They find something to sell that customers actually want. Even customers now.

To do this well, you have to measure productivity. I know there are lies, damn lies and statistics, but you need a little bit of something to make business decisions.

Translation: What I am recommending is Scrum for the whole business. I would recommend Scrum be in the context of Lean thinking about the whole business (although I did not explain that here at all in this post.)

Get on with it. We have a bunch of people to pull out of this economic cycle. Much as we enjoy Scrum, we didn't get into this just for ourselves.

Kaikaku or kaizen?

As you know, kaizen means continuous improvement. Implying a bunch of small improvement over some period of time.

Small continuing improvements have many virtues to recommend them.

But what if we need a big change? What if we can make a big change? What if a big change is the only things makes sense? (eg, small changes in isolation won't show any improvement until bunch of other changes are also made.)

Then we have kaikaku. A rapid, large, revolutionary change (as distinguished from a set of small evolutionary changes...kaizen).

In Agile, one example is a 2-day Scrum course for the whole team, followed by immediately diving into doing Scrum.

Even kaikaku does not attempt to change everything at once. But it does make a group of changes "at one time" that together are major.

All the time, the Agile coach is asking..."is it time for kaizen, or time for another kaikaku?"

What is the scope of impediments?

Last night at Agile-Carolinas we had Israel Gat, VP of Distributed System Management at BMC Software. He spoke on "Leading the Disruption". He is giving this talk also in Austin, TX (and maybe elsewhere). If you get a chance, I urge you to go. Or just contact him.

After that meeting, I had several conversations. And then thought about them this morning. All that results in this post. Or at least, this question?

What is the scope that defines what might be an impediment?

By definition in Scrum, an impediment is anything that keeps the team from being more productivity. And I personally add that everything is imperfect, so by my definition everything is an impediment to some degree, and the trick is to identify the one or two biggest impediments today.

Scrum has also said that the scope is wide, including such diverse things as engineering practices and personal issues.

What I have not seen talked about much is the scope from an end-to-end Value Stream perspective. So, I would argue that anything that reduces the business value of what the Team produces (or the speed with which the value is realized) is an impediment.

So, as a simple case, imagine you have a Dev team in Charlotte and an "implementation" team in Chicago. (In this context, implementation means all those services around the software that make it actually useful in production.) The Dev team completes their work. The Implementation team is not ready (certainly not as ready as the runner to the right). So no business value can be realized.

I am suggesting this is an impediment. Perhaps the top one for that Dev team. And that Dev team (and their ScrumMaster) need to assure it is fixed (understanding that "a dead ScrumMaster is a useless ScrumMaster"). They probably can't fix it themselves, but they can make many efforts to get others to fix it. Perhaps they need to enlist a manager's help.

To me, this is similar to what Toyota found, ie, that to get the full benefits of Lean, they needed to aggressively train their partner firms upstream and downstream from them in the Lean ideas around flow, pull, JIT, etc, etc.

Does this make sense to you?

Mura, Muri, Muda

These are Lean words. In Japanese. And I always get them confused, especially the first two, so I am doing this post partly to have a place to remind me what each word means. They are all in the negative.

Mura: unevenness of flow. Thus, the first thing to do is establish a reasonable pull, an even flow.

Muri: overburdening the system. (System being the overall thing you are talking about; generally not a computer system.) Thus, once you establish a production "pipe", don't try to force more through that pipe than it can handle. As a fluid dynamics person will tell you, if you overburden the pipe, it means even less liquid will travel through the pipe in a given time period.

Muda: waste. This is further defined by Type I and Type II muda. And by the classic 7 wastes. "Muda" is an ugly work in Japanese. Kind of like an earthy but dirty Anglo-Saxon word, I think.

The classic definition of Type I muda is necessary waste, ie, something that does not add value in the customer's eyes, but we feel, as a business, that it is necessary. (Compliance with government regs might be an example.) I call this "waste we have not yet figured out how to live without" (maybe not true of all things in this category).

The classic definition of Type II muda is unnecessary waste. I'll call this obvious waste (as soon as you put yourself in position to see it).

There is of course an inter-relationship between the three (mura, muri, muda).

In general, I find these ideas very similar to things we say in Agile, Scrum, XP, etc.

Jim Womack suggested that Lean thinkers practice those in that order, ie, focus on mura first. Then muri. Then muda. Perhaps this is good advice for Agile. (BTW, if you don't know Jim Womack, get one of his books: Lean Thinking. Recommended.)

Respect People

"Respect People" is a key tenet of Lean. Of course, who wants to disrespect people?! Still, when people study why Lean works in one company and does not work in another company, the answer the some of the best people give is: Respect People is truly realized at the successful companies.

Jim Womack leads the Lean Enterprise Institute. Go to lean.org.

Womack & Jones wrote Lean Thinking, which you must read.

Last December Jim Womack wrote a letter, in which he talked about what "Respect for People" means in a Lean context. Here's a key quote:

Managers begin by asking employees what the problem is with the way their work is currently being done. Next they challenge the employees' answer and enter into a dialogue about what the real problem is. (It's rarely the problem showing on the surface.)

Then they ask what is causing this problem and enter into another dialogue about its root causes. (True dialogue requires the employees to gather evidence on the gemba – the place where value is being created -- for joint evaluation.)

Then they ask what should be done about the problem and ask employees why they have proposed one solution instead of another. (This generally requires considering a range of solutions and collecting more evidence.)

Then they ask how they – manager and employees – will know when the problem has been solved, and engage one more time in dialogue on the best indicator.

Finally, after agreement is reached on the most appropriate measure of success, the employees set out to implement the solution.

This is not simple. It does not say that one person knows everything. And it is not mere consensus building. It is engaged and committed knowledge creation. With some healthy "intellectual fighting".

How does this sit for you with Agile? Does this approach make sense with managers outside the team working with team members?

I will guess that it provides more respect to the team member than many actually get now. And also more engagement with a manager than many get now. At least that is what I have typically seen.

5 Whys: To get better, say "why?"

If you have a 2 year old, or remember them, you are familiar with the word "why". Repeatedly. Now, a more adult way to use that word.

Lean tells us we should ask "Why" all the time. In fact, the 5 Whys. To discover the root cause of a problem. So we fix it once and for all.

Here's how Taiichi Ohno explains it:

It is difficult to do even though it sounds easy. For example, suppose a machine
stopped functioning:

1. Why did the machine stop?
There was an overload and the fuse blew.

2. Why was there an overload?
The bearing was not sufficiently lubricated.

3. Why was it not lubricated sufficiently?
The lubrication pump was not pumping sufficiently.

4. Why was it not pumping sufficiently?
The shaft of the pump was worn and rattling.

5. Why was the shaft worn out?
There was no strainer attached and metal scrap got in.

Repeating why five times, like this, can help uncover the root problem and correct it. ...get the real cause...which is often hidden behind more obvious symptoms.

Do you ask the Five Whys every time you have a bug in your software?

To hear further explanation from Taiichi Ohno, see chapter 2 of his short book:



There are many other great ideas in this book.

Have Compassion

Today I was in a meeting with Business and Technology folks, and I started talking about Customer Collaboration over Contract Negotiation. (Many will recognize this line from the Agile Manifesto.)

And I talked about how, always, there is distrust and tension and misunderstanding between the Business side and the Technology side. Well, at least on day 1 in every client I walk into. YMMV. With luck, we start building trust right away.

In thinking about this on the plane back home, I wanted to say something to those 12 people. And since they are not with me now, I will say it to you.

Have compassion.

What do I mean by that really?

First, the most important thing is that it is more blessed to give than to receive. More specifically, it is not about you. It is about doing for others, most especially for the end customer.

Let me introduce my second point with a story. When I teach Agile I like to start with the story of the 6 Blind Men and the Elephant. I won’t explain that story now, but one reason I like it is because that story is also related to Buddha. The compassionate Buddha, as he is known. And Buddha had great compassion for us, and our inability to comprehend all the knowledge we needed to know, and to figure out what is really important. And I say, we team members should have compassion for each other and how hard our work it, how much we need to learn. We try to solve the problems if a person who almost always is not there, and do it with a system that is abstracted and non-concrete in the extreme. And all the easy projects have already been done. Difficult work. We need compassion.

My third point is more specific. My experience is that most Technology folks have no conception of how difficult it is for the Business folks to see and be accurate about what the business need to do to satisfy their customers. The customers are changing, the competitors are changing, they don’t have time to understand what is do-able. This is extremely difficult work that only a few are truly insightful about. (In our economy, many are modestly lucky.)

On the other hand, the Business folks need to have more compassion for the technology guys. Technology work is extremely challenging, and offers great opportunities for creativity and discovery for those Business folks willing to travel those uncharted seas. And capable of escaping the dense fogs.

My fourth point starts with Deming, who has many valuable insights. Deming said that all problems in business are caused, in simple terms, by two things: “the system” and the people (vices, true inability, laziness, etc.). The “system” was all the things that were (or were not) there to structure the people and the work to get the work done. Initially he guessed that 80% of problems were caused by the system and 20% by people. As he grew older and learned more he revised that. I think he finally said that 95% of problems are caused by the system and only 5% by the people. And a leader's job is to get the system improved.

My point here is that, while you may be frustrated in some ways with your colleagues, most of your frustration is not about them, but about how “management” (maybe yourselves) have structured the system through and in which you work together (or not together).

Have compassion. Have patience. And start improving it today.

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.

Leaders, Managers, Bosses, and Administrators

The Poppendiecks are coming to Charlotte next week, to teach their Lean Software Development - Practitioners course. In their book, Implementing Lean Software Development: From Concept to Cash, the Poppendiecks talk, as one of their topics, about leadership.

They raise several excellent points.

1. A team needs leadership. Which is to say, vision. Someone to inspire and someone to help them put their hearts in the game. And keep it there.

2. The project needs decisiveness. If the team has too many leaders, and the leaders squabble about decisions, then the team wastes time. The team needs to know how it will make decisions. There is a trade-off between making the right decisions, and making decisions quickly.

3. Generally, the team needs to learn to make decisions only at the last responsible moment. So, much of the decision-making is about when to make a decision. At what point have you learned enough to make a good/better decision?

4. The project needs business decisions and technical decisions. This is very true. So the team needs business people and needs technical people who are ready and able to make those decisions. And, preferrably, business people who understand technology and technology people who understand business (and the customers).

5. And there are many other types of decisions to be made too. People decisions. Decisions about whose insights to go with on specific areas. Process decisions. Decisions about who is working effectively and who is not. Decisions about how to get the team to communicate better and learn faster.

6. In Scrum, we have ScrumMasters and Product Owners. These roles are endowed with certain leadership aspects. This is different than the leadership of the Chief Engineer, which is a role Toyota uses.

7. Project managers have also provided leadership. (And we have the whole PMP, PMI thing, too.) PMs have also provided managership, bossiness, administration and other things.

8. We know that no bosses are wanted. We want all the best from every person, and a boss will only inhibit that. A boss wants to command others, and thinks he knows all. These are not helpful traits in a learning situation. (So, semantically, we are using "boss" here to represent all the bad things that a boss can be. Of course, few managers or leaders are as bad as a boss, but we all can be that way sometimes.)

[Note: One can certainly argue whether everything in the 8 items above was said, implied or meant by the Poppendiecks. Doubtless at least some of it is me muddying the water.]

* * *

Let us add some additional thoughts.

We always find true leadership in short supply. A true leader does not just say "Go there!". He or she must explain things to the group (the team and those around the team) in such a way that they understand. In such a way that they agree not only with their mind but with their heart.

Thus, we say that everyone can lead and should lead. In some way or another. (This is not to invite conflicts about turf and other silliness. See below.)

Leadership and all these other topics are great to talk about in the abstract or as generalities. Where the rubber meets the road is after you have found the best people you can, and they start to take on certain roles. The role was made to help the man, not the man to fit into the role. Always adjust the role to fit the people involved.

Decision-making: We want to distinguish this from what we mean by leadership. First, the team must be very clear (a) when a decision needs to be made, (b) that all parties with anything to say on the subject have the opportunity to contribute, and (c) the team knows how the decision will be made (eg, maybe that one person will make the final decision on X topic). (Note: At the other extreme, the team norms might say that the team will vote on every decision. In my experience, this approach can work with some teams and not with others. There is a long explanation as to why.)

If you "decide" correctly about (a) what is the question to be decided, and (b) when should this decision be made, often the final step (what we might call "the decision" itself) is quite easy.

We take the view that most decisions are reversible. So, often the decision is more "what is our working hypothesis for now". Most decision-makers realize that deciding is like batting in baseball. If your batting average is .400, that is a great percentage; you just want to get yourself more "at bats".

One of the toughest issues is what I call "turf wars". This is the instinctive human (animalistic) thing where we try to decide you is top dog. You can get this whether you have no titles, few titles, or many titles. The team needs leaders (of all sorts) who help the team to minimize this animalistic stuff (caution: never expect to eliminate it). And then develop a more advanced version of managing and leading.

There are other points to make, but we leave them for later posts. One of them is about followership.

Lean-Agile Resources

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

A fourth Google video (Lean-Agile)

Thanks to Artem Marchenko for mentioning the Poppendieck's talk at Google, titled Competing on the basis of Speed.

This also gives me another chance to say that we are delighted that Mary and Tom Poppendieck will be in Charlotte on May 9-10. See here. And they will speak at Agile-Carolinas.

Adopting Agile (Lean Software Development - 4)

Brad Appleton, whom I mentioned in my last short post, also had this post linking to Agile Adoption as reported in the Agile Journal. This issue is talking about top-down agile adoption.

My own view is generally that the workers deliver to the customers, and the managers support the workers. So, in line with that, I think the best agile adoption comes with both bottom-up and top-down support. And both sides have to rigorously and compassionately face the truth and root out impediments.

Now, let me take something from the Poppendiecks, that to me puts agile adoption in perspective. This is step 1 in their 21 step program. (See the end of their new book.)

But having teased you, let me digress for a moment. I have had several conversations over the last few months where people would say something like "...but after all, this is not about agile, this is about getting the work done." And, depending upon the mood and meaning behind what they are saying, I am either nodding in agreement or shaking my head in amazement. If they understand agile and the value is brings, and their point is that agile is mainly about results and not about the perfection of the practices for their own sake, ok. But if they don't appreciate agile, and consider it little more than the flavor of the month, and just really want to go back to the old tired ways of working and delivering, I am discouraged. Agile is valuable because it helps delivers better business results.

After that seeming digression, what was step 1? Step 1 was "implement lean across an entire value stream and a complete product." Thus, before one considers software, one examines what the customers really want, in terms of some complete product or product set (product includes services), and what the full value stream is to deliver that. One uses lean techniques to identify how to improve that value delivery (more exactly what the customer wants, faster, cheaper, better quality).

Presumably improvements in the software will be identified as enablers to a "leaner" value stream. ("Leaner" meaning "better" in the most important ways rather than just the opposite of fat.) Even if the software is the product, bear in mind that creating that software is not the whole value stream. The problem to solve is to deliver to satisfy the need as soon as the need can reasonably be identified. Solving that problem is a lot more involved that just creating software.

If your firm is using Six Sigma or some other Business Process Reengineering approach to delivery, then connect Agile to that. (Exactly how is of course a potentially long discussion.)

Conclusions:
1. Start with a lean attitude toward value delivery to the end customer.
2. Place Agile in the context of helping to deliver business results for the end customer.

(Does my digression now make sense?)

Lean Resources

Brad Appleton had this post with a LOT of Lean resources. I have not reviewed them all. I will endeavor to annotate them later.

Little's Law - Lean Software Development - 3

Again, the Poppendieck's are coming to Charlotte (see here), so this is a continuation of posts on ideas they talk about.

This one is a particular favorite of mine: Little's Law. (No, not me.) This is from John Little, a professor at MIT's Sloan School, and it's in regard to queuing theory.

So, we believe (and in fact long experience has shown) that we should satisfy the customer as quickly as possible. Reduce end-to-end cycle time. Thus, for example, we use value stream mapping in Lean.

So, we have a black box (the business system/process) and we want things to go through that box as quickly as possible. One way of looking at this is queuing theory. Every time you stand in line at a grocery store or a bank or an airport, you are hoping that someone there has studied and implemented queuing theory.

Now, I am not going into queuing theory a lot. Let's just discuss Little's Law. It states something that is actually obvious common sense (and he proved it mathematically): the average time is takes a thing (say, a person) to go through the black box is equal to the number of items in process divided by the average completion rate per item (when the system is running well).

In other words, if there are 10 people in line, and each of two tellers can serve one person every 5 minutes, you can expect the last two people to be "completed" after 25 minutes. And, if people arrive in the queue at 2 per five minutes, you can expect the average completion time for the day to approach 25 minutes for all customers.

So what? How do I use this in my project?

Well, from this we deduce...put fewer things in process. To get stories done quickly, only work on one or two stories at a time. Don't make a big backlog of stories, so that you can release more quickly. If you want your projects completed more quickly, start fewer of them.

These are simple statements, and in practice need some modification (eg, consideration of all the other factors in play).

One of the bigger ones is the cost for people doing task-switching. This is generally far larger than generally recognized (eg, effort and motivation and FUD). These costs for human systems (eg, a SW dev team) urges us even more to put fewer things in process.

There is generally minimal cost associated with implementing Little's Law, except...for the cost of changing the way your colleagues look at work and work-in-process. An important cost, but worth it.

Do we have to use the F-word?

OK. It's a provocative title. I like to talk about two F-words: Feelings and Failure. This post is about failure, and how to use it.

I was working in a firm recently and someone said: "We can't talk about failure around here. That would hurt our careers." Ummm.

First, let me (apparently) change subjects completely. As I mentioned earlier, Mary & Tom Poppendieck are coming to Charlotte May 9-10 to lead their Lean Software Development - Practitioners course. So I want to talk about some of the things they will talk about.

They posit 7 principles of lean software development:

• Eliminate waste
• Build quality in
• Create knowledge
• Use the scientific method
• Standards exist to be challenged and improved
• Predictable performance is driven by feedback
  
• Defer commitment
• Deliver fast
• Respect people
• Optimize the whole

As with all good ideas, most of these are obviously good at first glance. What is apparently (from what I see in real life) not so obvious is the full meaning and application of these principles. Which the Poppendiecks explain.

You will notice that I gave detail for only one: Create knowledge. (The others have more detail, not shown; perhaps subjects for another day.)

So, let's talk about the scientific method. "But wait, weren't you going to talk about failure?" Ah, I am talking about failure. Imagine the many failures of the Wright Brothers (two of my favorites) or Alexander Graham Bell. Only after a couple of years of failure did we hear: "Mr Watson—Come here—I want to see you". And the telephone was born.

The Poppendiecks explain the scientific method this way: "Teach teams to establish hypotheses, conduct many rapid experiments, create concise documentation, and implement the best alternative."

When we are creating something new (with software we always are), we need to fail, fail, fail, succeed. This is embedded in the Red, Green, Refactor of test driven development. This is what all inventors do. (Now you can call yourself an inventor. Really.)

Now, using failure to learn and make progress and discover is not an excuse to use failure to hide shoddy work or laziness. (Very few workers really want to do shoddy work or be lazy, but a few of us have that kind of motivation from time to time. Examining why is perhaps a subject for another post.)

So, if your firm or the people around you don't want to hear the F-word, tell them your team is using the scientific method. You are testing hypotheses to identify the best one. Only by failing can we succeed. (Another paradox resolved.)

Good luck with your project.

Waste in projects...Working hard is not enough.

The second big idea in Lean is waste. Or getting rid of waste (muda in Japanese). Seems obvious. Everyone in favor of waste, raise their hands....umm, no one.

First: Why do I want to talk about this? Many reasons; one today. I meet so many development team members who are so gung-ho, they want to impress everyone with how hard they are working. Working hard is nice, and a demonstration of good character. Up to a point. But working hard, by itself, can be wasteful. (Other issues with working hard...in another blog entry.)

[Note: My apologies to people experienced with Lean. I feel it is necessary to go over these basics first. If you wish to comment, with a more advanced insight, please do. Please be patient.]

There are many types of waste (to be discussed later). Let's start with time as an example. In simple terms, (and it really means more than this implies) let's look at waste being every extra second it takes from the time we start working on the product until the end customer gets satisfaction. Think of it first as "I'm an impatient customer, and I want to be satisfied now." Lean attacks the time delay with a value stream map...and actions arising from that.

This is what Womack and Jones say:

Identify all the steps in the value stream for each product family, eliminating every step and every action and every practice that does not create value.

The value stream is the set of all the specific actions required to bring a specific product through the critical management tasks of any business: the problem-solving task running from concept through detailed design and engineering to production launch, the information management task running from order-taking through detailed scheduling to delivery, and the physical transformation task proceeding from raw materials to a finished product in the hands of the customer. Identifying the entire value stream for each product is the next step in lean thinking, a step which firms have rarely attempted but which almost always exposes enormous, indeed staggering, amounts of waste.

"Wait a minute", you say, "how can I, smart as I am, be doing anything that does not add value?"

First, any time things are standing idle, it is waste.

Second, value is defined in the eye of the customer. So, of course you are always doing stuff that you or someone thinks is very very very important. But does the customer see it as adding value to him (or her)?

In Lean there are two types of waste: Type I muda is waste that is (currently) unavoidable. Government reporting might be an example of this. You don't want to go to jail, so although it adds no value to the customer, you do the government report.

Type II muda is avoidable waste. Like wait time.

Note that muda is an ugly word (in Japanese). Lean uses it for that very reason. Waste is ugly.

Once most of the Type II muda has been eliminated step-by-step, then you go back and re-evaluate Type I muda. Isn't some of that now avoidable? Can't we talk to the government, etc?

We will also suggest that many things that once seemed important and useful are, under a careful eye, things that can be done with less effort or in a simpler way, thus avoiding much waste.

Using these ideas, we can use Pareto's 80/20 rule, and ask: "Are we focused on the 20% of effort that will produce the 80% of value?" "Should we really be doing any or much of that 80% of things that only produces 20% of the value?"

Thinking about and talking about waste in this way typically raises many questions...we will start to talk about those in a few more posts. Comment below with your questions.

Next, we want to talk about another way to look at the types of waste. See the Poppendiecks for a preview. See the list of 7 types of waste on page 3 of this linked article.

** Joe Little

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

What is Business Value? Part 1

I have noticed a bunch of projects lately (mine and those of other people) where the business value is not so clear.

As Yogi Berra said, "If you don't know where you're going, you might not get there."

But what is Business Value? I mean, what is it really?

First, I like the definition of Lean. Value is defined by the end customer. Value becomes meaningful when talking about a specific product that meets a customer’s needs at a specific price at a specific time. (See here: http://www.lean.org/WhatsLean/Principles.cfm#specify)

End customer. So, all the rest of us are just making guesses at what the customer wants. Remarkably, sometimes we are right. And the next sentence is also important. There has to be a context. In fact, I believe the context is much larger and harder to define than this. We buy things based on a conscious or unconscious comparison to all the other things we might buy or do or not do.

For example, when I go to Starbucks for a decaf coffee (don't ask; no, I hardly ever buy a latte), I am implicitly comparing to all the other cool things I could do, places with social scenes, drinks I might have, other bars or coffee houses I have gone to lately.

My main point is business value is complex. And it changes. The customers are changing and my understanding of the customers is hopefully improving along the way. Indeed, I should organize things so that I can experiment with new products, to find out if my hypotheses about the customers were correct. (Yes, Virginia, even end customers can't always explain to you what they really want. Accurately.)

So, with agile project management, we are learning about what the project is and how to do the project and who the team really is. At that same time, the business lead is learning "what really is the business value here".

"As you from crimes would pardon’d be,
Let your indulgence set me free"
- Shakespeare, The Tempest

The business lead must accept the Team is learning, and they must accept that the business lead is learning.

Now, the fact that we are learning does not mean we start with totally sloppy thinking or no thinking. We need to make a relatively quick first estimate (hey, it might even be accurate enough). And then test that. I would not suggest starting a project just on the hunch of a "business lead" who has no track record of successful hunches.

A couple of suggestions:

• Demand to understand the business value of your project (be reasonable in how you put this)
  
• Talk about it (anyone might have a contribution)
  
• Talk about it some more; see if everyone is motivated by the business value as articulated so far
  
• Develop an approach together to getting more confirmation that the business value of your project is really there (Hint: incremental releases might be part of that approach.)
  

We have some more things to say about business value, and then we will talk about the relationship between a SW project and a process.

+ Joe Little