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

Self-organization

We have this idea in Agile, that the Team should self-organize.  This is an important idea. And also an important occurrence (eg, the reality precedes the idea).

In Agile, self-organization is compared to command-and-control.

We think self-org is an important thing to study, both in general and in your Team.

Why

Well, one, because it is just right.  People are free, and self-organization is saying that the Team is allowed to be free.

I guess this needs to be explained a bit.  Some will say: well, the company has bought their time as employees, so the company gets to define what the Team does.  Well, let is concede this at a high level; let us say that the company may define the vision or the goal or the general product.  Perhaps even the user stories.  The Team members are not slaves, but we can assume that, as employees, they agree to do the company’s work for pay.  A contract.

But, devising the work, figuring out how they will get to the goal, they should have the freedom to do.

The second main answer is: self-organizing humans tend to do better work than human ‘slaves’ (humans directed by one or a few command-and-control people).

There is lots of evidence of this. The first book I recommend is The Wisdom of Teams by Katzenbach and Smith.  This is a rather old book.  But the basic evidence is that a self-organizing team out-performs, almost always, an individual.  And to such a degree that the extra cost is well worth it.  But, you must given them some degree of ‘freedom’.

There are also a lot of more recent evidence.

Some topic you may wish to research:
Self-organization
Complex Adaptive Systems
Maneuver Warfare
Free Enterprise
Knowledge Creation

Note: Some people say that a free enterprise system is mainly characterized by (mostly) private ownership of capital (means of production). And attribute its successes or failures to that. Others focus on the freedom of individuals to make their own decisions (much like the “wisdom of crowds” idea) and on the view of the national economy as a complex adaptive system, trying to accomplish high-level economic success via many individual agents (people or companies) making their own decisions.  In our view, successful free enterprise countries exhibit many of the successful characteristics related to self-organization.

Command-and-Control Managers

Lots of managers have been taught, explicitly or implicitly, that the ‘workers’ are dumb, and the manager must tell the worker how to work.  In our view, especially for virtually 100% of knowledge workers (our domain), this is very very incorrect teaching.  But it is nonetheless, what they have been taught.

Now, some of them also understand freedom to some degree, and understand that they want the people in their group to ‘think for themselves’. But, we can say with relative assurance, most companies have a lot of people who are relatively command-and-control in their style.

And, in pressure situations (our common situation), they want to use too much command-and-control.

Again, this is not true of all managers, but of many. It depends, in part, on the company’s culture.

It is hard to convince these people to be patient for self-organization.

Teams that won’t self-organize

This is seen in real teams.

There seem to be several root causes. One, the team has been beat down by command-and-control managers so much, that they have ‘forgotten’ how to self-organize.  Another: that they Team does not believe it when managers say ‘self-organize’.  Another: The Team is fearful that by self-organizing they will be ‘held accountable’ with punishment a likely outcome.  To avoid pain, they refuse to self-organize.

Whatever the reason, two things can be said.

Many Team (perhaps with Agile coaches) do eventually break out from being ‘stuck’ (not self-organizing).

And some Teams may take a very long time or perhaps never do it.

The key advice is this: If the Team will not self-organize, or seems to want to self-organize to mediocrity, then a good manager should intervene.  Temporarily.

Perhaps prior key advice: Be patient. Often Teams will self-organize in two or three sprints.  Keep talking about it, and ask them if they need help.

Third advice: In the view of some (including me), some Teams lack some key skills to self-organize. For example, a new junior Team may not know really how to break down work into tasks for the sprint planning meeting. Sometimes ‘holding their hand’ as they mature is a very successful approach.  And 3 or 4 sprint later, they can be very good at self-organizing their own Sprint Backlog.

Learning to decide as a Team

I think each Team learns how to decide.

The first, most useful thing, is that everyone in the Team gets to offer input on a decision.

Next, the Team needs to accept that no decision is ever perfect.  Thus, decisions in general must be made, perhaps not always quickly, but promptly.

The Team needs to understand the impact of decisions on the morale of the Team and on the success of the Team.

In our view, most teams go through a forming and storming period of decision-making.  And then later get better.

Good self-organization… and better

Lots of Teams seems to self-organize well.

What is also common is for most Teams to plateau.

In part, we may say that a root cause is that most Teams want to reach a stasis… a place where things are balanced and where change slows down.

But have they reached the height of improvement?  We think not.  Some Teams have reached much higher heights.  And some Teams keep on improving.

There seem to be two main factors (or sets of factors):
* magic — or, more accurately, a bunch of things that are hard to describe.
* a bunch of factors that people talk about, and some teams study and work on

Some of these last factors seem to be quite ‘soft’.  Love, listening, creativity, heart seem to be among them.

Lastly

If you have never been on a good team, it is hard to understand what self-organizing is all about.

Within the Team, it might be rather rough and ready. But a lot depends on the specific individuals in the Team.

Self-organization

Some smart people are discussing self-organization on the Lean Software Development yahoo group. You might want to listen or talk there.

Here is what I said today:

****

First, we must recognize that self-organization happens willy-nilly all the time. The only question is when does it start, and where or why does it stop. (Thanks to Tolstoy and War & Peace for explaining this to me. And I am not just a slow learner; it’s a great book in many ways.)

That is to say, whenever a ‘boss’ gives someone an order (big or small), that person must figure out how to do that (assuming they agree to do it… lots of self-organization very smartly ignores the boss’ stupid orders).

At a high level, an ‘order’ could be an initial vision of a product: “We need a hybrid car pronto…figure it out.” I think none of us would call that command-and-control, but it could be called an ‘order’.

