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

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 is a ScrumMaster worth? (2)

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.

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

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"

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

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.

What's a ScrumMaster Worth?

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.

"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.)

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.

Much Ado About Animals...or, Animals & the missed metaphor

I have been having or listening to several conversations lately about animals.

In Scrum, we have the idea that the ScrumMaster has some characteristics of a sheepdog. Some of us also talk about chickens and pigs. Mike Vizdos uses that metaphor a lot on his site (http://www.implementingscrum.com/).

As it would happen, my wife, knowing nothing about all this, went out and bought four steel sculptures: a large pig, a baby pig, a large chicken (perhaps a rooster), and a chick (I guess). I will post pictures soon.

Surely this all is not without meaning.

It seems that everyone has been reading Aesop lately. And we're taking our Aesop quite seriously. And perhaps we should.

On using metaphors. Usually metaphors rise from the subconscious to communicate. They make ideas concrete. But my metaphor may not be yours. Just as your attempt at humor may not make me laugh, or make me laugh today. If my metaphor doesn't get through to you, I'll try to say it a different way.

Please don't overuse my metaphors. Only with permission can you extend them. They only come out to play for a brief time, partly because so many want to extend them too much, which makes them brittle and almost useless.

The sheep dog metaphor
Some people are concerned about the woof woof that is sometimes used at the end of the Certified ScrumMaster course. The woof woof is of course alluding to the sheepdog characteristics of a SM. And what can be wrong with protecting the Team?

Well, some people feel that the woofing is like a secret society. Or it seems, in their cultural context, silly and demeaning. (I did not have this reaction, so perhaps I do not do it justice. Nonetheless, I am sympathetic with those who don't "get it" about the woofing.) They feel that the woof starts to create an Us vs. Them feeling.

To me the woof woof is mostly comical, and I fear we can easily get overly involved with a whimsical thing and miss the more important issue.

To me there is a much more useful tension in the idea/feeling of Us vs. Them. A key issue and a key dilemma.

Let me unravel it a bit, as the thread goes through my mind, and then you all join in. So, let me start by saying why I think Us vs. Them is not useful. And then by explaining why it is useful, necessary and inevitable.

Why not useful. To me, to explain this we start with the idea that we are all God's children. (You humanists might prefer "we are all human, with certain unalienable rights".) However much we travel in the dark, we all can come back to the light at any moment. It is not useful to demonize. It is not useful to put people in "bad" categories. (Those who can't woof, those who don't get the woof. Those who woof; those that think the woof is good.) While some actions may indeed be bad, telling a person they are bad usually does not help them stop doing the bad stuff and start doing more good stuff. Why create an enemy before you've met the person?

As an example, I call myself a recovering waterfallic. By which I mean to imply that I have compassion for all who only part get agile, since I myself know that I relapse from time to time from the best ideas in agile. Notice that I don't call others recovering waterfallics, although my guess is that I have talked to quite a few recovering waterfallics, in de Nile and elsewhere.

Most of us are of a mixed nature. Putting the bad out there (in some one else) keeps us from seeing the bad within.

Why useful. Isn't this obvious also? It is so humanly natural to form up in teams. It is embedded in our genes that we must know "our" people and distinguish them from those "other" people. It is also so comforting to identify our enemies within the agile movement. Helps us form our own identify and find friends ("the enemy of my enemy is my friend"). Comforting, and oh so human.

Our language is rife with all kinds of dualities. Light/dark, up/down, good/bad. Ad infinitum. And they are necessary. We often need those simple binary choices so we can move on quickly. If we had to really think about everything, we'd be in quite a pickle. Clearly there are people who don't get agile. We each can identify types of people who are, on average, pretty unlikely to get agile very quickly. Our brain takes a couple of impressions and naturally starts making categories.

And there are indeed instances where a person has hurt the team. We have to identify those persons sooner or later, and do something about it.

The Resolution of Romance (Wynton Marsalis)
If I had a simple resolution to this continuing dilemma, for this tension, I'd be a wiser man than I am. I don't even have a complex resolution. We must have Us vs. Them. We can never have Us vs. Them. Ummm?

Seems to me just recognizing that we have this dilemma is a start. So, let's have chickens and pigs. Let's have a sheepdog to keep the wolves away. But remember, these are Aesop stories for children. We humans are often a tad more complex. And, as Ken Schwaber said, the important thing is that we do more thinking for ourselves, about what our current project situation really is. At least from time to time.

Let's also remember that from our enemies, even in this discussion, we can always learn something. One of my favorite blessings is "May you be blessed with good enemies."

+ Joe Little