Wednesday, December 19, 2007

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.

Tuesday, December 18, 2007

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.

Thursday, December 13, 2007

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.

Wednesday, December 12, 2007

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.

Tuesday, December 11, 2007

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

Thursday, December 6, 2007

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.
* * *

Sunday, December 2, 2007

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?