AND…with a Scrum Team there are rightly times and places for them to say “geez, we don’t know what to do next, can someone help, please?!!?” Not exactly classical self-organization.

Yes, self-organization is magical and is changing all the time (to a lessor or greater degree). But it is quite real and indeed happening all the time. And we all have many experiences of it.

Now, when asked, I don’t think that a ‘capable team’ that kinda sorta wants to do the work will ever refuse to self-organize. Assuming they are not dysfunctional also. From their background (company culture), they may at first not believe the request to self-organize (how did the manager allow that to happen??). But after a Sprint or two, I have always seen them self-organize.

And I have seen more than one mediocre team need a manager’s ‘nudging’ (that’s the official term) to get them started. This is partly because they are relatively inexperienced, not used to power, and not used to being in the project this early in the process. It feels odd to them so they feel unsure what to do. But, once started, they self-organize pretty well.

Now, one more thing must be said or asked. Will a team of 7 always come up with the best solution on their own?

Asked that way, I think it is clear the answer is No. Even if they give themselves some feedback (eg, the Scrum demo). So, the Team should be encouraged to ask for more feedback and advice. And indeed, there is room for managers to provide leadership. It might be called ‘coaching’ or something else (so that all of them are less likely to fall into command and control). But,
despite what some agile people say, what I see is that smart and good managers have a real role. (OK, yes, there are fewer of them than we want. Agreed.)

And that these good managers are not contrary to self-organization at all. Once mutual respect is built up (and, as Taiichi Ohno might say, mutual humility: “Half of what I know is wrong” is pretty close to his quote).

Spontaneous Order


I will not remember this well (knowledge decay), but there is a great quote from Fujio Cho (now Chairman of Toyota) at the beginning of Liker’s The Toyota Way. Something like: “There are many things you do not understand, and therefore we ask you, ‘why don’t you just take action? Try to do something.’” With the idea that you thus cut the gordian knot of inaction, and start real learning.

What happens if we do not? The opposite: “And thus the native hue of resolution is sicklied o’er with the pale cast of thought.”

And enterprises of great pitch and moment
With this regard their currents turn awry
And lose the name of action.

I have been in projects like that, and so have many of you. (These last two quotes are from a play, not Fujio Cho.)

The soft spider web of thought can be the hardest, most granite-like roadblock.

Yesterday I finished helping to teach a Certified ScrumMaster course with Jeff Sutherland. So, a couple of related thoughts from several conversations.

1. Spontaneous Organization. In the agile community, we are fond of self-organization and complex adaptive systems. And these ideas go way back. Chuangtze and Laotze taught us that the Tao that can be expressed is not the true Tao. That Tao organizes itself in things great and small. And Chuangtze especially talked about the spontaneous organization of things, nature, people, society. That if left alone, they would move toward Tao; that human meddling would more likely move them away from Tao. Better that they take on that more perfect imperfection of Tao, he seemed to say.

Like many another idea, these ideas were picked up later by others, by Proudon and Hayek for example. Tolstoy speaks of this when he talks about the hive of Moscow after the battle of Borodino in War and Peace. We see this in the things of nature, where Energy and Mass self-organize at the speed of light. (OK, perhaps a play on Einstein.) But there is a natural organic spontaneous organization of things.

Now, in real life, that spontaneous organization might be at a mediocre level or a hyperproductive level. The ScrumMaster may have more influence over this fork in the road than she has accepted yet.

I suggest to you that the ScrumMaster, at least, think deeply on how to put these mere thoughts into action for each team. And stir the pot gently. Maybe start here: http://en.wikipedia.org/wiki/Spontaneous_order

It is by spontaneous order that free enterprise gives you your daily bread. However much we may say (and it is true) that man does not live by bread alone, still we must have bread.

2. The ineluctable contradictoriness of things. We humans have this wish for things, for life, to be simple. And so in some ways it is indeed. “A kiss is still a kiss.” But we are everyday forced, if we allow our eyes to see, that in so many things there are contradictions. Male and female. Good and bad. Black and white. Darkly wise and rudely great. Go fast slowly. Achieve by not trying. I must be cruel only to be kind.

Sometimes we see through the glass, darkly, that these contradictions do not need to ensnare us, but rather they give us balance.

So, for a pedestrian example, the ScrumMaster should be a servant-leader. The Team should use velocity to push back at the magical-thinking managers who demand they double output; and the next minute demand of themselves that they push velocity to hyperproductivity. From a certain point of view, these can seem utter contradictions.

In theory, we may think these contradictions should make us fail; in practice, done well, we come to know they do the opposite.

Perhaps a few of you will find the famous Butterfly Dream (see that link) an apt koan for the harmonious contradictoriness of things. Chuangtze has other, perhaps better, stories that deal with this.

ScrumMasters: They can cut through their mental spider webs in a minute. Or in two years. You can be a key difference. This is your great refactoring work. Find that sharp, swift, gentle, liberating sword. And pull it out.

Shock Therapy

Back in September, Jeff Sutherland spoke at the Googleplex in NYC.

Topic: Shock Therapy. Also called: “Self-Organization: The secret sauce for improving your Scrum team”.

About 90 minutes.

Here: http://www.youtube.com/watch?v=M1q6b9JI2Wc

Recommended.

Summary: Shock Therapy is a technique for a special and experienced coach to work with a Team to help the team boot up so that they can self-organize to a better life and hyperproductivity. Like many things in Scrum, it sounds paradoxical, but is not in practice.