The ScrumMaster should not be the 'people' manager

Agile Carolinas had a good meeting tonight about the 'iteration manager' role that one firm is using.  And a good discussion of the pros and cons.  Many thanks to Ike Eichorn and Brad Ball.

I do not wish to discuss all the ideas raised, but I do wish to make a few observations about how I see the ScrumMaster being effective.

First, Iteration Manager in the agile community is often another, smaller, name for the ScrumMaster.  With this firm, the Iteration Manager is an 'expanded' role.  It includes ScrumMaster, People manager (here called HR manager), project manager, etc, etc.

 ***

First, some people at the organization, maybe many, feel that the new 'iteration manager' role is more successful than what they were doing before.

This of course may still be true, even if the 'iteration manager' role were seriously sub-optimum.

And I think it is sub-optimum, although to be fair, I am not there, and I do not know what they are really doing, but only what people say and how I hear that.

So, we cannot really talk about the specific situation.  We are forced to talk about the principles and other experiences.

***

 Let's look at 3 key factors.

1. We need a real Team to get real success.

What is a real Team?  Well, many people do not know, because they have never experienced it.   And it is true that some sets of real people cannot become a real Team.  But, we are strongly convinced that a strong, stable, dedicated Team will give the greatest success.

A real Team is, first, a small Team of about 7 who, due to a serious challenge, have taken on joint responsibility for a mission.

The Team is of course multi-functional, dedicated, and has most of the knowledge domains and skill sets to accomplish the goal. So, while it may be a challenging mission, it is not truly impossible.

Can one have success without a real Team?  Of course.  But it will be a much lower success.

The Scrum Team includes the PO and the SM.  It is not one person that owns success, but they all do, jointly.

 So, if we start to make the SM too powerful, it means that everyone sees that he (or she) is accountable for success.  Not the Team, but one person.

As one example: to foster Team responsibility and self-organization within the Team, the Team must decide how it will decide things.  But normally, with a good team, that decision-making process should not be 'ask the SM, and let him decide everything'...or anything close to that.

2. We want the Team to self-organize, self-manage, and self-direct.

There is something magical in this.  It is hard to explain, and never done perfectly.  But we find that if decent or better teams self-organize, self-direct and self-manage, they can perform miracles.

Again, the self-organization is very unlikely to be the same if one person is clearly more powerful.

And the SM is making the self-organization happen. It is a funny sentence, because it is almost like saying: I will make you free.  Still, the SM is enabling self-organization.

The SM is mainly a servant leader.  That is, as one way of saying it. he does not tell the Team what to do, but helps the Team fulfill its potential (eg, by removing impediments).  So, if the SM has many roles, he is unlikely to be performing his role as impediment remover in chief.  And it is this role of removing impediments that makes the SM effect, makes the Team more effective, and is key to real success, to the highest levels of success.  For, by removing impediments, the SM can enable the Team to double and triple (and increase more) their productivity without the Team working any more hours.  Or any harder (from a 'too stressed out' perspective).

3. The SM is responsible for greater transparency.

In most or maybe all companies, there is a conspiracy of silence.  An agreement to ignore many things. Often this has to do with the biggest impediments, which might be people issues.

One of the roles of the SM is to help the Team see its biggest impediments.  And then see that these can be mitigated or eliminated.

One of the key problems having the SM as the people manager is that the person can no longer increase transparency.  In fact, due to power issues, one can be sure that he is decreasing transparency.  Things that might be mentioned in the Daily Scrum, for example, will not be said.

And it is hard to notice what is not said.  More broadly, it is hard to notice this overall decrease in transparency, compared to what it might have been.  It does not have to mean that suddenly everything is obviously opaque, just that things are not becoming more and more transparent.

 ***

Can it be that some of these effects will not happen or will be minor?   Well, experience shows that people will not notice, or at least seem not to notice. It is certainly true that for some teams power issues are more clearly pronounced than in other teams.  We suspect mainly due to the character of the people.  Still, this does not mean the effects are not still important.

 Does that mean the negative effects are not there?  No, that is not proof.

Can it be, again, that even though these negative effects are there and substantial, can it be that still this approach is better than what they were doing before?  Yes, I believe experience shows that it can, sadly, be better than what they were doing before, to have an expanded iteration manager versus a badly done SM.

