Agile & Business

The Nokia Test (5): A prioritized Product Backlog is essential

2008-06-15T19:46:00.005-05:00

We started a series on The Nokia test some time ago. This is the fifth explanatory post about the test. To find the others, search above (left). And here is the original post.

The second item in the second section of the Nokia Test is this:

There is a product backlog prioritized by business value

Seem obvious? Well, maybe you don't want to say so quickly.

First, if we are doing Scrum, we must have a Product Backlog. A Product Backlog is a list of all the work items the team is expected to work on. If the Team is doing software, most of them will be features at a high or low level of granularity. In Agile, the growing preference is to put these Product Backlog items in User Story format.

This part of the Nokia Test does not require you to use the User Story format. Or any particular format.

"Prioritized": Ummm. What does that mean?

Well, I think it means that the Product Backlog has been put in order of Business Value.

The Nokia Test does not give us any hints about what Business Value is. My opinion is that this itself is a complex topic. But I think the implication is that the Product Owner (who owns the Product Backlog, and makes all final decisions about it)...the Product Owner will put the items in business value order.

Does the test imply that Nokia always wants to work the highest business value items first?

This is open to some debate. My view is that one can still pass the test if one also uses "cost" (or story points as a proxy for cost) and dependencies/risks as additional factors (bits of information) in helping the Product Owner to order the work.

Let's put this some other ways.

The technical team does not have the final decision about what order to do the work in. Sometimes it is better to be inefficient and get some high Business Value item(s) out there in production.

