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.

Joe's Booklet on Agile Release Planning

I have a first draft, version 1.01 of a booklet that ties together all the posts I have made (well, most of them) on agile release planning.

Here: http://agileconsortium.pbworks.com/w/page/57940361/Joe%27s%20Release%20Planning

It is a bit rough, needs more editing. My apologies for that.

If you have a moment to read it or just look at it, and give comments, please do.

Joe

Refactoring the release plan

At the end of the last post, we had complete the initial release plan.
What were the key outcomes?

[This is one in a series of posts about release planning. See here.]

Well, the plan had some sort of scope, date and budget. Usually on Day zero the quality is 'crappy' to use the technical term. As it must be, given how much we don't know on Day zero.

The real win was that we now have 'everyone' on the same page, at a useful middle level of detail: what is this elephant?  What are we about to do... 

And then we start the first sprint.  Or more specifically, we start the first Sprint Planning Meeting.

But that is not really the end of release planning. But the beginning of RPR (release plan refactoring).

It is absolutely fundamental to agile release planning that we refactor the release plan frequently. I say (and many others that I greatly respect say) that we must refactor the release plan every sprint. Every sprint.  Ok, maybe during every 10th sprint there will be so little change, that we don't have to change the release plan at all.  Ok, maybe this very occasionally happens. But at least we must evaluate that that is the case.

Now, when I say release plan refactoring, I mean all of the following:

* changing the vision (all of these are 'if needed')
* improving the product backlog items (more, fewer, smaller, better)
* re-evaluating business value (very key and very hard)
* Re-estimating the effort (eg, where Story Points are wrong, for new stories, for newly sliced stories, etc.)
* taking a new look at the benefit-cost ratios
* including new learning about risks, dependencies, learning, MMFS, etc.
* re-ordering the work
* doing a new scope-date trade-off.  Usually to make the initial release smaller (fewer aggregate story points -- is one way of expressing it).
* including the newest velocity expectations (based on recent trends).
* adjusting the buffers and communicating the new, new release plan (scope, date, budget) to the right people

Now, I also include in Release Plan Refactoring all the changes to the Product Backlog information to make it ready for the Team to be successful in doing the Sprint work.  Some people use phrases such as 'product backlog grooming' for this. (Note: I think 'product backlog grooming' can have other meanings too, depending on who is using the phrase.)

These activities include:
* breaking down stories or epics into small sprint-sized stories.
* improving the stories or PBIs (wording, INVEST criteria, etc.)
* estimating the business value of the smaller stories
* estimating the effort of the smaller stories
* answering questions from the Team about the expected sprint stories
* adding detail (notes, acceptance criteria, etc.)
* adding an agile spec for each PBI to be in the next sprint.  [Sometimes this may be done 2 sprints or more ahead. But not 'way' ahead.]
* checking that the Team thinks each story (likely to go in the next sprint) is 'ready' before the Sprint Planning Meeting

One could argue that release plan refactoring and product backlog grooming are completely different.  I think this way of thinking is unhelpful.  One of the purposes of release planning is to make the work in the sprints more successful. Release planning is not completed until, for each sprint planning meeting, we have 'the stuff' ready for a successful sprint planning meeting. Among the key success criteria of that meeting is: we used the time of the business stakeholders well.

Let me pause.

Why is using the time of the business stakeholders important?

Well, they are the key independent check on the thinking of the Product Owner.  We know from long experience in our industry that 'knowing what the customer wants' is extremely hard. Extremely. The business stakeholders are people whose time is scarce and yet these people are essential to us in getting a much better fix on what the customer really wants (or what the firm wants).  We want them in the Sprint Planning Meeting, agreeing with what the Team takes in and, at the Sprint Review, giving us feedback.  Because these independent input and output checks are so vital, we must use their time efficiently.

Thus, for me it is better to think of higher level release plan refactoring and lower level release plan refactoring. And when people say 'product backlog grooming' they often mean lower level release plan refactoring of those stories about to go into the next sprint.

Again, the key idea here is that we ALWAYS refactor the release plan every sprint.  We improve it.  This is absolutely key to adaptive planning.

Release Planning: Completing the Plan

As discussed in the previous post on Release Planning, the user stories are now ordered.