Now, let us assume that we still disagree: that some people still believe that 'the expanded iteration manager' is better than a 'true' SM.  If that is the case, the best way to prove one or the other of the hypotheses is to do tests, and get real evidence.  To be far, several tests will need to be done.  It will take some time and some work, but the difference is worth knowing about.

There is much much more to say on this topic area, but enough for today.

 Your comments and observations, please.  

Why should the PO attend the Daily Scrum?

Umm. Good question.  We partly discussed this in an earlier post.

First, the Scrum Guide (2011) does not require that the PO attend the Daily Scrum.  If you asked Jeff Sutherland is normal preference though, he would say it is probably better if the PO attended regularly.

OK, so why?

Well, first, the Team needs to know it is a Team. And the PO is part of the Team. Yes, he is different than the others. Much like a hockey goalie is different than the other skaters.  But still part of the Team.

Often the key problem is: how to get the Business Value and the detailed requirements into the Team?  It is not going perfectly yet. This is very often our biggest problem.  And it is a very hard problem. There are several 'laws' of software development that speak to this problem.

And the PO is key to its solution.

So, we can say that the PO comes to the Daily Scrum to hear about progress (or lack thereof).  We must be careful saying it that way. The PO has a kind of leadership role, it is true. But he is not the 'boss' that the Team 'reports' to. Or, at least, this is not the approach we want in Scrum.
We want the whole Team, including the PO to be in the same boat.  Maybe the PO is like George Washington in that famous picture, but everyone is doing things to 'manage' the boat toward success. And they are all 'in this together'.

The PO could come to 'comment' on Team progress. Again, careful.  What do you mean by comment?  So, if the Team has a question that the PO can answer, certainly in or just after the Daily Scrum, he will 'comment' or answer.  But the idea is not that he gets to, in a top boss kind of way, stand above the Team and critique 'the other guys' (the Team).  Again, in Scrum the PO is part of the Team. They win or lose together.

Maybe the PO tells the Team the tasks they will do?  NO!  Well, even that, in a different way, we must be careful how we say it.  So, at what Scrum defines as the Task level, no the PO as such would never define and 'force' the tasks on the Team. In part it is because we assume the PO is normally a business person, and would not even know which tasks need doing. In part, we want the full Team to self-organize, and define their own tasks.

But, from a certain point of view, each PBI (product backlog item or story) represents work, and in a sense represents a 'task' for the Team. In that way, yes the PO is the person who does the final ordering of the Product Backlog. So, if the Team gets all the PBIs done that they 'committed to', then the PO can 'give' them the next PBI to work on in the Sprint.

The PO could come to determine if the Team needs help.  Umm, again, careful how you say it.  Yes, the PO could come to hear all the answers to the 3 questions. And, if something comes up where the PO could help, and that help can be provided quickly, then that could happen in the Daily Scrum. But often the discussion could be too long (bust the 15 minute time box), so the PO may only be able to identify that help is needed, and then provide the help after the Daily Scrum.

Now, who actually identifies that the help is needed? Well, it could be anyone, so the best way to say it is that the Team (including of course the PO) identifies that help is needed.  From the PO. But specifically, it can be the PO who discovers first that help is needed on a given story.

One final reason for today (for why the PO attends the Daily Scrum). The PO should give his own answers to the 3 questions. Why?  In part because he is a Team member (meaning, he is a member of the Scrum Team, not that he is doing 'Team role' work). By reporting to the Team, he and everyone starts to think of him more as a Team member.  By reporting to the Team, over time everyone starts to see better how integral his work is to Team success.  Yes, the PO's work is different. Yes, his work is not as tied to the current Sprint as it is for the Implementers. But still, the whole Team needs to start to understand better how all the work is connected. (And if some is not usefully connected....well, maybe fix that.)

Could we imagine some 'mis-understandings' between business and technology at the beginning that could lead to some 'awkward' conversations?  Yes! And this is good!  Because now we as a Team will be addressing real, hard, difficult issues.

Could this conflict or tensions get out of hand?  Yes. And the SM must manage the conflict. Making it more useful rather than 'just conflict'.

***
OK, that's what I think. What do you think?

Are there PMs in Scrum? No (but...)

