Why should the PO attend the Daily Scrum?

Posted on April 22, 2013 by Joe Little

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

Posted on February 15, 2013 by Joe Little

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 PO – The Team Daily Scrum

Posted on August 25, 2012 by Joe Little

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:

The PO is very important to success.
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.
Knowledge creation as a full team is very important. In multiple domains. All domains impinge on all other domains. (Key example: cost-benefit analysis.)
The full Scrum team delivers the product. Each provides his unique skills and ideas and creativity.
The PO is definitely a member of the Team. Given real life, often 100% of his time is not enough (see also #7 below).
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.)
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.
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.
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.
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.
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: If the PO comes to the Daily Scrum (usually), then over time it will make them at least a bit better.

Certainly some of you have done different things and been fairly successful. For example, with the PO not coming to the Daily Scrum. But could you have been more successful by having him come? 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 to 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?

Posted on February 20, 2012 by Joe Little

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

Posted on September 4, 2010 by Joe Little

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?

Posted on April 22, 2010 by Joe Little

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

Posted on February 22, 2010 by Joe Little

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

Posted on June 24, 2009 by Joe Little

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?

Posted on February 7, 2009 by Joe Little

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

Posted on June 16, 2008 by Joe Little

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