The Nokia Test (6): Estimates created by the Team

Another installment on the Nokia Test.

Before we begin, a quick mention that Jeff Sutherland has done an improved scoring on the Nokia Test. See here.

So, the next item on the test says: "The Product backlog has estimates created by the Team."

Why is this important and what does it mean? Meaning first.

So, normally in Scrum estimates mean estimates of relative size/complexity in Story Points. See Mike Cohn's book:


Each story (or at least any story in a Release Plan or Product Roadmap) needs a story point estimate. You can't bring into Sprint Planning any stories without Story Points. No, no, no. (If the Story is discovered in Sprint Planning, that's a bit different.)

And these estimates are created by the Team of implementors. Those who will do the real work.

Why?

Well, estimating my own work gives me much more motivation. And responsibility. And a reason (well, another reason) to appreciate how my work interacts with the work of others. If the Story Points come from some other person or group, they don't have the same feeling.

Yes, there is a downside. Not every Team is equally good at estimating. Yes, it's true. But we are convinced that the negatives are more than offset by the positives.

Another key reason for this test is how we will, later, use Story Points to know velocity. And how we will use velocity for many things, from which I will highlight three:

• Tell some managers: "Look at our velocity. We are going at 20 work units per Sprint. Stop hoping and dreaming that we will go at 40 work units. It's magical thinking and it ain't happening. And your trying to make it happen is just making things worse."
• Tell ourselves: "Folks, we're going at 20 Story Points, but we need to do better. Let's identify a top impediment and FIX IT. So that we can go 22 or 25. Now! (But not by working harder.) "
• Face the truth. Velocity is a way to help us all face the truth. And take action. (Ex: If you name an impediment, someone is going to ask: "Ok, what do we do about it?")

OK. That's some commentary to start with. Now put your thoughts into action.

Agile Portfolio Management - 2

OK, so we got started earlier.

What next?

Ummm. One of the goals of Agile Portfolio Management is making sure the most important things are done first. And that all of us are only working on the highest priority things.

One of the goals of Agile Portfolio Management is to enable us to harness change for our competitive advantage.

[Note: Agile Portfolio Management is distinct from Scrum, but I will talk about APM in a Scrum context. In a different context, one would need to explain it differently.]

OK. So how do we do that?

Well, if we have a bunch of teams, let's say 5 Scrum teams of about 7 people each, we name a Chief Product Owner for that whole group. The CPO prioritizes a high level Product Backlog, and assures that all 5 teams are only working on the most important stuff. The CPO must organize the "Product Owner team" so that great "stories" are given to each team. So that lots of Business Value is realized in every release, much more than before.

The CPO is not trying to make individual teams efficient per se, but trying to identify and get the Business Value released (and get the cha-ching, the dollars rolling).

The CPO (and the PO team) is always surveying the winds of change, to enable our company to adapt faster (or to minimize bad impact).

Every month, the PO team is looking at all efforts and teams, and asking: How can we adapt faster so that more BV is realized? They recognize all the different learning that is going on, and see where it leads them. The monthly cycle is largely because this is the typical frequency with which senior stakeholders can engage and participate. So, the PO team is looking across all the teams and saying: Ok, where is the best place to invest now?

Many consequences could arise from these conversations:
* any month a significant effort could be decommissioned
* any month a new effort could be started
* the direction of any team could be changed, perhaps in a minor way, perhaps in a more major way
* the master Product Backlog is refactored with input from all stakeholders
* stories are eliminated, modified, added...and the impact of this is understood and socialized

Thus, at a fairly high level, the overall direction of this group is adjusted. Then, at a lower level, the CPO gives specific stories (maybe larger ones) to each Team. The PO for each team typically will need to organize the refactoring of the (large) stories into smaller ones that can go into an individual Sprint for his Team.

The PO team does not attempt to micro-manage at a level below the Story. And in general, the PO Team does not have time to deal much with small stories, unless there is conflict or important learning needed about such things as: "how does this story fit with our overall direction?" "how does the story in team X fit with another story in team Y?"

More later...

Agile Portfolio Management - 1

A few people have been asking about "Agile Portfolio Management". Or at least about "how do we manage this stuff?" and what they mean is what I call Agile Portfolio Management.

Agile Portfolio Management is of course distinct from Scrum, but for simplicity, I have assumed a Scrum context.

First, Scrum is relatively silent on this subject, which is well and good. It is an advanced subject. And one can't implement "all" of Agile in a single go. So, better to make it an advanced topic.

Still, I have heard others say that if one gets "demand management" down (controlled) in an Agile way, then all the Team stuff (eg, all the other Scrum stuff) becomes so much easier to implement.

One might say: Mura, muri, muda. That is to say:
* Establish an evenness of flow first
* Do not overstress the system
* Then remove waste (or, one might say, other wastes)

Let's unpack these for a moment.

You can't get evenness of flow if the team is constantly being interrupted (for example). So, demand management means you have to control the flow of demand (new features) into the team to eliminate interruptions (and allow change).

You have to get business (and the team) willing to identify each team's capacity and NOT over-stress the team by asking them to deliver more than their capacity. When you over-stress, you actually reduce the real capacity of the team.

Then, removing waste, in simple terms, is removing the impediments identified by Scrum.

Next, some discussion of "single product backlog" (for multiple teams) and "chief product owner".

Note: Apologies for typos in the earlier version.

Reading List CSM Sutherland/Little course

We recently led a course in Atlanta.

Suggested reading included the following:

    

And....

The New New Product Development Game by Takeuchi and Nonaka. hbr.com

The Contradictions That Drive Toyota's Success by Takeuchi. hbr.com

The Concept of "Ba" by Nonaka and Konno.

Comment: For the books, I think it is more colorful and more useful to provide you with a picture of the book and access to Amazon's info about the book. Hope this is not otherwise a problem; I am slightly concerned that it may appear too commercial.

Note: I 

Scrum Certification Test

The Scrum Alliance has recently announced a Scrum Certification test.

Two cheers. This is a minor, good thing.

And it gives us an opportunity to say what makes someone good at Scrum.

Hint: High scores on the Scrum Test probably have very little to do with it.

First, Scrum is a team sport, so how good one person is is almost irrelevant.

Second, explicit knowledge, while somewhat useful, is not the main deal. The juice is in the tacit knowledge.

Third, building unused inventories of explicit knowledge is probably NOT going to help.

Fourth: Courage.

It takes courage to come in each day and face one's own imperfections, and force oneself to get better. Similarly, it takes courage from the team to come in each morning, tell the truth, and face their own imperfections. Every day. (It's fun too, but I think courage is the key.)

And it takes courage to tell the managers of the organization you are in that things need fixing around here.

So...

More book learning about Scrum. Yes, good. Hey, and let's add a minor test just to encourage that.

More courage. Much more useful.