(Please see this post for a list of all the posts on Release Planning.)

Now we must complete the Release Plan.

So, we must make the trade-off between scope and date.

There are three ways to do this:

1. Fixed Release Date.  We will release every X months or Y sprints.

Some teams or firms prefer to have a fixed release date. It makes things simple.  It makes managers and others realize that we will release.  They only question is exactly what will be in the release.

2. Fixed scope.  We will release when all of the scope (all the stories or PBIs in that scope) is/are done.

3. Trade-off.  We understand our velocity and go down the Product Backlog a ways. And ask: two sprints, umm, how many features are done?  Ok, three sprints, how many features are done.  Ok, four sprints, umm, customers would really like to see another release, the market needs it, but do we have enough?  Ok, five sprints, umm, I think we have enough.  Let's shoot for that.  -- It is that kind of trade-off.

This requires that we know our velocity.

Estimating Velocity

With an existing team, you might already know their velocity. With a new team, you must guess.

So, we do a calculation to get an educated guess.

First, for the 1 story point reference story (for effort)... how many ideal person days would it take. The Team huddles around the story and reaches a decision.  Imagine the number is 1 SP = 1.5 ideal days.

Imagine the Team has 6 doers (of real work).

Imagine the Team will do 2 week Sprints.

Let's assume the focus factor is 60%. That means, out of an 8 hour day, roughly 60% of the minutes are usable for the project.  The other minutes are used talking about the game, taking breaks, eating lunch, getting interrupted, answering questions, reading the email, going to company meetings, etc, etc.  Maybe some work, but not work on this project.

Calculation:

2 weeks = 10 days.

6 x 10 = 60

60 x 60% = 36

36 x (1-40%) = 21.6

21.6 / 1.5 = 14.4 Story Points for the 1st Sprint.

----

We subtract the 40% has a start-up "cost" for the 1st Sprint.  The Team is learning Scrum, the Team is "forming, storming, norming, performing..", the Team always wants to over-estimate what they can do in a timebox. 
For the 2nd Sprint, we subtract 20%.  For the 3rd Sprint, we subtract maybe nothing.

You may find that these rule of thumb numbers need to be adjusted for special situations.  But they seem to work for most start-up teams.

---

36 x (1 - 20%) = 28.8

28.8 / 1.5 = 19.2 story points for 2nd sprint

---

36 * (1) = 36

36 / 1.5 = 24 story points for 3rd sprint

And so on...

Communications Plan

I tend to put pressure on new Product Owners to release earlier.  They are mentally too tied to the concept of the 100% - 100% rule.  That nothing can be released until everything is done.  This is almost always just wrong.  Hence, I always ask for an earlier release.

Once the PO and Team agree on the scope and date, we then have to talk about the "communications plan", as I call it.

If the Team works with a manager who truly understands adaptive planning (meaning that the current plan will be revised and improved every sprint... this is only the first guess at the plan)... then tell that manager the truth.  Here's what we guess, this is what we are worried about.  This is our feeling about how it is likely to change.  And maybe we have contradictory feelings.

But often some key managers do NOT understand adaptive planning. These "tough" managers (or customers) want you to give a fixed date, and then deliver to that date.

Then you are stuck. So, we have to do what we used to do in waterfall. Add some "buffers" (aka padding, etc, etc) to the date.  For "problems", for new stories to be identified later, etc, etc.

It is hard to guess how much buffer to add.  We have no additional magic.

But, we do strongly suggest that you protect yourself and your Team. Do not get them in a situation of a Death March, trying to meet an impossible date.  More about this later....

And then we talk about, "ok, how will we communicate the date?"  (Almost always, the key issue is the date.) You have to start setting expectations that the date will change if other things change (substantially), and they are likely to change substantially.  This is not one conversation by the PO, but a series of conversations by and with many people.  It is over time that the start to see and feel the power of adaptive planning.

For some of you, the issue is not so much "communications plan", but "what do we put in the contract".  Too big a subject for this post.

Finalizing the Plan

Assuming you have "business stakeholders" as I described them earlier, then always you have to review the release plan you have with them.  Get their buy-in or comments or adjustments.  This of course may affect the communications plan.

So, this is most of the basics.  A bunch of issues we have not addressed.  Some I will address in the next post.