Scrum has only 3 roles: Product Owner, ScrumMaster and Implementer.
Who is responsible for 'the project'?  Well, that would be the whole Team.
What do we do with George, who was a Project Manager (PM)?  Well, we have to talk to George, but maybe he would make a great ScrumMaster or a great Product Owner.  Or something else.
The ones who liked removing impediments tend to make good SMs. The ones who liked managing the requirements often make good POs.
Next, several comments.
1. Some of the best agile people I know were Project Managers once.  (I was one once.)
2. It is very common for the phrase 'project manager' to imply to some people that that person is 'responsible' for project success.  This is not the case with agile. The whole Team is responsible. Together.  Each person in a slightly different way. But, they win together or they lose together.
Now, often the PM knows well that only the Team has success. And sometimes the Team also understands this well. But as soon as we call someone 'PM', then a manager outside the Team starts talking as if this is George's project to win or lose. And it starts to hurt things, hurt the chances for success. So, I suggest avoiding the term completely.
It is a nice idea that one person only could be responsible. It might seem to make another manager's work easier.  And maybe in some areas, it is true. But in our knowledge work, the whole Team must contribute. So, they win or lose as a Team.
3. Some PMs have years of experience trying to drive a 'team'. They have their checklists. They have their command-and-control ways. I think this way of working is wrong, both as a way to treat people, and as a way to success. In any case, it is not what we do in Scrum.  And, many PMs cannot break these habits. So, watch out for that.
4. Scrum is a simple framework. Scrum does not even try to give the Team, by itself, everything that the Team will need to succeed.  They Team is expected to add things to Scrum, appropriate things for their work and their situation.
In this regards, many PMs have dealt with and studied many of these 'possible things to add'.  So, often George is good at suggesting these things. And other things can also be suggested by other 'disciplines too.
5. Some companies still have PMOs after getting well started in Scrum. (PMO means Project Management Office, although I find each PMO group...usually several PM types grouped together...each PMO group can be run quite differently.)  This may not be the best pattern, but it is not clear that this is a terrible pattern. Or at least, it might be a necessary pattern for a temporary period.  In any case, some PMs can still work in a PMO kind of office, and this does not seem to be totally contrary to Scrum, or to clearly hurt Scrum teams. (But there are occasionally issues.)
6. Most of the duties of the old PM are divided in Scrum amongst the PO, the SM, and the Team.
7. Should we put George (a PM) on a Team that already has a PO and a SM?  And give George mainly his old PM duties?  (We could make a long list of those....)  No, it seems very unlikely this will work well. George will be in too much unnecessary conflict with the PO and the SM. And, while there may be a few other duties, they are not enough to keep George busy full-time.  Maybe, in a system that still also demands Teams to comply with waterfall reporting, maybe then there is enough work for George (the former PM) as a 'pig'. Maybe. But we ought to get away from that as soon as possible.
8. Could Scrum Teams in large organizations need help doing 'project management reporting' and such?  Yes. And often George has a great role to assist several teams in handling this work.  In this case, we might say George is a 'chicken' to several teams.  Still, we would hope that most of this role would go away with time.

The Team and the Implementer Role

There has been, in several places, some good discussion about the roles in Scrum.  And soon the discussion turns (explicitly or implicitly) to 'what is the Team and what does it mean?'

The Team

The full team is what is most important.  Product Owner (PO), ScrumMaster (SM), and Implementers.  Together.  About 7 in total. Ideally 100% dedicated to one set of work (one vision, one product backlog).

They will be motivated, responsible, pigs (in the chicken and pig story), etc.  They will help each other, self-organize, become a strong complex adaptive system, create knowledge together.

If there are problems, it is clear where the problems lie. (Maybe in the Team, maybe outside. But clearer.)  And clearer who or what is affected by the problems (the Team is less effective in building the product).

It is where business and technology meet. And most of the biggest issues are resolved where business and technology meet. (Ok, a complex statement that I will not fully explain here.)

It is this (full) team that wins or loses.  (Yes, a Scrum team can lose.  This is not a failure of Scrum. And Waterfall would not have been better.  Just longer.)

Key Issue 1 - PO part of Team?

