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.

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.

Lean Software Development - 1

Mary & Tom Poppendieck will be visiting Charlotte to give their Lean Software Development - Practitioner's course on May 9-10. [Written in 2007]

Partly because of that and because of an inquiry, I wanted to talk some about Lean. Specifically, about waste, which is known as muda in Japanese.

Earlier I posted about waste. This is a different perspective on the same basic subject.

Those who know Lean manufacturing know that Shigeo Shingo defined the Seven Wastes for manufacturing (derived from his work at Toyota).  (Well, some say Taiichi Ohno identified the 7 wastes. Oh well.)  The Poppendiecks have defined the Seven Wastes of software development. See below.

Manufacturing	Software Development
In-Process Inventory	Partially Done Work
Over-Production	Extra Features
Extra Processing	Relearning
Transportation	Handoffs
Motion	Task Switching
Waiting	Delays
Defects	Defects

Some of them are obvious. Some maybe not.

Let’s pick on the first row. What is Partially Done Work?

The Poppendiecks identify several examples:

• Uncoded documentation
• Unsynchronized code
• Untested code
• Undocumented code (if documentation will be needed; usually some will be needed in my experience)
• Undeployed code

In fact, any work done prior to receiving the business benefits of the deployed software is “partially done work”.

Why is this waste? After all, from an accounting point of view, this is “inventory”, which is an asset. Right? (And so thought the auto industry for the longest time.)

But, what good can happen with or to partially done work? (My answer: almost nothing.)

And what bad can happen to partially done work? Lots. Every minute it is undeployed is a minute the customer is left unsatisfied. And with time, la donna e mobile (see lyrics), and so the customer’s needs also change. Ever happen to you? I would bet it has.

We lose our knowledge and understanding of that unfinished work. (What's the half-life of our memory of a Requirements Doc, when we have worked on two more in the meantime?) People lose it, it gets harmed. We have to do Task Switching to come back to it.

Further, thousands of dollars have been invested in that unfinished work, which often can’t even be shown to the customer. The firm has to fund that investment, and the customer loses confidence that the development team can produce anything worthwhile. And the development team is unsure…how near finished is it, really? You have a guess, but nothing beats getting the ball over the goal line (oops, football metaphor, wrong season).

“But, but, but”, you complain, “I must have some partially done work.” Yes, indeed the team must. So, the goal is to limit that waste to the smallest amount possible. Example that might fit your situation: Only one story in-flight at a time.

More on waste later.

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