Little's Second Law: "People are remarkably good at doing..."

Little's Law is justly famous. I highly advise that your firm think about it, and use it as a justification for reducing the number of projects "in the system". And for having team members only work on one project. There are other reasons to do this, but Little's Law is enough.

Now I want to invent Little's Second Law. (This time it is a different Mr. Little, your humble blogster.)

It is: "People are remarkably good at doing what they want to do."

This is a law of human nature. Linked to the top value of Agile (in my opinion): Humanity or People. And linked to one of my favorite documents, The Declaration of Independence.

"We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness."

Since we are free, we do what we want. We can be advised or commanded, but we will ultimately do what we want (and this is probably a good thing, especially if you want us to do it well at all).

In one sense, it is another way of saying "where there's a will, there's a way."

The law also directly implies that people are remarkably good at not doing what they don't want to do.

To me, the law suggests to managers and those on teams who would lead, that they convince and influence people to understand why they want to do something. You are not changing motivation, you are revealing motivation.

To me, it implies one should work with good people who generally will want to do the right thing, once they see and understand it. If you work in alignment with the energy of this law, success can come easily. If you work against this law, success can be difficult.

In my opinion, Lean-Agile has this law embedded in many of its practices. For example, it reminds me of one of the Poppendiecks' 7 principles: Respect People.

A few comments about what this law does not say or imply (in my opinion).

This law does not imply that people will always want the right things. This law does not imply that people will always have the courage to do the right thing. The law does not imply that people will never be lazy.

Origin: I am fond of quotes, as some of you will have guessed by now. This phrase came to me one day, as I was thinking of some quotes. In fact, I thought it was a quote for a moment. And I remember thinking: "This is a bit mushy to be a quote. Really it is kind of obvious." And certainly it was to me. But the phrase would not leave me. I used it in several teaching and coaching situations, and it struck me as an obvious truth, a truth that some managers seem to want to avoid. (I suppose many of them want to live in the fantasy that they can control other people. To the degree this might really be true, this is slavery, a most abhorrent thing.) And it is a truth that many of us, including myself, do not recognize and work in accordance with often enough.

By and by, it struck me that this phrase, which just came to me, was important enough to call a law. Surely it is not without meaning that "it just came to me". So I call it Little's Second Law rather modestly, and somewhat jokingly. And in deference to Little's Law, which also needs more recognition.

How to measure success on agile projects from a customer point of view

This topic is a thread on Scrum-Dev (the yahoo list). Excellent topic. With many good posters. Go and see.

This is an involved topic, so I will give some views in this post, and more views later.

I start with the word "measure". Because I am concerned that we are measuring too many things (not good), and the wrong things (even worse). Many people don't take to being measured like a thing. (People have lots of characteristics and variability, but being a "thing" is something they are especially not good at, or so I have found.)

So, what to do if one wants a simple measure?

The simplest "measure" would be to ask the Product Owner on the team..."is this team effective and are you guys producing business value?"

