3 Ways a Scrum Team is Managed

We think it is reasonable to manage a Scrum Team in at most 3 ways.  (OK, we mention also a fourth.)

(Context: To simplify, we assume a smallish firm with teams that are mostly working independently.  There are lots of other contexts.)

There are two main rules.

A. Do NOT over-manage or over-control the Team.  Over-managing is not what you do with knowledge workers and not what you do for innovation. Over-control destroys their productivity.

B. Let them self-manage a lot.  But they never self-manage completely in isolation. There is some outside ‘help.’

Let’s describe this a bit more.

1. Self-management

The most important way a team is managed: self-management.

They are responsible for managing themselves to success.  That is, within their scope, they have to figure out what they need, and then get it.  They have to define all the details of success.  They are expected to ask for help in some areas, like impediments.  They are expected to also identify and overcome some issues or impediments themselves.

Often no one explains self-management to the Team. Look at everything (necessary) and assure there will be success.  Overcome your own problems (often, by demanding some help), etc. etc.  The managers and the culture must foster self-management.  The right people must be in the Team so that they will adults.

When the Team comes to a manager (when they should have self-managed), the question should be: could you have managed this yourselves as a Team?  (Typically the manager is thinking they could.) Then go back and forth until they really believe management when they say “self-management”.

Often they have been trained for years and years NOT to self-manage.  It will take more than 1 sprint before they truly understand what self-management is.

Have a discussion about what the boundaries are.  In simple terms, the Team is self-managing within the context of their work; not outside that.

2. Business stakeholders

The business stakeholders (those working with this Team) have a responsibility to provide management over-sight. They should be at Sprint Planning Meetings and the Sprint Reviews.  The business stakeholders (BSHs) mainly are there to provide business-side and customer information, but some or all are also there to manage the Team. (In a ‘subtle’ way, as Takeuchi and Nonaka explain in “The New New Product Development Game” article in HBR.)

3. A manager

Each team should have one manager.  That is, one person who can give them direction.  And one person to whom they (usually) go to get an impediment fixed.

Note: It is best if this person is also their ‘people manager’, but this is not the main function we are discussing here.

This manager usually has multiple teams, and he must keep up with them all.  In general, he or she supports the Team in self-organizing.  But he must intervene if things are going badly.

But sometimes managers do not realize they are supposed to step in if the Team is in trouble.  Or, maybe they are not engaged enough with the Team.

In many cases, though, what I see is that managers over-manage.  They do not let the Team self-manage enough.  And this hurts.  The Team needs to self-organize, which means the Team needs to make some (smallish) mistakes.

But if mistakes continue or might be big, then these manager must intervene.  Usually by helping with one or two impediments.  Possibly by making some people changes.  At the extreme, by dis-banding the Team.

4. Steering Committee: Oversight of multiple Teams

There should be a steering group or committee.  In a small company, this might be the Executive Team.  In a larger company, maybe an ‘oversight committee’.

A purpose of this oversight group is to look at each team and evaluate whether it is doing ‘well enough’ to continue, when compared to other Teams and other opportunities.  And, the Steering Committee can also help a Team resolve some conflicts (eg, two teams want the same person).

Ex: One can also imagine that a manager for one team might not do his job in managing that team, so this committee is a backstop to that level of management.

Each team should meet with and be reviewed by the steering committee once per month. (Yes, there could be other frequencies.)  Usually these reviews should be brief.

The steering committee needs good information to use to review and compare initiatives.  Some facts.

The Team can ask for, and the oversight group can offer, ‘help’.  In Scrum, we typically talk in terms of fixing impediments.

I strongly urge the whole Team be present when the steering committee reviews them.  The Team can answer questions, and they can take any feedback ‘to the Team’ with less misunderstanding.  Try to keep the communication clear.  The Team feels respected, the Team also now feels responsible to the Oversight Committee. It might be ok, sometimes, if only the PO and the SM attend at the steering committee meeting.  Maybe.  But if we are in this together, then let’s be in this together.

So, 3 ‘levels’ of management. (Plus a steering committee.) And that is enough.  The poor Team needs time to actually do something, instead of being managed so much that they go crazy.

In Scrum, it is pretty clear to see if they are making progress, and usually, we can see whether they are making enough progress.

It is just wrong to over-manage innovation.  Much of the variance is just the natural variance in innovation.

 

« « 9 Key Statements about Estimating || Impediments – Charlotte – Oct 2014 » »