Since all Product Backlog items are not of the same size (let's call this "amount of work" for now...although one must tread carefully here), and not of the same Business Value, the Product Owner must do cost-benefit analysis to determine (implicitly at least) business value per unit of work for each PB item.

Why do we prioritize by business value? We are always trying to discover and release business value (eg, increase customer satisfaction). Quickly. Only if we use Pareto's 80-20 rule can we do the most important stuff first. Ordering the PB items puts Pareto's rule into play.

And I think the Nokia Test says the Product Owner cannot cop out and say each PB item has the same amount of Business Value.

Similarly, this part of the test does not prohibit some team members (developers), where they have useful knowledge, from influencing the Product Owner about business value and about the order of the work. (Still, Scrum says the Product Owner gets the final say.)

* * *

Well, that's a start on the implications from this one part of the Nokia Test.

Please see our other posts on the Nokia Test.

Note: The picture of the story card above was stolen from here: http://www.pragmaticsw.com/newsletters/Newsletter_2008_05_SP.htm

What's a team?

2008-06-08T19:34:00.003-05:00

Let's review what a team is in Agile.

A small group: 7 plus or minus two.
Motivated by the vision of one person.
Dedicated (ideally 100% but certainly a lot).
With almost all the skills needed to realize the vision.
The team works together daily.

A team is not:
* Lots more people than that (that's a collection of people).
* Motivated by multiple visions (if there is some similarity in the work, that might be a department).
* Following multiple people (that would be confusion).
* Some folks who work together from time to time.

We give a Team a mission, and we expect them to figure out how to deliver it.

For an interesting discussion about how small teams work in warfare, see Maneuver warfare.

Why are teams important?

This may seem obvious to many of you. But even for those, it may be useful to review.

1. No simple problems. We now need a team to figure out almost any problem. We need the knowledge from multiple people.

2. Creating knowledge. The team is the unit that creates the knowledge. The convert tacit knowledge to explicit knowledge. They brainstorm. They convert ideas to something more real, and examine whether they are achieving the vision.

3. Has "it". We can't describe everything that makes a winning team. One day knowledge. One day skill. One day motivation. Every day something different. But they get it done.

4. Motivation. Creating something brand new is hard work. The team members need to motivate each other to get past all the problems and issues. The team has to find its heart. Once it has it, you can let it run.

5. Clarity. If we have a real team, then when we examine what it produces each Sprint, we have clarity about that. The problems are much more obvious. There is much less confusion. The best actions to make further progress are clearer.

6. Fundamental to make Scrum work. Scrum is built upon a team concept. To get the real value from Scrum, you should start with a team. (I have not thought about it as much, but I think this would apply to all or almost all of Agile.)

* * *

Is your team reaching its potential now?

Kaikaku or kaizen? (2)

2008-05-20T20:26:00.004-05:00

I recently did a mail/internet survey, asking people what kinds of training they might be interested in. (If you would like to respond to this, please tell me.)

Someone responded, "how about adopting a continuous improvement approach?" Now, we don't know what the writer had exactly in mind (although maybe I will learn more). One assumes the writer meant something like: "continuous improvement is at least as valuable as more training." So let's play this out some.

In my view, training should be part of Kaikaku...which is a rapid, large, revolutionary change. In my view, there are times to make large changes. For example, when starting Agile. Or perhaps a new project. And there are also times to make small incremental improvements (kaizen or continuous improvement).

The preferred pattern is to have occasional large Kaikaku and many, frequent small Kaizen.

Now in general I am in favor with learning that is closely tied to, and proved by action. Which is to say. "The learner has not learned unless the actions become more effective."

So, training should be used to prepare for action right away.

But let's also talk about what action is. Not as simple as it might appear.

The hardest action is to change one's own mind. The next hardest is to change someone else's mind. (Proper action in the realm of the mind can lead to tangible improvements in satisfaction for real customers.)

Let's look at one example. One can imagine sending someone who is "resisting" agile to an agile course. The resulting action might be no more than a willing suspension of disbelief, so that the team can move forward without active resistance. So, while from a certain viewpoint nothing is accomplished, yet because the team can now be more functional, much has actually changed.

Agile Leadership - 2

2008-05-14T22:12:00.005-05:00

This series on leadership arises from a talk by Mary Poppendieck on Agile Leadership. See our earlier post.

Now let's consider leadership in Scrum. In theory. And then later, in practice.

We are reminded of Yogi Berra's quote: "In theory there is no difference between theory and practice. In practice, there is." (A nod to Nancy Van Schooenderwoert.)

Some in Scrum will say that there is no leader on a Scrum team; everyone self-organizes themselves and things emerge. (See the High Moon video, here.) In a very healthy and capable team one can imagine that things might seem that way, but we rather doubt that is the truth. Or at least, not the whole truth. We suspect that subtle signals of leadership are being given and received within the team. (And then we fall back to...what does leadership really mean??)

We also have had teams that, well, demand a "leader" if not a boss, to guide them in (or perhaps even tell them) what to do. In theory this is not good, but there you are sometimes.

Some in Scrum will say that the Product Owner is the leader. She decides the team's priorities by choosing the Product Backlog items to be worked now and by deciding when they are done. Thus, she is the leader. Or at least a leader.

Others might say the ScrumMaster is the leader or a leader. He is not command and control (as stated in the book), but with his Jedi magic, he is nonetheless in effect leading the team toward higher productivity. Clearly it is an important role, since the ScrumMaster's main job is to manage, and see that action is taken on, the top items on the Impediments List. The role is not a mere process coach for a few Sprints or an MC for meetings.

My own view is that Scrum does not really specify leadership. And that this is a good thing.

First, we need to remind ourselves that there is a whole range of essential things about which Scrum remains silent, expecting the team members to add the appropriate things needed to get the job done in their specific situation. I think leadership falls in this category also.

This is good, because no one-size-fits-all set of answers actually works in all situations. It is good because not all teams require the same dimensions of leadership, and not all teams have capable leaders in the correct roles. This is also partly because not all teams have good followers. (By which we mean not sheepish followers, but those people who can see good leadership and support it.)

Let me remind you (although some may already have inferred this) that when I talk about leadership I tend to mean that group of things relating to vision (purpose, meaning, value), inspiration, and people skills.

Another important area (sometimes included in leadership) is to have the right person make the important decisions. To me, who the right person is must be determined decision-by-decision (or area-by-area). The right person to have the last say on the business value of a story is probably not the same person who should say whether some java code is written well enough.

So, the team should probably define norms about how the various team members will lead. And I would recommend some flexibility in that definition. My bias is that everyone on the team is responsible for leadership in one area or in some way.

Here is the crux, in my view. When the chips are down, on that day when things look worst, who carries the heart of the team? Who encourages that team to stick to it? Who comes up with that one useful, inspiring idea? Who won't let the team fail? Who let's the personal issues get discussed, but then gets the team back on track?

My experience is that this leadership can come from many types of people. It all depends on the people involved.

Although we have no simple answers, the team still needs leadership. (Dang, again we are missing that Agile Cookbook chapter that people can follow and check off to see whether they have a good "leader".)

Agile Leadership - 1

2008-05-14T21:25:00.005-05:00

I was pleased to help arrange a talk by Mary Poppendieck at Google in NYC last week. The topic was: "A History of Leadership". The talk will be out in video soon. The slide deck is here.

This is an important topic. And, if I may say so, Mary Poppendieck makes a number of great points. I will emphasize a few below.

To me, the first thing is to tease out the various meanings of leadership, leader, leading.

Sometimes we mean decision-making, as in "who should make this decision."

Sometimes we mean boss-ship, as in "she's my boss."

Sometimes we mean guiding and coaching, as in "he helped us discover this."

Sometimes we mean domain knowledge, as in "she is the leader in x-ray tomography."

Sometimes we mean inspiration, as in "I would follow him anywhere." I will include providing a vision and resolving people issues in this category, although they might easily be placed in their own categories.

It seems to me, as I will discuss a bit below, we need to be very careful about these different meanings (and others).

It also needs to be said that there are principles and patterns of leadership, and then there is taking a group of people, forming a specific team, and discovering that specific leader of that team. Even if he leads only for one day.

This is to say that leadership arises from specific needs, and for specific followers. Another set of followers might be in a different situation and need a different kind of leadership. A good leader in one situation will not necessarily be successful in another situation (or as successful).

For amusement, you may wish to peek at one of Churchill's famous speeches. Here's one.

Perhaps the most useful thing to say right now about IT efforts is that they are ultimately business efforts. And success to a large degree depends upon making the right trade-offs between a fluid technology situation and an evolving business problem shared by a customer-base in flux. So, we must visualize the problem and see where technology (with other things) can make a great contribution. In concrete terms, Mary Poppendieck puts the technology leader and the marketing (business) leader into one person, based on the Toyota pattern of a "chief engineer." Certainly this addresses one of our key problems: a "technical success" that it not a market success.

Now, what do we do if we don't have such a single person?

Mary Poppendieck says (rightly in my opinion) that we need two people in the team joined at the hip; a marketing leader and a technical leader. This of course is not always possible either, but then at least the problem is clear.

And this also makes clear the more general knowledge-creation problem. The people in the team with business knowledge must learn how to collaborate in creating combined knowledge with those on the team who are technically expert. And vice versa. Only when the two domains (to make it very simple) are fully engaged can a truly successful and innovative product be created (or emerge).

More about leadership in the fog of war in a later installment.

Kaikaku or kaizen?

2008-05-02T21:04:00.003-05:00

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

Small continuing improvements have many virtues to recommend them.

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

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

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

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

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

Services We Provide

2008-04-30T09:54:00.003-05:00

My boss (that would be me) tells me I must make some money in order to afford to spend time on this blog. So forgive a short post with advertising.

We provide Lean-Agile coaching. See here. Or contact us (contact info is at that site). From one day to 400 days. This is what we do; we're good at it. We do many varieties of coaching.

We also provide Lean-Agile training. In fact, we just opened a new site, http://leanagiletraining.com/ We have been doing training for years, but this site is new. Not as pretty as we would like, but that will be improved iteratively. And more content to add to it.

Within training, we provide both public courses (see that site) and in-house courses (contact us). The public courses are being updated all the time (we have some scheduled that are not showing yet).

You may wish to subscribe to our training course newsletter (monthly)...see on the right-hand bar (Can we help you?) or see the mailing list page at leanagiletraining.com. The newsletter also includes 3 or 4 new ideas each month, which we hope you find useful even if the courses are not interesting at the moment.

...well, maybe not as good as a Super Bowl ad.

Now back to our regularly scheduled programming.

Up the creek. Without a paddle

2008-04-30T09:14:00.007-05:00

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

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

Very simple idea. Very true.

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

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

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

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

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

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

What is the scope of impediments?

2008-04-25T11:29:00.005-05:00

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

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

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

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

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

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

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

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

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

Does this make sense to you?

The importance of Velocity

2008-04-24T10:39:00.003-05:00

I had an interesting conversation about Agile metrics yesterday, and wanted to share one insight.

Why is velocity so important?

Well, first we should say, that in many ways it is not. Honestly. Velocity can be unmeasured, used badly, up, down, sideways, misunderstood. Whatever. As long as the team produces some business value (eg, software in production) that is seen as a positive multiple to what they cost, that is all the counts. Of course, we customers always want it sooner, but as long as the effort realized good business value, then it was not too late. The product helped that customer set; it probably helped society more generally.

Still, in most real situations is also really need velocity. Why?

First, for those new to Agile, the typical operational definition of "actual velocity" is the number of story points from the stories (features) completed in an iteration, based on the team's (robust) definition of done. (Describing a robust definition of done is a good topic for another post.)

Three words.

Defense: The team needs velocity because almost surely some manager is going to ask them to do the impossible and go a lot faster (eg, complete more story points in an iteration) than they can go. Velocity is what the team uses to help that manager accept the true.
Challenge: While we do not crucify the team based on demand for magic, at the same time, the team needs to be challenged to make their velocity get faster. This means identifying impediments. And getting them fixed (maybe after management approval, maybe by someone else).
Justification: "What was it you wanted" is the name of a Dylan song. People forget. Managers will lose interest in Agile if we don't have some data to show them and to explain to them why Agile is important. Velocity is one of those key numbers. It helps explain why good teams, good Product Owners, good ScrumMasters, good coaches are needed. It helps keep Agile from being "the flavor of the month" (if you are persuasive in explaining the numbers).

What do you think? Helpful?

What is a ScrumMaster worth? (2)

2008-04-24T10:36:00.002-05:00

Based on comments, I made a few changes to the original post, here.

The specific numbers used in the post are not that important. The approach to logically identifying the value of a better ScrumMaster is. Take the approach, and fill in your own numbers. Help the right people think it through, using their own assumptions.

Your Business Case for Agile

2008-04-22T22:35:00.008-05:00

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

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

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

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

So, what is the case?

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

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

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

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

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

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

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

OK. One more thing on this topic.

How do you prove this for yourself?

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

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

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

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

Can fairly good people generally show impressive progress? Yes!

Developer Abuse

2008-04-21T13:29:00.002-05:00

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

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

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

Being Agile is our favorite thing

2008-04-21T13:27:00.002-05:00

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

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

The Nokia Test (4): You know who the product owner is

2008-04-21T11:21:00.003-05:00

In this series, we are going over each question in the Nokia Test.

The first section of the Nokia Test is a quick determination: are you doing incremental development? Then second section is: are you doing Scrum?

We are now up to the first question in the second section is: Do you know who your Product Owner is?

Clearly, it is not just "do you know his or her name?"

The Product Owner has these responsibilities in Scrum:

Defines the features of the product, decides each release date and content – gets product backlog ready
Is responsible for the profitability of the product (ROI)
Prioritizes features according to market value
Can change features and priority at next Sprint
Accepts or rejects work results

A few comments.

The Product Owner is the main voice of the business side into the Team. She is responsible to assure that the team understands everything the business can tell them about the effort (high level and low level).

The Product Owner is the main risk manager, since most risks are business risks, and must be managed as trade-offs against other things (values, risks, etc). At the same time, the team members are seen as business people also (they signed up to deliver business value), so in some ways managing risk is a collaboration. But when the final decision must be made, she must decide (at least, if it is decided within the team).

The Product Owner is part of the team. (This was debated for awhile in the Agile/Scrum community; the best advice now is to treat the PO as part of the team.)

The Product Owner also has outward facing responsibilities. Most of the team members work within the team, in most senses of that word. She is also responsible for understanding the customers (eg, end-users). This takes constant work, since the customers are always changing.

The Product Owner manages the stakeholders. The stakeholders are people outside the team who have a stake or a say in the product being created. Maybe the product is mainly for external customers, but operations must use it also. Maybe Legal or Compliance has some say, etc, etc. In large corporations, these stakeholders take a lot of work (or so it seems to be required). A key area in managing the stakeholders is getting down to one prioritized Product Backlog, at least the Product Backlog items for the next Sprint.

So, how much time does the Product Owner spend with the Team? There is no precise answer to this question; it depends and it varies. But the Product Owner should work with the Team at least as much as the Team wants. And the Team should want the PO as much as having her will improve the product (speed, accuracy, more value, better, cheaper, etc). It is seldom that one can learn too fast or too much.

The typical situation I find is this. The Product Owner person and the Team start out not used to working together. And not seeing a lot of value in working together much. But they learn about the value over time. Toward the end of the first effort, the PO will usually say "Wow, this takes a lot of my time to be with the team, but it pays such great benefits! It is well worth the effort."

Perhaps this Nokia Test item should read: "The Product Owner and the Team collaborate well"

Mura, Muri, Muda

2008-04-17T14:25:00.005-05:00

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

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

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

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

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

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

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

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

Jim Womack suggested that Lean thinkers practice those in that order, ie, focus on mura first. Perhaps this is good advice for Agile.

Two cheers for the Nokia Test (2)

2008-04-17T07:58:00.002-05:00

A comment by Kelly Waters and a discussion yesterday with Peter Smith prompts me to add another comment.

Some are attempted to come up with a long list of all the practices involved with Scrum (or Scrum plus other parts of Agile). And then score each team.

I don't think the long list replaces the simple short list. First, for many people, the simplicity is important and necessary. They need a quick, bright line to guide them back on to the road as they start to veer off. The short list does that better.

Regarding the long list...

I have done this (or was required to do it), and found one aspect of it very useless and another aspect very useful. And I just thought of another useful way to use the tool.

Useless: I think generally scoring each team is not very useful. Do I care that one team is 63 and another team is 72? You might do it, but I would not make too much of the number. Each practice is not equally important (and probably the importance varies by situation). I think it would be useful to tell the team "well, you answered 'yes' on 30 out of 40 of these items...what does that tell you?"

By the way, we found it useful for an external coach to walk through the long list with the team (ie, not the team's ScrumMaster/coach).

Useful: Asking the questions, some as yes/no and some with a sliding scale answer, is useful in generating great conversations with the team. The trick is to help them identify one weakness or root cause as the highest priority impediment, and to act on it. ("We need a half-day Scrum refresher course, with a focus on the principles" might be one example.)

Useful 2: I think it might be useful to pull data across many teams, and determine what are the practices that teams generally are doing least. That tells me the "Scrum Center" (if you have one) has done a poor job in communicating the value of the least used practices. Or at least that is a likely root cause. Then the Scrum Center can consider how to communicate why that practice is indeed valuable.

I hope these are actionable comments for you.

Two cheers for the Nokia Test

2008-04-16T21:30:00.003-05:00

I am an advocate of the Nokia Test, up to a point.

Why do I like it? I think it is a simple way to set some sort of lower boundary on Agile (Scrum) and it tends to make two problems more visible: Cowboy Agile on one side and Agilefall (aka Wagile) on the other side. Cowboy Agile is where you are doing stuff you are making up on the fly (mainly not doing things you personally don't want to do). Agilefall is where you are doing Waterfall (or mostly waterfall) and calling it Agile (or Scrum). [Alert: Those are my definitions of those terms; others may proclaim somewhat different definitions.]

If the Nokia Test causes people to say, "oh, gee, maybe we aren't really doing Scrum", I think that is a good thing. Especially if they think about it, and decide to do Scrum better.

As with almost anything, it can be misused.

As one example: If people use it as just a checklist, and say "oh, we have 'em all checked off; so we must be doing Scrum well", that would not be helpful. In my opinion.

The Nokia Test only defines an absolute minimum set of things regarding Scrum.

Use the Nokia Test to start some conversations around "Are we really doing Scrum and really getting value from it, or are we just playing at Scrum?"

Passing the Nokia test does not say you are doing Scrum well. Among other things, to do Scrum well, you must really understand the principles and the values of Agile. So, for example, the Nokia Test does not talk about principles. The Nokia Test, in my view, does not even cover all the important practices.

So, it is a test more to determine who is NOT doing Scrum than who really is doing it. It establishes a lower guard rail; if you touch it, you should think a bit.

What does it mean to fail the Nokia Test? Well, whatever you are doing, you should stop calling it Scrum. Does failing the test say you are "bad"? No. Does failing mean you are less productive than before? Not necessarily in my opinion. BUT...although you might be more productive than your waterfall days, I think you are likely to be quite clearly less productive than you could be if you followed Scrum a good deal more closely.

One final thought. I really think using Scrum well can make your teams a whole lot better. But the real point of Scrum is not to brag "I'm doing Scrum just as they told me", but to say something like "Scrum is helping us produce a lot more business value each month....". You should want to do purer Scrum to get more business value, not just to be a purist for its own sake.

The primacy of learning

2008-04-16T07:22:00.004-05:00

I am taking the view more and more that learning is the central thing about business.

What does this mean?

First, learning by itself is not that meaningful. It is learning combined with action. And then that simple seeming dichotomy (between thinking and action) is really not so simple; for example, one of the best ways to learn is to take action and inspect the results.

But is we stick with the simple dichotomy, we want more and faster cycles of thinking and action. Learn, act. Learn, act. (A slightly modified version of the Deming cycle.)

So, in business, my bias is that the key action is providing the best solution you can to the customer's (customers') problem. And learning, in various ways, makes those actions better.

And since the customers are always changing and their problems are changing every minute, there is much to learn. So, what do we need to learn?

what the customer's problem really is (now) (which means walking in their moccasins)
what they want as a solution
who we (the solution providers) are, and what we are capable of (now)
how are proposed solution fits into the context of the firm and of society (eg, can we pay our shareholders a good return)
what technology we should use and how to get the most out of it
how all the changes in people, business, technology and society are affecting this situation (both at micro and macro levels)
how to prioritize the things we need to learn now

My premise is that if we consider learning primary, how we organize people and how we do work changes. But I find, even though I have had this thought before (that learning is primary), it has not yet affected my work and my thinking nearly as much as it should.

The team that learns the fastest wins.

To me, this connects to ideas about the Knowledge-Creating Company and to the concept of Ba.

What do you think about all this? Is learning a key principle as you use Agile to produce customer solutions?

Respect People

2008-04-11T17:39:00.005-05:00

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

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

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

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

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

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

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

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

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

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

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

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

Do we need a coach? Do we need a coach now?

2008-04-10T15:37:00.007-05:00

Here are some questions that come up again and again: Do we need a coach? Do we really need a ScrumMaster? How much time should a ScrumMaster give a team? How good do they need to be? Will we always need one?

I am a coach, so perhaps I am biased.

Still, bear with me as we look at a recent example, and see if we learn anything.

Earlier this week the Kansas Jayhawks won the NCAA Men's Basketball Tournament. What do we see?

They have a coach, Bill Self. (We notice in fact that every team in the Tournament has a coach. Umm.)
He makes a lot of money (I heard $1.2 million per year. Fact checker!?)
Kansas is not firing Bill Self now that they have won. (And why not? Those kids clearly already know how to win.) In fact, they are going to pay him about $1 million more per year than this year (I think it will basically double his salary).
Bill Self does not play basketball; no NCAA coach does. (Very rarely the NBA has had a playing coach.)
The team of pigs is small; only 5 people play at one time. Plus some chickens. The total roster of Kansas was 17. Kansas played 8 people in the final game.
The team plays about 2x per week for maybe 24 weeks.
The team nets a fair amount of money for the school, especially if they go to NCAA's and do well. Consistently. I will guess in the $10-20 million range per year in total. (Can someone fact check this for Kansas?)
The winningest teams tend to have the best coaches. (Or at least so people think.)
The more successful coaches tend to be disproportionately successful (ie, success does not appear to be random or reliant on one lucky pituitary case.). Although a coach is by no means the whole picture. As one simple example: Since 1979 very seldom does the same University have back-to-back championships (exceptions: Florida & Duke).
The coaches run the show at a given University; they recruit players, they hire assistants, etc, etc.
The basketball coach is a full-time job, year-round.
In fact, many teams (all?) have multiple assistant coaches (Duke has 3 famous assistant coaches, presumably very good in their own right).
Basketball is a highly adaptive sport. The point guard is often called the floor general for the team. Plays are invented on the fly.

* * *

So, what do you infer about Agile and coaches from those comments? Or from other things you know about basketball coaches?

I infer that coaches are very valuable. In basketball. And in Agile. And probably more so in Agile than they are generally given credit for. (In Agile, we don't talk much about a continuum from ok to good to very good to great coaches. We should more.)

In my view, a ScrumMaster should be at least aspiring to be a coach. And probably on her way to being a coach.

How do I start an Agile project?

2008-04-08T16:02:00.004-05:00

I have been teaching Agile courses for a while now.

One of the persistent questions is: "Enjoyed the course, but I want more help on actually doing an Agile (Scrum) project?"

In part this question arises from a wish to have a "cookbook". This cookbook notion is something most of the smart people (at least people I think are smart) want to avoid. Agile is there to make everyone think together; it is not there to stop you thinking and let you just follow the checklist in the cookbook.

In part this question arises from a wish to understand everything in two days. While Agile is simple in some ways, it really is far too complex to be fully understood in 2 days. In my opinion, there is still much I need to learn about Agile; much I can get better at. Even after years working at this.

OK it's an awkward question. Still, beginners need some help in starting. (Now, as you learn these dance steps, remember that you will never be a good dancer without feeling the music. In Agile, this means you must let the Agile principles become gut instinct. This will take a long time; keep listening to the music.)

So, what are the basic steps?

At one level, they are Deming's Plan-Do-Check-Act. In fact, at several levels. (See the Deming Cycle.)

But let's take it to the next lower level. This is what I tend to do...

1. Confirm that you have a meaningful effort to work on.

Many times, someone "says" we have a project, but often it is a bunch of nice, somewhat useful work. Don't accept that. You want work that is very valuable. You only have one life on this earth. Do something meaningful with it. And let the team have something truly meaningful to work on.

[Note: I assuming "you" are a manager responsible for a large set of work (eg, a project). But really "you" could be any team member. Or other people.]

2. Gather a team.

It is always good advice to get the best people you can. Recruit them. (Note: it helps to have a juicy piece of work.)

3. Assure that the team is on the same page, and agree on a definition of Done.

Important step. Many parts to it. Often forgotten or minimized. Agree that the definition of done will change later.

4. Prepare a Product Backlog of user stories (and other work).

Identify the stories, identify the Business value of each story, identify the story points on each story, identify other factors (risk, dependencies, etc.)...and then order the work. Do initial Release Planning (for now, I will say that means laying out the work into Sprints, and seeing when the first release will be).

This does not have to be perfect and complete; you will revise, add and improve as time goes on. As you understand the effort better.

5. Work on Iteration Zero.

Prepare the infrastructure that the team needs to do its work. (In some ways, this step could start earlier.) This work does not have to be completed before starting a real Sprint 1. And later Sprints might also include some infrastructure work.

Do I need to say that every Iteration is time-boxed? Yes, even Iteration Zero.

6. Start Daily Scrums (standups).

Start them in Iteration Zero.

7. Do Sprint Planning.

8. Do daily Sprint work and Daily Scrums.

Completing the stories. And this includes refactoring the Product Backlog and preparing Agile specifications for the stories in the next Sprint. And other things.

The ScrumMaster always has an updated Impediments List and is working on the top item. (In effect, this list started on day one.)

9. Do Sprint Review.

This always includes a demo of some sort. We want feedback. We want to learn faster how we were wrong.

10. Do Retrospective.

This meeting must identify actions. And some actions (with some impact) must be taken before the next Retrospective. The actions should be addressing one or two top items on the Impediments List.

11. Repeat steps 7-10 until effort is finished.

When you repeat, you must use Velocity to adjust how much work to bring into the Sprint. And the team must, almost immediately, be thinking of every way to increase their velocity. Every way but working more hours than, say 40 per week.

* * *

Those are the basic steps. There are a hundred questions about each step. The questions (and answers) vary depending on the situation. And usually there are some standard, expectable impediments that arise very early. So they in effect add more big steps in the beginning (or whenever they are discovered).

As with dance or sports, there are lots of variations on the steps, depending on the situation.

"Solve no problem before its time." A catchy way of saying, as you start, don't look for extra trouble. Work on only the most important impediment affecting team velocity. If you worry about every problem that is affecting, or did or will affect the team, you can become too discouraged. (The team can actually "work around" more problems than you probably think.)

More on this "getting started" topic later.

"Kids, careful trying this at home." Some say they actually did try this at "home" without help from an experienced person. With success. Usually, if they had much success, they actually did have lots of help from people experienced with Agile, although perhaps less help than other large firms got.

A metaphor. Kind of like NCAA Final Four basketball, it looks easy until you actually try to do it yourself. It's hard on the body, the head, the mind, the will. Still, if you want to, you can be a winner with Agile. Certainly lots better than where you are now.

The Nokia Test (3): Agile Specifications

2008-04-01T08:49:00.006-05:00

The third line in the Nokia Test is: "The Iteration must start before the specification is complete."

What does this mean?

The first practical goal was to eliminate the analysis paralysis and delay associated with waiting until the specification was "complete". I don't know all the details at Nokia, but I have lived them at many other firms.

What is wrong with this old waterfall process? (at least in my opinion):

too much delay
a pretense that further change (or learning) won't happen
a magical belief that the customer can really fully understand a spec (I have seen it happen maybe once)
a magical belief that "all the questions are answered by the spec", when we know that people learn much better in a face-to-face Q&A format

As an aside, anyone who has made Waterfall succeed of course does not rely on the spec alone; we use agile-like conversations and other agile-like tricks to make the meaning clearer.

So, what are we advocating in Aglie (Scrum) to replace this broken process?

Well, it turns out to be a Goldilocks idea. We have some wish to make the team efficient and at the same time we know we are learning all the time. So, we advocate an Agile Spec. Not too much, not too little; just right.

What does this mean?

Well, at a minimum it means that the business person involved (in simple terms, the Product Owner) at least thinks he understands the story (let me assume the team is using User Stories). And at least thinks he can answer all the questions. It is also a good practice for the Business Analyst (or someone) to write down a page or two or more of notes. In the course of doing that, she (the Business Analyst in this example) will ask the PO several questions, and find out that he doesn't have the answers yet, and so new learning will happen.

But the Agile spec is very short. Maybe a bunch of diagrams. The good stuff is not buried in wads of paper.

Who decides what the Agile spec looks like for a given team? The consumers. Primarily the coders, the testers and other team members who must use it. Different projects and different teams (and even different situations) may require somewhat different Agile specs.

Let me be clear. The Nokia Test does not say "use an Agile Spec". I (and others) are recommending an Agile Spec as a best practice.

And Scrum does not say "use an Agile Spec". Scrum does say "improve your engineering practices" and I (and many others) would suggest that one improvement area would be around "requirements", and more specifically, one would be using Agile Specs.

Be aware that some in Agile would advocate no written spec at the beginning of the Sprint. Nothing written; just have conversation in the Sprint. This has worked, although I think it typically is not optimal (ie, the team usually could have done more if they had used an Agile Spec). While I agree with the importance of the conversation, face-to-face with Q&A, I also think the 1-5+ page Agile Spec per Story is also helpful. As long as there is discussion between the writer and the readers about what in it was useful or in the way, or just missing (and needed to be written down). (Answer to a question: Yes, all the Agile Specs developed so far could be in one document, if the team found that useful.)

I would suggest that about 5% of the team's total time in this iteration should be used to prepare for the next Sprint. This includes building and discussing (at a high level) the Agile specs for the next Sprint.

Remember that we are always learning. Just because something got put in an Agile spec does not mean it can't change (if we now know better). At the same time, an unprofessional attitude about learning ("oh, I'll just let myself learn about that later") is not allowed either. We are trying to learn as fast as we can. By putting all our minds together.

{Note: To find our previous posts on The Nokia Test, you might search on that term in the Blogger search box at the top of this page. We have 3 earlier posts.}

What's a ScrumMaster Worth?

2008-03-25T16:57:00.008-05:00

You may have noticed that some people are feeling a recession out there. So money can be a bit tighter.

So, can you afford a good ScrumMaster?

The answer is obviously yes, and in fact they are even in greater need (since there is greater urgency).

Now, let's unwrap this from a financial viewpoint. We will use a simple example, and provide a simple spreadsheet. Hopefully you can take these ideas, use your own local numbers, and have a good conversation so the right thing happens.

A caveat: This post is not suggesting that the ScrumMaster is the end-all and be-all. We are asserting that the ScrumMaster can have a big influence on the productivity of a team. And that better ScrumMasters can have a lot more influence. And that the best ScrumMasters are rare.

* * *

Imagine a team of 8 that costs $1,000,000 per year. Including the Product Owner and ScrumMaster.

That team produces Business Value at some multiple of its cost. Let's take the case that that multiple is 7x. So the team produces $7,000,000 in BV per year. (One can think of BV being NPV (net present value) but it could be measured, originally at least, many other ways.)

Let's take the case that the team has an "ok" ScrumMaster, but the team is increasing velocity at only 10% per year. (Assume at the beginning of the year they are running at 150% of waterfall velocity.) Assume the "ok" ScrumMaster is making, all-in, $125K.

Now assume a "better" ScrumMaster who can double the productivity of the team in one year. (He does this by removing impediments or having them removed.) And assume that the better ScrumMaster (if he is available) costs $250K per year.

(NB. I hope you are noting that the numbers we are using are simple, round and convenient. You have to identify your own numbers. Nonetheless, I will call the numbers in this post, hopefully, inspirational.)

My, my, my. Very expensive dude, isn't he.

Should we invest in the better ScrumMaster?

Well, let's look at this some more. We assume that the Product Owner has or can discover new Product Backlog items so that the average BV of stories will not decline over the year. And let's assume the better ScrumMaster does not improve productivity by helping her (the Product Owner) discover more business value. Let's further assume the better SM improves (enables the team to improve) velocity roughly equally over the year. So that, over the next year the team will produce $10.5 million in business value (rather than $14 million, if the jump were to happen immediately).

I have also assumed the situation (the team, the managers, the company, etc) will allow the better SM to help enable the team to reach a 2x level.

(N.B. The conversation is about value in relation to cost. It is not, and never was, purely a cost consideration.)

So, for an added investment of $125K, the firm will get an extra $3.15 million. Is this a good business decision?

Well, we don't quite know yet.

Let's assume the better SM finds impediments that cost $1 million to fix (training, SW, HW, etc), so that, in simple terms, the firm must invest a total of $1.125 million total to get $3.15 million.

What do you think? Is this a good business decision in a recession?

One could discuss my assumptions endlessly. Discuss a little if you must; then do an experiment where you are. We are all interested in your results.

(To update this algorithm with your own assumptions, download the XLS file here. And revise it.)

N.B. Scrum was built to help teams get 5x to 10x productivity gains. I think a 2x gain in one year is conservative (low, easily reached in a normal situation). So, there is more juice in the orange. There is also the possibility that you have a "dead core" and further productivity improvements are not possible. More on this in later posts.
N.B. A key principle of Agile is sustainable pace. So in Scrum, the gains are not made by driving the team through a "death march". Unfortunately, this still has to be said for some people.

Agile & Business

The Nokia Test (5): A prioritized Product Backlog is essential

What's a team?

Kaikaku or kaizen? (2)

Agile Leadership - 2

Agile Leadership - 1

Kaikaku or kaizen?

Services We Provide

Up the creek. Without a paddle

What is the scope of impediments?

The importance of Velocity

What is a ScrumMaster worth? (2)

Your Business Case for Agile

Developer Abuse

Being Agile is our favorite thing

The Nokia Test (4): You know who the product owner is

Mura, Muri, Muda

Two cheers for the Nokia Test (2)

Two cheers for the Nokia Test

The primacy of learning

Respect People

Do we need a coach? Do we need a coach now?

How do I start an Agile project?

The Nokia Test (3): Agile Specifications

What's a ScrumMaster Worth?

Suggested Reading - For 2 CSM courses last week