This is one measure. It might even be binary (yes or no). And it is low cost to collect, except that the Product Owner might give you (let's say for now that you are a senior manager) more of the truth than you want. And ask you to assist in making things better (and things can always be better). (As an aside, if the Product Owner were really good, I might accept a yes/no answer. From a less strong Product Owner, I would always want a longer answer, probably with follow-on questions.) And it might be a conversation that is forward-looking and action-oriented.

The next problem becomes "what is business value really"? To me this is the key direction to take this question (finding a simple measure). (There are other directions we must also take, but for later.)

Let me emphasize this: efforts (projects) are successful to the degree that they deliver business value. There are no technical successes ("we did what we were asked to do", "we're within scope and budget", "it's a beautiful system", etc, etc). There is only delivery of business value...at least somewhere along the chain of value to the ultimate customers.

Therefore: "what is business value really?" There are many views on what business value is. We have discussed some in earlier posts.

Lean says that value is defined by the customer in the context of a specific product (service) at a specific time. That says, among other things, that customers are redefining value all the time. If you take your own personal experience, you know that your "values" (at least in the
material world) are changing all the time. Your own wants and needs change, with great rapidity sometimes.

OK, so what do we do about this in Scrum? Well, Scrum does not prescribe any specific method. (That's a good thing, because there are so many situations.)

What I often suggest is this...and it seems to fit many situations well. Let's assume you can determine a dollar amount representing the business value of a release or for the whole project. Then, assign 1,000 (or 10,000) "gummi bears" to all the existing user stories (or the equivalent if your Product Backlog is not in stories). Perhaps reserve some gummi bears for stories yet to be discovered. You might put those BV gummi bear numbers on one corner of each Story Card. (I do not call these BV numbers "Story Points" because too many people understand that term to mean points of size/effort, which is different.)

Then, as each iteration is completed, count the gummi bears "done". Say 100 are done after the first iteration and the total is 10,000. And say that the total business value is $26 million. 100 divided by 10,000 says you have completed 1% of the business value. Or $260,000 in business value (if I did the math right).

It's a good enough approximation for most situations.

The next problem is if total business value changes during the project. Which it always does to some degree. And new business value is discovered (if anyone is paying attention). Usually.

Is that a simple enough answer?

Of course there is much more to say on this topic. I particularly recommend Software by Numbers by Denne and Cleland-Huang.

"Things should be as simple as possible, and not simpler." I think Einstein said that.

Let me deal with one more issue (in this post) that I have often seen. The issue: the Product Owner is not always "good enough". This is always a risk. But, in a way, unavoidable. Someone must be the proxy for our customer set, trying to determine the overall business value of the product (or our change to the product). Scrum prefers, to avoid long delays in making decisions, to name only one Product Owner. Who serves as that customer proxy (in the context I mentioned). Of course, one or more people (perhaps on the team, perhaps not) might still assist that Product Owner in determining the business value.

Just as the one Product Owner can fail, so also can any group of people fail. Scrum has no silver bullet to eliminate failure by people. What it does do is make clear and visible where the (relative) failures are. Often that can allow corrections to be made.

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.

Acceptable Interrupts - Toward a better Daily Scrum

As many of you know, Scrum has a Daily Scrum or stand-up, where the team syncs up quickly (in 15 minutes). For some reason (or perhaps a variety of reasons), many teams either don't get the value or take too long. Or both.

So, to make your Daily Scrum better, consider a couple of questions.

1. What is the purpose of the Daily Scrum or stand-up?

It is typically not to solve world hunger. Nor to discuss vacation plans. A reasonable purpose might be "to discuss those things essential to helping the team finish a successful sprint or iteration". Agree on the purpose within the team.

2. How big is the team?

Lots of info suggests the team size should be 7 plus minus 2. Maybe your team needs to break into 2 teams. Figure it out.

3. How do we keep it shorter?

The whole team can't concentrate for a long time. Maybe 15 minutes. So we try to say the essential stuff (using a timebox and the 80-20 rule) in 15 minutes. Yes, 15 minutes.

The team might actually all pay attention for that long.

It is a Daily Scrum, right?

4. How do we keep it to 15 minutes?

One suggestion: Fewer interruptions. And only short ones. When a person is answering the 3 questions for himself or herself, we need to interrupt them less (usually).

5. What are acceptable interruptions?

Make a team norm about this. My proposal is this...

a. None? (Probably good to suggest, but not easy to do. A few interrupts are actually useful.)

b. "I did not hear or understand what you said..."

c. "Let's talk about X right after this huddle?"

d. "Can I help you? Do you need help with that?"

e. "Is X an impediment?"

f. If the person did not give a full update...

- "yesterday?"
- "today?"
- "impediments?"

g. No interrupt (including reply) is longer than 10 seconds.


6. Do you start on time?

Don't waste the whole team's time for one person's delay. If you delay, you are telling the late person it is ok for him or her to be late. Always start on time.

7. Talk to the Sprint Backlog board and cards, or something that represents the whole iteration's worth of work.

This can take many forms. Have easy reference numbers so everyone can follow along. Point to things (cards) in the room while speaking (people are engaged more if you use visuals like moving your body to point to a card).

8. Call the Daily Scrum "done" and let most people get back to "real work". (Yes, Virginia, the Daily Scrum is also real work. And it takes effort.)

9. Who are the attendees?

Of course you want the pigs (those people who are committed to delivering on that sprint's work). And of course that includes the Product Owner (the key person representing the business side).

One common problem is "talking chickens" during the Daily Scrum. We sometimes do want to hear from them (the "only involved" can still be very valuable), but let's talk with them after the stand-up. One related problem is that chickens often don't attend the Daily Scrum often enough to know the Team Norms about how the Daily Scrum will work. So explain a little and let them talk after the Daily Scrum (when many team members will have had a chance to escape ).

Good luck with better huddles. And tell us your ideas.

Some video resources

Lachlan Heasman posted a comment to another post, reminding me of some great video resources. For now, I'll just mention the two he reminded me of. There are earlier posts with other videos.

1. Ken Schwaber talking about Scrum at Google (about 1 hour). As I commented to Ken, good for lots of companies to know that Google is using Scrum. Might make them question that (current) waterfall ways. See here.

2. The Scrum Masters (second joint production): The Dysfunctional Daily Scrum (aka stand-up). These are some great coaches (and proud to call them friends, as well) having fun pretending to do a daily scrum the wrong way. See the video here.

How to learn more about Lean-Agile

Several people who have taken recent courses have asked "where do we find a discussion group where we can learn more about agile?"

Here are some answers.

First, find local people.

Agile Alliance has a list of agile groups. And the Scrum community has identified some local groups (often the same ones) here. In fact, the Scrum community has identified its community more broadly and specifically, here.

What are other ways to learn? Certainly there are many books. Here is a list, although not complete.

There are discussion groups, especially on Yahoo. Here are my top four:

scrumdevelopment
extremeprogramming
agileprojectmanagement
leandevelopment

There are other very good ones.

And there are some good blogs as well. Carnival of the Agilists highlights better blog posts. And the Scrum community has listed a lot of great blogs. And don't forget the blogs in the Blog Roll to the right (some repetition in these lists).

That should get you more than started.

Lean-Agile Courses Available

Certified ScrumMaster course. Winston-Salem, NC. Jan 16-17, 2008

Leader: Mike Vizdos. See: Vizdos CSM Course

Implementing Lean Software Development - Practitioner's course. Charlotte, NC. Jan 28-29, 2008

Leaders: Mary & Tom Poppendieck. See: Lean Software Development course

Certified ScrumMaster course. New York, NY. Feb 28-29, 2008.

Leader: Jeff Sutherland. See: Jeff Sutherland Certified ScrumMaster training

Suggested Resources for attendees at the Jim York Certified ScrumMaster course on Dec 4-5

Here are some suggested resources that came out of a Certified ScrumMaster course that Jim York and I just led.

Books

On the Web

http://www.mountaingoatsoftware.com/
http://www.planningpoker.com/

http://groups.yahoo.com/group/scrumdevelopment/ -- The Scrum-Dev yahoo discussion group. Enter with salt.

Articles

New New Product Development Game by Takeuchi and Nonaka. (See http://www.hbr.com/) This is the article that directly led to Scrum (along with other sources). It also gave Scrum its name.


Key Words

Kaikaku - a rapid or radical change event (such as the initial implementation of Scrum)

Kaizen - continuous improvement (also used to refer to continuous improvement actions)

"Go to the Gemba" - Gemba in Japanese means "actual place" or the place where truth is. Similarities to the Godfather phrase "Go to the mattresses". With "go to the Gemba" we are typically asking a manager to go visit the Agile Team Room.

Genchi Genbutsu - Japanese for "Go and see for yourself". More roughly translated as "don't manage from behind a desk". In Agile, we might say, "Come to the demo and see for yourself" to a stakeholder. Or, to a manager "if you want to really know how the project is going, come to the Daily Standup or come to an Iteration Review." Closely related to "go to the Gemba" and Gemba Attitude. See http://en.wikipedia.org/wiki/Genchi_Genbutsu
The ScrumMaster role:
"...whose end, both at the first and now, was and is, to hold as 'twere the
mirror up to nature: to show virtue her feature, scorn her own
image, and the very age and body of the time his form and
pressure." Hamlet. (That's a lot of what a ScrumMaster does.)

Pictures
Communications Nodes PDF. See http://agileconsortium.pbwiki.com/Presentations
The idea here is to show why we need small teams.
See also earlier posts tagged Recommended Reading.
* * *

The Nokia Test

Nokia (the cell phone maker) uses Scrum.  Well, actually it is/was a small Euro 50 billion joint venture, called Nokia Siemens Networks.  They have developed a test to check whether a team is really using Scrum or just doing what I call Cowboy Agile (see wikipedia on cowboy coding). Or doing Agilefall (talking Agile terms, but really doing mostly waterfall).

The Nokia Test is in two parts.

First, are you doing Iterative Development?

• Iterations must be timeboxed to less than 4 weeks
• Software features must be tested and working at the end of each iteration
• The Iteration must start before specification is complete

The experience is that if you ask a lot of "Scrum" teams if they can pass this part of the test, they can't. If you are at a conference, often not a single team in the room.

The next part of the test checks whether you are doing Scrum (in Nokia's opinion):

• •You know who the product owner is
• •There is a product backlog prioritized by business value
• •The product backlog has estimates created by the team
• •The team generates burndown charts and knows their velocity
• •There are no project managers (or anyone else) disrupting the work of the team

My reaction:
I think this is an excellent way to deal with Cowboy Agile or Agilefall.

Let me say this loud and clear: a firm can't in good faith say "we tried Scrum" and then move away from it if they never had any teams that could pass the Nokia test. And pass for a reasonable period of time. Of course they could say "we tried Scrum", but they did not. (I will not define right now what 'pass' would require.)

The Nokia Test is demanding. That is clear. But a test of this nature is a necessary (if not sufficient) condition to doing professional agile software development. (Or did we expect to get out of Fred Brooks' tar pit by doing unprofessional software development?)

There are some forces in a firm that want to do Cowboy Agile or Agilefall or want Agile to fail ("it's moving my cheese"). This is true in every firm that I have worked in, I believe. So, if you use the Nokia Test, expect to get some resistance.

The Nokia Test is arguably too minimal. There are many other important parts of Agile or Scrum that it does not cover. Are the things in the test the most important parts? My thought is that this collection of principles and practices provides a good core of Agile/Scrum that will defend you from the most common dysfunctions. Not all. Is there a better test? Probably we could define one, but let's pass the Nokia Test now.

Should the test be significantly more detailed? I think not. First, to work with any test, we need the test to be simple enough to be comprehended easily by most of the people involved. In this way, it becomes self-policing. Second, Agile/Scrum needs to be adaptive, so having a lengthy test that puts all teams in the same straight-jacket would noticeably limit that adaptability.

What are your thoughts? Are you aware of similar tests? How does your firm limit Cowboy Agile?

Carnival of the Agilists - 11/29

Once again we are pleased and humbled to be included within the Carnival of the Agilists collection of blog posts. See here: http://trailridgeconsulting.com/blog/?p=104

For all the prior Carnival of the Agilists selections, see here: http://www.agilealliance.org/show/1670

Enjoy. These are recommended.

This is not to say that I would agree with every word of every post, but "two heads are better than one" is an key idea in Agile. The team is wiser than any one individual. (Yes, I know there are exceptions, and a good team knows when to follow the leader.)

"You can observe a lot by just watching"

As some of you may know, I am a fan of Yogi Berra quotes. The guy is amazingly stupid-smart. And, since he was a coach, I can relate.

One of his quotes is: You can observe a lot by just watching.

Why is this relevant to Agile?

Well, it seems obvious to me. But it seems it needs to be explained, and I need reminding too.

Let me start by stating my hypothesis, that everything we do in working as a team is imperfect, everything can be improved. My related hypothesis is that people and their interactions are complex. And another related hypothesis is that only by sharing tacit knowledge can the team create new knowledge and become truly successful in creating a new product for its set of customers (a new piece of software for example).

So the ScrumMaster watches the team to see what is really going on. How the productivity is working. And he evaluates...what are the top impediments and what can we do about them.

These impediments can be anything. Any thing. People, technology, external intrusions, light/heat, attitude, process, whatever. So the ScrumMaster evaluates what is important enough to be worth taking action on.

Thus, as I am trying to explain, the ScrumMaster needs time to observe the team (and things around the team). Time to smoke out what is noise and what is real. Time to let the introverts speak with their actions. What are the usual complaints about "work" or "life" (we all always have these), and what are the top one or two impediments that, if changed or improved on, will give the team greater velocity.

It's not hard if you relax and concentrate. (The paradox that martial arts and most sports and, indeed, life itself always bring us back to. Mastery with some time.)

Top Enterprise Impediments - Part 2

This post is a continuation of the previous post on Top Enterprise Impediments. Here we add 3 more impediments.

No or minimal Business commitment

This problem recurs and recurs. It derives in part from the Business people viewing Lean-Agile as a Technology initiative. It also derives from the Business people believing in magic. Not understanding what Technologists really do, they “give up” and just hand off stuff to Technology to “just go do it”.

First, we need to recognize that the Business side is unlikely to commit to something unless someone asks them to, and points out the value of committing. Like everyone, they are busy and they need to be convinced that the Lean-Agile initiative needs to be on their plate.

The problem also derives from the Business people having a lack of focus, or being driven by their managers from one thing to another, so that they must lack focus. Example: One business person is not able to be a consistent Product Owner to a small team due to his manager’s lack of focus.

The Business people who really understand, who understand the problem the team needs to address and the real needs of the customers, are extraordinarily valuable. If the value of them playing with the Technology team members is not continually made visible, they or their managers will often forget. (I am reminded of the Dylan song "What was it you wanted?", covered by Willie Nelson.)

And, based solely on experience, we know that teams with active business side Product Owners, who are participating roughly half of each day with the Team, these teams are the most successful, and are most productive in producing business value quickly. This is not just my personal experience, but the experience of many many people using Lean-Agile in many firms and situations.

Lack of appreciation of the change effort

Many managers seem to think that once something is “decided” it naturally sticks and happens. But the facts are that Lean-Agile is a major mind shift for everyone, and particularly for some people. These people think they get it, but they do not, and every other word betrays that they do not, even as they say that they do.

Lean-Agile is also a big change for the culture of all firms that I have worked with (and this is confirmed in discussions with all the coaches I meet). Each culture wants to revert to some “natural” state, and that state is not Lean-Agile. I will guess at the main cause: Lean-Agile is just a little bit too transparent for comfort. There are other causes as well.

Moving the waterfall mindset and replacing it are extremely difficult. Many key tenets of waterfall thinking are deeply embedded in all of us, and, as with smoking, those old habits do not go away just because we “decided” to stop. Toyota has gotten good acceptance of Lean after decades of work in changing its culture. And that work continues.

So changing people’s core habits is an enormous struggle. What is delightful is that even a minimal change (and the use of some core practices) almost immediately enables most teams to be more effective than they were before. How remarkable!

Perhaps more to the point, every culture will contain people who will seriously resist the change. They will nod their heads, but subconsciously or even consciously, they will resist. There are many reasons for this and many types of games that are played. This is normal, expectable, and in some ways not to be blamed. Arguably the struggle at the level of the middle managers’ (between the advocates and the resisters) is the key “event” that will determine whether an enterprise will really “go” Lean-Agile or not.

No or minimal embedded culture for managing impediments incrementally

All firms have some de facto approach to dealing with problems. While some of the approaches may not be official or even very effective, some problems must at least be addressed. So, in some sense, every firm has some kind of impediments management approach.

Lean-Agile asks the firm to go to a higher level. First, it asks the firm to focus on improving the fast delivery of business value, and specifically the velocity of its Lean-Agile teams. Anything that is slowing that stuff down is an impediment. Anything!

So, Lean-Agile demands a relentless honesty about all of our problems. In fact, our biggest problems. Some managers want to blame people as soon as they hear of a problem, so you immediately see that this does not breed a good impediment management culture. ("My system is perfect, but it's those darn workers who aren't doing it right.")

Beyond the identification of impediments (typically by the Lean-Agile teams), managers (and the culture) need to learn more rigorous ways of prioritizing and taking action on the impediments. This is often a significant shift.

And not an easy one. Impediments come in all shapes and sizes. People issues, compensation issues, training issues, Corporate Real Estate issues, Build issues, Testing issues, etc, etc. Some of these require significant investment. An investment that is only justified if the problem is big enough, which might be proved, for example, if many teams are experiencing the same problem. Getting the visibility into how many teams are affected by a given problem often requires a culture shift in the way impediments are handled.

Another part of the culture shift is the approach of continuous improvement. Many firms start with an attitude of “I want to fix it once and for all”. Classic waterfall thinking. So they do not take the opportunity to fix an impediment partially, and then look and see if it remains the biggest impediment after the smaller, quicker fix.

* * *

If we only had these 6 impediments fixed, Lean-Agile adoption might be easy sailing. But, easy or hard, it's worth the effort.

Some Top Enterprise Impediments

I have had several conversations on this topic lately, so I thought I would post some thoughts. Actually, this will take several posts. (And one could argue that many earlier posts are also about this topic.)

My aim in the comments below is to identify and describe the main impediments that are most typical in a large enterprise. Occasionally I will speculate or comment on the source of the problem in my experience. While the descriptions may suggest ways of addressing these impediments, proposing a full course of action is not a goal here. First one must identify the real problem.

Word of caution: These may not be your top impediments. The way I look at it, nothing is perfect and everything is an impediment to some degree. But you need to identify your top impediments today...so you can improve them now. So, use the comments below with caution.

Top Management

Top Management itself can be the top impediment. What do we mean by this? Several things. First, top management may in effect oppose the change. Ex: Proclamations that imply a waterfall approach to work.

Does top management clearly support the change? This may be at least a point of confusion to middle managers and performers. In most firms, some people have more courage if they know they are doing things that are generally in the flow of top management’s direction. Ex: Statements that repeatedly mention the core benefits of Lean-Agile will enable greater courage.

Next, does Top Management really understand the change? Well? Surprisingly perhaps, the first two points do not require that top management really understand Lean-Agile well at all. This point means they understand it, they ideally have executed some work using the core methods. And therefore they have a chance of accurately coaching wayward participants in the new approaches.

There are other related issues addressed later.

Command & Control Culture

It continues to surprise me that “management” does not understand that Lean-Agile does not take a “command & control” view of people. To me, the choice is very simple: are people free or are they slaves? If they are free, then one must lead them, pull them, respect them. And not push them, boss them, and micro-manage them. If they should be slaves, then clearly workers need to be bossed and micro-managed.

Often, whether Top Management is aware or not, “management” (I am thinking of middle managers here) are using a command and control culture to run the shop to a large degree. And these power dynamics can cripple the Lean-Agile adoption.

Now, I do not mean to propose a full laissez-faire view of people. “They are good and I don’t need to manage them at all.” To me, this also is a silly notion. One must be adult and realistic. We lead, we ask, and we pull. But occasionally we must decide a person is not making it. Occasionally we must keep asking questions about why work is not done. (There can be lots of reasons, and a small share of them are about the person, not just “the system”, as Deming has said.)

Culture and attitudes of thinking take time to move and change. Top Management, who is always ultimately responsible for a successful change, must expect these movements to take time. This particularly applies to a Command-and-Control culture; this will not change (and stay changed) based on one top management declaration. (Yes, "I command that a command-and-control culture end immediately" does seem almost laughable.)

Lean-Agile viewed as a Technology initiative

Lean-Agile is really not about delivering software. There are no “technical successes”. Business Value is delivered or not. The customer’s problem is solved (or partially solved) or it is not.

So, every time someone thinks of Lean-Agile as a Technology initiative, that is an impediment to their proper thinking. And their proper execution. This manifests itself in many ways.

Delivering business value of course requires daily interaction between Business and Technology people. If Business people hear that Lean-Agile is a Technology initiative, they immediately assume that their role in it is minor.

Perhaps more to the point, solving problems requires the creation of knowledge in some combination of business and technology domains. So, almost by definition, half of the problems in creating this knowledge have to do with the business side. If the Business people do not own Lean-Agile as a means to solving business problems, then many of the most meaningful productivity increases are unlikely to occur.

In any case, Lean-Agile is trying to help solve the Business problem of how to deliver more business value. So, by definition, it should be a Business initiative.

More impediments to follow. Your comments on these are welcome.

lean

Jim York will lead a CSM course in Charlotte on Dec 4-5. See here for details:
http://wiki.kittyhawkconsulting.com/Jim+York+CSM+Course+in+Charlotte

Or contact me.

Reading List for CSM Course Nov 5-6

The following are some suggested readings for people in this course. Others may enjoy also.

Again, as always, I recommend that you learn as fast as you can. And that you mix learning with action. To know and not to do is not to know. Thus, your real knowledge becomes known in how well you can act. Then you see your...opportunities for improvement, and are ready to learn some more, and then to act again. So, read what you will learn from and what you need to learn now. These needs will differ for each person.

For some of these books and more, see http://www.kittyhawkconsulting.com/id15.html In this case, I have made the entries graphical, which some may enjoy. Click on an entry, and you will go to Amazon.com, where you can read more about the book.





And three articles:
The New New Product Development Game by Taeuchi and Nonaka. Where the Scrum name came from.

The Knowledge-Creating Company by Nonaka. This article is a very short version of their book of the same name.

The Concept of Ba by Nonaka and Konno. In Scrum, the team room is the "Ba" (the place or context in which knowledge is created). So, this will help you understand what kinds of things should be going on in the Team Room or other Ba's.

See also this earlier post titled Prioritized Reading List.

Scrum and Agile are simple. At the same time, all the different reasons you follow these Scrum practices are many. And people are...involved. So, there is always more to learn.

Carnival of the Agilistas - 10/30

We are pleased to modestly report that our blog has been included again in the Carnival of the Agilists, this time the 10/30 edition. See here: http://www.notesfromatooluser.com/2007/10/carnival-of-the.html

This listing of "the best Agile blog posts" is quite interesting. See here for the fuller listing:
http://www.agilealliance.org/show/1670

Enjoy!

The Agile Recipe; on second thought...Not

I have been asked recently to provide a recipe for how to do Agile. I am sympathetic with this request, but I feel it misses an important point.

First, why am I sympathetic. Well, because I look at Agile as an art form, like playing the violin or learning Hapkido (Korean version of Aikido). It is an art that one continually learns. And, at the beginning one feels lost. How do I learn this thing that seems so strange? How do I start to make un-ugly noises from the violin? And the teacher must give you instructions of some sort, and you start to play. Perhaps ugly at first, but you start to play. And then you start to be…as a friend pur it recently, you start to suck less.

Of course, Agile is more like a team sport than playing a violin. But it is still an art. Where one starts with little skill and builds and builds. Agile is like the "ballet with force" that is basketball.

OK, So how do you learn to play basketball?. Well, start by dribbling. (Which one can break down.) Learn to do a layup. (Which one can break down.) But the real thing about basketball is not the individual skills. The real juice is learning how to play as a team. To improvise on the court. To maintain your confidence if the other team dunks on you twice in a row.

In basketball, there are a few set plays that one can diagram. With perhaps many variations. One cannot just follow a recipe in playing championship basketball.

This is where giving the recipe can mislead. By giving a recipe the coach can suggest to the beginner “all you have to do is follow the recipe and all will be well”. Maybe with an ordinary dish, but not if you want a meal that dazzles. And don’t you aspire to produce something that delightful?

If you have studied an art, you know that great artists will tell you that being really good requires a certain something that is hard to define. In Agile, we often say that you must "get it". You must start to reflect, in your every thought and decision, Agile values and principles. And without these values and principles, just following the cookbook or the recipe will make only a small improvement.

Leadership: Getting us there

A few thoughts after reading this: http://lwok.org/index.php?title=Main_Page

We always need leadership to help us through the many hard patches, and on to ultimate success.

It is hard to say what is the main thing that leads to success, and one supposes that the most essential element varies by situation. Some important elements are...
* passion for the vision
* perseverance
* courage
* helping others overcome their roadblocks
* assuring that most of the team is winning and that few things lead to tradeoffs where one person is hurt

We also mention the creation of Ba (Japanese), which represents that context or place in which new knowledge is created. Only by creating knowledge can the seeming constraints be transcended, and success becomes possible.

Many people possess one or more of these skills. It is not having the skill or skills, it is bringing it all to fruition so that the Team reaches the goal.

Still, there remains that element of magic, where somehow some make it up the river and others do not. Here's to those magic ones, who make it up the river more often than not.

Knowing where to go

To me, the essence of leadership boils down to two things.

1. Knowing what needs to be done.

The ability to identify and articulate what needs to be done is enormously useful.

In most business situations, it means understanding the customer. It means focus on a few relatively important things. It means explaining this to other people in a persuasive way.

There are, of course, a whole bunch of skills related to understanding the customer. Understanding the customer is so very difficult, perhaps partially because it is an act of selection and editing (not everything that a customer might want, but those few essential things). Knowing what needs to be done can, for example, be claimed to be partially a financial understanding (ROI and NPV), but I think not mainly in most cases.

A listing of skills is not essential. Decomposing "what a leader does" into parts misleads as much as it helps. It is how the cake is put together and how it bakes as much as any list of ingredients. And finally it is in the eating only that its true meaning is fulfilled.

Once one has a vision, it is necessary to communicate this to others. So that they are inspired and encouraged. So that they act. Knowing is not enough; acting in such a way that the Team gets started is part of setting the initial direction. Imagine Moses setting off.

2. Getting us there

This is discussed in the next blg post.

This line of thoughts was opened up upon seeing this site:
http://lwok.org/index.php?title=Main_Page

Only solutions deliverers

As I was saying earlier, in all my clients there is this divide between Business and Technology. "I'm a business guy, not a technology guy." "Oh, I work in IT; go ask the business folks that."

This is an unhelpful distinction.

The customer does not want business or technology or even a product. The customer just wants a solution to his problem. Now.

So we all are just solutions deliverers.

And it becomes clearer each day that our job is to work together in teams, to create the knowledge needed for the next solution. To create the metaphor of what the problem really is; to envision how it might feel to have it solved. To brainstorm, to see the whole problem, to imagine how alternate solutions might fit, to transcend the constraints, and finally yet quickly to deliver what the customer really needs to solve his problem, not what he said he wanted.

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.

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.

Proposed Reading List

For the CSM Class in NYC on Sept 5-6.

A teacher recently told me this: “To know and not to do is not to know.” And we know from many teachers that we learn best by thinking a bit and then practicing some, and then thinking some more and practicing more.

This is embedded, as one example, in the Deming Cycle.

So, I have already suggested that the best way to learn for you, right now, might be to practice for a while. A short while.

Next, one needs to say that each of us is different. So, if we want our learning to be effective, we need to consider our individual needs and abilities. Some of you think in concepts, some in pictures, some with stories, etc., etc. Some of you understand (or have no interest in) User Stories, for example. Others have pressing needs to understand engineering practices.

Also, now that you have been infected with the Agile virus, you can read almost any book from an Agile viewpoint. War and Peace by Tolstoy is one of my personal favorites. This might be the best way for you.

Now, after all these explanations (and you might say, excuses), here are some suggested readings.  I have these books on my website, with direct links to Amazon, so you might want to go there:

User Stories Applied by Mike Cohn. Great book on how to write and use User Stories. And once you feel you get the ideas yourself, go to his site (www.mountaingoatsoftware.com) and download some of the presentations on this subject. To use for your discussions with associates.

Agile Estimating and Planning by Mike Cohn. Here he discusses planning poker, and lots of other subjects around Release Planning and Iteration Planning. Again, he has very useful presentations on this subject as well.

The New New Product Development Game by Takeuchi and Nonaka. Article. This is where Scrum started. To me, it is essential that we view our selves as creating new products. Passing this one around starts to get light bulbs turning on.

Extreme Programming Explained (2^nd Edition) by Kent Beck and Cynthia Andres. Kent Beck, Ron Jeffries and Ward Cunningham are the three guys most responsible for extreme programming. Kent is an excellent writer, and his discussion of values, principles and practices is wonderful. (Be aware that some people prefer the 1st edition (2000), but that is now hard to find.)

The Knowledge-Creating Company by Nonaka. This is a HBR article that summarizes many of the key concepts in the book (of the same name) by Takeuchi and Nonaka.

The Concept of Ba by Nonaka.  This is an article that summarizes some of the key concepts that are discussed in the Hitosubashi on Knowledge Management book, edited by Takeuchi and Nonaka.

Fearless Change by Manns and Rising. This book is about introducing a new idea into any “group” (such as your company). These ladies are actually Agilists, but the book is about introducing any idea (not specifically Agile). The book presents a little theory and lots of patterns on how to influence various people so that Scrum/Agile/Lean will succeed in your group. The majority of these patterns you know, but the reminders, tips and tricks are very valuable. Arguably, this is the most important book for you right now.

The Power of a Positive No by William Ury. Bill co-wrote Getting To Yes. This book, about saying no sometimes, is essential. Almost everyone in Agile that I know is not practicing sustainable work because they can’t say “no” enough. Frankly (although Bill is a friend) the title is a little hokey to me, and the basic idea seems obvious (you have to say “no” before any “yes” can have meaning). Again, in theory there is no difference between theory and practice…in practice, there is. As you read the book, I think you will learn useful ways to say "no" almost as often as you should. Priorities.

Working with Legacy Code by Michael Feathers. This book has lots of ideas about how to deal with legacy systems. Michael is an excellent Agile Coach (a bit more in the XP flavor).

Lean Thinking by Womack and Jones. The first chapter of this book is an excellent introduction to Lean. Some of you will be amused to learn that Ohno, whom many credit with inventing Lean, said that he learned it all from Henry Ford’s book Today and Tomorrow.

Implementing Lean Software Development by Mary and Tom Poppendieck. Excellent source for taking Lean ideas and applying them to software development. This is their second book. Not a bad book for you to read first, in fact.

Godspeed on your journey.

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?"

Jeff Sutherland in Charlotte July 11-12

Jeff Sutherland will teach a Certified ScrumMaster course in Charlotte on July 11-12.

See Jeff's blog for some information. See here for specific information. And see here to register.

Jeff includes a lot of ideas associated with XP and Lean in his practice of Scrum. (And equally, Kent Beck and the Poppendiecks have been influenced by Jeff Sutherland, in my opinion.)

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.

Google, Agile and Business Value

Google announced on 4/20 that it earned $1.002 billion in the first quarter. The Net was up 69% from 2006. See WSJ.com - Google Displays Core Strength*. The sales increase was not too shabby either.

Maybe it's a company we can learn from. (Or maybe they are just lucky.)

Google uses Agile. As I hear, Agile isn't forced on anyone, and many different types of Agile are used. Which, in a way, is agile itself. My hypothesis is that the relationship between Agile and the increased profits is not coincidental.

But that is not my topic for today.

As I hear it, Google takes a very different view of how to use Business Value in its projects. It allows project teams to work on lots of things, as long as someone thinks there is potential of value. The value is not clearly defined upfront. Google gets a beta product in front of the customer world quickly, and gets feedback. After feedback and improvements, if the product has traction (internally and externally) then they release. Only then do they start to worry about monetizing the product (say, Google maps).

Again, they build, and give it away and build market share. And once they have a product that people want, then they figure out how to monetize it.

What's the idea here?

I am guessing the idea goes like this....
1. The first thing is serving the customers.
2. Some products (for Google at least) don't need to bring in money by themselves. They are looked at as filling out a whole customer relationship. It is those customer relationships that become profitable (in multiple ways, if you know how Google makes its money).
3. The first decisions are made by the bright employees deciding how much they want to invest (their own time) in creating or improving the product. My understanding is that each employee is almost an entrepreneur in the way he decides to invest his own time in projects. (I will guess this is something of an exaggeration, but you get the drift.)
4. Then each product team "sells" the product internally and externally, building users and buzz. And perhaps gathering input and more people (workers) for the project (product). So, the key tollgate is "does this product add value for the customer?" Early on, and to some degree later, internal people act as proxies for external customers. But the product is also out quickly to get external customer feedback as well.
5. Then, once they have a released "successful" product (ie, successful to the customers), then they worry about monetizing it (how Google will make money off it). Sometimes those earning are indirect (eg, via ads rather than via license fees to users).

To me, the main lesson here is that Google folks expects to learn along the way what the customers really want. And what business value really is. So they start getting feedback as soon as possible. It's a question of who can learn more useful stuff faster.

Three Google/Agile videos

Google is doing Agile, and four people have come to talk at the Googleplex about Agile. (Maybe more.)

One is Ken Schwaber, who talked to them for about an hour, mostly about Scrum. The excellent video of his talk is here. The nuances of Scrum become clearer when you hear Ken explain it. His website is here.

Esther Derby and Diana Larsen also visited the Googleplex. Their talk about Agile Retrospectives is here. I am a fan. Of Agile Retrospectives (the activity and their book). And of Esther and Diana.
See also their blogs here and here.

Again, Jeff Sutherland spoke at the Googleplex. His talk on Scrum tuning is here. Also highly recommended. His blog is here.

Carnival of the Agilists for Apr 20

Mark Levison, a friendly Canadian (I am working with a bunch of those Canadians lately) has the controls for the Carnival of the Agilists this time. Again, we are honored to have been selected, this time for Adopting Agile and similar posts related to Lean.

Check it out.

And check out the Agile Tangents group that Mark set up. A number of good people there.

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.