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