There is justified concern, based on experience, that if the PO is part of the Team, he will force the Team to commit to more stories in the Sprint than the Team should.

Well, yes, this has happened. And many other dysfunctions can happen with any set of people, no matter how you configure them. But it should not happen.

First, the PO is typically involved in the process of getting the stories done each sprint.  He provides, or should provide, the business value information and the detailed requirements in a JIT (just-in-time) or flow way during the sprint.  Example: When the implementers ask questions during the sprint (and they always should), the PO should get an answer ASAP (if not sooner). [I also favor the Agile Spec idea, where a mini-spec for each story is ready JIT before the Sprint Planning Meeting.]

Second, the PO gets one vote amongst 6 or 7.  So, the other implementers should be able to out-vote him if he gets too crazy.

Third, let's take an example where the PO will be on vacation. If that case, the PO might say: "We should not sign up for 7 stories, we should only sign up for 6 because I will be on vacation one of these two weeks." So, the PO's input could be valuable that way.

Fourth, I find it is often the implementers themselves who over-commit. And the PO who wants and needs them to be realistic.

So, thinking of the Implementers (only) as the decision makers on the Sprint commitment is typically not that useful.  But, agreed, when we have the dysfunction of the PO trying to get the Implementers to over-commit (I do, sometimes, see that) it is wrong.  But that dysfunction can happen in any case, and mere talk about that 'Dev Team' as distinct from the full Scrum Team will not help much at all.  I find.

Key Issue 2 - "The Dev Team" idea

There is a lot of talk in the Scrum community about the Dev Team, as distinct from the full Scrum Team. (The Dev Team only includes the Implementers, is the idea.)

I find this way of talking, this use of words, generally unhelpful. Confusing, especially to beginners. And confusing later.  (We often have to ask: "Did you want me to call the full team or just the dev team?  And why?").  And just not very helpful.

Yes, the implementers do things 'together' some and talk just amongst themselves.  And I think we can say it that way.  If I want to say it quickly, I call them "the Doers".  Just two syllables in 'doers.'

Should they have an SM or a PO in some of these discussions or in this work?  I find it virtually universal for the first two years that the SM and PO are not involved enough.  In part because people just are not used to thinking about them.  It is a paradigm shift.

The Dev Team idea perpetuates the notion, to some degree, that there is still a concept of a 'technical success' distinct from a business success.  And that is not good.

There are only business successes.  I hope we have recognized that.  We deliver business value or we do not. Or more or less business value.  But "well, we did what we said we would do, and it is real neat technically" are both fairly useless notions.

Result 

So, you can see that the phrase "Team" (meaning the Team role that much Scrum documentation talks about) or "Team Role".... I don't like either of them.  Again, to me they are more confusing than helpful.

And you can see that I strongly feel that the issue of whether the PO is part of the team is also fully settled: Yes. (This is discussed in two earlier blog posts.)

Now, what I am talking about above is how we learn and how we teach and talk.  But in the end, the words are not that important.

The real question is always: what did we do?  What did we accomplish?  What shall we do?    The words can help or hurt a bit, but if you are acting the better way (despite always having some problems with words), then things are pretty good.

The PO - The Team - Daily Scrum

I have some different views on this, and wanted to share them.

Your comments are of course welcome.

I am NOT asking what is or should be in the Scrum Guide. Or whichever 'scrum bible' you use.

I am just saying what my thoughts and experiences have, together, taught me.  I want to discover just what is most effective for 'pretty good' Scrum teams.  (Maybe not best for super teams or for beginner teams.)  So, I am trying to have a conversation -- maybe about what to add to Scrum -- not a religious war.

OK.  My views expressed too quickly:

1. The PO is very important to success.
2. Understanding business value and understanding detailed 'requirements' is very important to success. Both these 'activities' are extremely difficult.  Both for the PO and for the Team.
3. Knowledge creation as a full team is very important. In multiple domains. All domains impinge on all other domains. (Key example: cost-benefit analysis.)
4. The full Scrum team delivers the product. Each provides his unique skills and ideas and creativity.
5. The PO is definitely a member of the Team.  Given real life, often 100% of his time is not enough (see also #7 below).
6. The only team that matters is the full Scrum Team.  It is this team that self-orgs, most importantly. (Yes, every person, pair, teamlet self-orgs....not the most important aspect of self-org though.)
7. I do not think it is useful to talk about a team within the team. (I hardly ever say 'Dev Team'.)  Talking about a team within the team  creates an us-them attitude. And anyway is not useful. And at first at least, a bit confusing.
8. The PO must spend a lot of time with 'people outside the team'.  I will call them, at times, customers. managers, business stakeholders, etc etc.
9. Still, the PO should attend the Daily Scrum as often as possible (by phone if not in person).  And should answer the 3 questions. His work affects the output of the Team.
10. The simplest example is: On Day 1, a question is asked by the coder. On Day 2, the PO can give the answer (or at least say 'I got the answer') in the Daily Scrum.
11. If the PO does not do the Daily Scrum (ever), I think most team members start to think or feel (sub-consciously): "who is that guy; he is not part of the real team".

OK.  This is my experience.  Maybe limited experience.   Maybe just bad thinking.

Imagine that you disagree.

Where we differ, I expect my main reaction or push-back would be: "Well, I can see that happening, and it has happened to me, but I think we should coach them to be better, and often, if we coach them to be better, they actually will be."  Meaning for example: They can do the things above, and it will make them at least a bit better.

Certainly some of you have done different things and been successful.  But could you have been more successful doing it this way?  Or might 'my' teams be more successful doing it your way?  This, to me, is the question.

Again, I am not sure I would coach all beginning teams do it this way.  I am sure some super teams might be more successful another way.  My inquiry is: For most 'good' (but not super) teams, which is the best way to do these things? (PO, Team, Daily Scrum)

Of course, there are many other things in life and in Scrum than just the 3 things I discuss above.

BTW, while what I am saying above is not exactly how it is described in the current Scrum Guide, I do not think it is contrary to what the authors would want.  But it may be more than 'the bare Scrum framework'.  The minimum that they want.

Who should fix Impediments?

In the Certified ScrumMasters LinkedIn group, Michael asked: Who should fix impediments, the SM or the Team?

His own answer was: Both. And then he discussed.  This topic has drawn a fair number of comments.  Here was one of mine.

***

1. Michael is right, that who should fix the impediments and how much the Team should be involved is not a simple question. I think this discussion has brought out the issues.

2. I like what Mike and others said about changing the mind-set of the Team.

3. Clearly, getting the Team involved in impediments is important. To me, the first thing is getting the Team better at identifying the top impediments (imagining that real change can happen), and then better at giving the SM information about how to prioritize them.

4. Clearly the SM should always be working on something, although I do think "observing" is important and hard work. (It can identify some people impediments, for example.)  Working to get others to complete the fix of an impediment is also important.  And the SM should also actually fix some impediments, where he has a decent ability to do so. (If an SM does not know what CI means, I would not have him work on Continuous Integration.  I think.)

5. The list of impediments is endless, in some sense, because never do we have even one thing running perfectly. So, in theory, we could spend all of our time fixing impediments. I think spending about 1/7 of our time on impediments is reasonable.  (This is a bigger issue, but relates to this conversation.)  There are definitely limits to how much the Team should work on impediments.  We want them mostly doing 'real work'.

6. I have never seen a Team reach optimal productivity. Never. They may get to 5x or 10x, but they still have not max-ed out.  I don't believe Michael Phelps has swum his fastest possible race.  In fact, most Teams can't win the Super Bowl the next year...they can't even stay at that high level. Never, never, never send out a team without a 'coach' (without an SM).

***
Comments?

Release Planning & the Early Warning System

Building complex innovative products is, of course, hard.

So, in that context, what is the purpose of Release Planning in Scrum/Agile?

We will not provide a complete explanation here, but we will give a few key ideas.

1. A consensus view of the 'same' elephant. We want all the team members to see the whole product and to start to see the same whole product. We think this is typically the most valuable thing.

2. Think first, but not think too much. This is a neat trick -- getting some people to think enough before they start, and also helping others not get stuck in 'analysis paralysis'.

I find that many people want to know 'perfectly' a certain set of information before they start. Meaning: They want to wait and study too long. I find this seeking for 'perfection' is mis-guided. It typically does not include enough consideration of what it costs us not to know 'X' before we start. (If the cost could be real high, then slowing down to learn 'X' makes more sense).

I think each team should have a good fight about how much to 'study' before starting to Sprint.

3. Establishing a project plan, with a date estimate for the first release and a cost estimate. In most organizations, something like this is usually needed. My experience is that, aside from the discussions about risks and impediments, this is usually the least valuable output. But it establishes a starting point for improvement. So, for several reasons, it is necessary.

4. Establishing an Early Warning System. I was just working with a large client who has a big, multi-team and multi-year effort. Some on the team think they will get done 'early'. And some think they will be 'late' as usual (this is said from my own personal experience that most waterfall projects are late...and this organization is just transitioning from waterfall).

In this case particularly, the group (everyone in the group) needs an early warning system that can tell them whether they are likely to hit the date or not. (A date and a high-level scope has been defined, but the detailed requirements are undefined.) For example, the earlier the group knows there is a problem, the earlier it can take counter-measures to address the problem.

So, the Release Planning sets up the ideas (velocity, story points to be completed, Business Value of the features, etc) that go into the Release Plan. And the Release Plan, with its implied 'ideal velocity', can become the Early Warning System.

Since, in this case, the Chief Product Owner is leading this effort, this gives him great incentive to get the whole group to do professional Release Planning now. So that, for example, refactoring of the Release Plan will take less effort later. So, the CPO needs to explain and explain again why the whole group wants a good Release Plan sooner rather than later. (Only if they want to do it, will they do it well.) Not an easy job. Do-able, but not easy. Especially for beginning Product Owners.

What does a PO do?

We say a Product Owner (PO) can have a tremendous impact on the success of a team, of the team's work.

Say, double the productivity in 6 months. With the recession, we could use that about now.

Sounds nice. How is the PO gonna do that?

Well, this is a constant study, but let's summarize the summary here:

* continually improve the BV Engineering theories and practices
* improve the deliver of the Business info into the team
* become better at correctly telling the team what the customers really want
* optimize, continually, on the 80-20 rule
* identify the minimal marketable feature set, and always yet more minimal
* express the value of the customer solution so well, that the team is totally psyched to do the work
* continually integrate the Business and Technical information to make the best possible trade-offs (such as minimizing Technical Debt)

And lastly, seeing and explaining to many people how every one of these activities, when done well together, inter-link and support each other. (Why? A subject for a later post.)

Take a CSPO course and learn more.

The importance of the Product Owner

It is probably true that the Product Owner is yet more important than the ScrumMaster for the success of the Team.

The ScrumMaster should, almost by herself, triple the velocity of the Team. She is the ingredient, without which it does not happen.

And the Product Owner can execute the 85-33 Rule. Where the $1 million of annual cost to $3 million of annual NPV moves to getting $9 million of NPV for the same cost. (I will discuss the 85-33 rule again soon.) Ah, yes, another tripling, independent of the tripling of velocity.

(What if both things tripled? Would anyone at your firm notice? [Ok, a bit of sarcasm there.])

Suffice to say that the Product Owner is very very important. For the Customer and for the Team. Even for the Firm and its shareholders.

We also think Business Value Engineering is very very important. (Discussed in earlier blog posts.)

So, we are very happy to have two Certified Scrum Product Owner courses coming up. To us, the CSPO courses should be at least as popular as the CSM courses. They are certainly as much (now more) needed.

We have one coming up Feb 24-25 in Montreal and one in NYC (Mar 24-25). See LeanAgileTraining.com.

Completing a Release

OK, so we have a known velocity in Story Points. And, having that, it is an exercise for a 6 year old to figure out how many more sprints until the release.

Example: We have a velocity of 20 and the stories in the backlog for this release have a total of 100 story points, so QED, we have 5 sprints remaining until we can release.

[QED is from my old school days, meaning "which was to be proved".]

Fine, for a shark, a simple project manager or a 6 year old.

What's the problem, you say?

In real life, we need to be cleverer than a shark.

It takes a clever, determined Product Owner (in Scrum terms) to land the release.

We know from long experience that the Product Backlog will (or should) change. New features will be discovered, the customer will "know it when he sees it" (a law of software "requirements"). And "stuff will happen" such that the current known velocity will change.

Most importantly, the PO (Product Owner) will be executing the Pareto Rule, which says that 80% of the value comes from 20% of the stories (maybe better to say 20% of the story points). Maybe not a perfect 80-20 rules, but all those stories slated for the release are NOT required.

Side note: What can happen to velocity? First, it should improve as we remove impediments. Second, "stuff happens" and the foreseeable problems (which we refused to foresee) happen. And the completely unexpectable happens with known regularity (and perhaps some unknown frequency as well).

Let me emphasize again: The PO should dynamically be looking at the product as it grows to determine the Minimum Marketable Feature Set (MMFS) to release. This is a very dynamic process of discovery. Or should be. When you are creating something for the first time, there is always plenty to learn. (Or, if you waited for the "perfection" of the so-called requirements, you probably waited way too long.)

For a given product, we hope there will never come a day when we are finished improving it. When all the stories are done. We are always discovering what they want most NOW. Customers always want more (although the "more" that they want is often less...example: less complexity).

Should we invest in a better Product Owner?

I won't bore you with the calculation, but...

If you assume that a better Product Owner can:
* increase the value of Product Backlog items (stories) by 20% on average
* identify the Pareto curve partially in the Product Backlog, so that an 85-33 rule applies
* and if we assume that the team costs about $1,000,000 per year (all-in) and delivers, before the better PO, about $3,000,000 per year...

...then, what happens?

The team is now able to deliver $3,000,000 "projects" three times per year. Thus, this new PO has tripled the business value delivered by the team.

So, how much could you afford to invest in that better PO to get those results? Probably more than $1,500 (eg, for a Certified Product Owner course). And, while the course is good, I suspect that most Product Owners need more than just the course to get those results (eg, perhaps some coaching from someone really good).

So, what's the first impediment to doing this?

What I find is that most firms think of their IT department as a cost center. And thus they have no concept of BV delivered by IT, much less metrics around that. So, I am suggesting that just getting estimates of BV (and telling the team) and then measuring (even if only roughly) the BV actually delivered would be a big step in the right direction.

BV does not have to be measured in money. At least not initially. Depending on your firm, other direct metrics would be more meaningful. Then you need some experts to give you a rough estimate of the money value of those benefits.

Knowing the BV delivered of each team might be kind of important right now. In more ways than one. Go talk to your Product Owner about that today.

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

Only solutions deliverers

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

This is an unhelpful distinction.

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

So we all are just solutions deliverers.

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

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.

Follow-up to : Much Ado About Animals

There has been a bunch of discussion about the chicken and pig story in the scrumdev yahoo group lately. And my friend, Mike Vizdos, uses the chicken and pig metaphor a lot on his site: Implementing Scrum. That's a link to the latest cartoon.

Reminder: Metaphor alert, as described in my previous post on this subject.

At about the same time, my wife bought 4 steel sculptures, 2 of chickens and 2 of pigs. For no known reason (she knows very little about SCrum and I had not mentioned the chicken and pig sory to her). Since I think of the chicken and pig story is a great Aesop fable for children, let me show you the baby chicken and the baby pig first.

Here's the baby pig. I love the authentic rust.
And the screw used for the nose (look closely). Wouldn't you want to be a pig? (Oh, yes, that's right, it's just a story about committed vs. involved. You don't have to be a real pig.)


Now, here's the sculpture of the baby chick.
What do you observe? Seems to want to dominate the little pig (must be a conspiracy there). Seems a bit of an air-head. And, again, rust becomes her (my artistic impression is that this chick is female...apologies to those who disagree). And I don't know what's up with that tail feather.

Was I talking about a real chicken? Was I talking about a real person? No, in both cases. I was talking about a real thing, that picture of a sculpture you see above.

Here's to always inspecting and adapting based on as-close-to-the-real-thing-as-we-can-get.

To increase the level of fun, let me quote from Mark Twain's Huckleberry Finn:

"PERSONS attempting to find a motive in this narrative will be prosecuted; persons attempting to find a moral in it will be banished; persons attempting to find a plot in it will be shot.
BY ORDER OF THE AUTHOR,
Per G.G., Chief of Ordnance."
Perhaps he protested too much. You be the judge.

Please tell me if this story or these pictures are amusing to you. They say that education and entertainment have been entwined for thousands of years.