The ScrumMaster should not be the 'people' manager

Agile Carolinas had a good meeting tonight about the 'iteration manager' role that one firm is using.  And a good discussion of the pros and cons.  Many thanks to Ike Eichorn and Brad Ball.

I do not wish to discuss all the ideas raised, but I do wish to make a few observations about how I see the ScrumMaster being effective.

First, Iteration Manager in the agile community is often another, smaller, name for the ScrumMaster.  With this firm, the Iteration Manager is an 'expanded' role.  It includes ScrumMaster, People manager (here called HR manager), project manager, etc, etc.

 ***

First, some people at the organization, maybe many, feel that the new 'iteration manager' role is more successful than what they were doing before.

This of course may still be true, even if the 'iteration manager' role were seriously sub-optimum.

And I think it is sub-optimum, although to be fair, I am not there, and I do not know what they are really doing, but only what people say and how I hear that.

So, we cannot really talk about the specific situation.  We are forced to talk about the principles and other experiences.

***

 Let's look at 3 key factors.

1. We need a real Team to get real success.

What is a real Team?  Well, many people do not know, because they have never experienced it.   And it is true that some sets of real people cannot become a real Team.  But, we are strongly convinced that a strong, stable, dedicated Team will give the greatest success.

A real Team is, first, a small Team of about 7 who, due to a serious challenge, have taken on joint responsibility for a mission.

The Team is of course multi-functional, dedicated, and has most of the knowledge domains and skill sets to accomplish the goal. So, while it may be a challenging mission, it is not truly impossible.

Can one have success without a real Team?  Of course.  But it will be a much lower success.

The Scrum Team includes the PO and the SM.  It is not one person that owns success, but they all do, jointly.

 So, if we start to make the SM too powerful, it means that everyone sees that he (or she) is accountable for success.  Not the Team, but one person.

As one example: to foster Team responsibility and self-organization within the Team, the Team must decide how it will decide things.  But normally, with a good team, that decision-making process should not be 'ask the SM, and let him decide everything'...or anything close to that.

2. We want the Team to self-organize, self-manage, and self-direct.

There is something magical in this.  It is hard to explain, and never done perfectly.  But we find that if decent or better teams self-organize, self-direct and self-manage, they can perform miracles.

Again, the self-organization is very unlikely to be the same if one person is clearly more powerful.

And the SM is making the self-organization happen. It is a funny sentence, because it is almost like saying: I will make you free.  Still, the SM is enabling self-organization.

The SM is mainly a servant leader.  That is, as one way of saying it. he does not tell the Team what to do, but helps the Team fulfill its potential (eg, by removing impediments).  So, if the SM has many roles, he is unlikely to be performing his role as impediment remover in chief.  And it is this role of removing impediments that makes the SM effect, makes the Team more effective, and is key to real success, to the highest levels of success.  For, by removing impediments, the SM can enable the Team to double and triple (and increase more) their productivity without the Team working any more hours.  Or any harder (from a 'too stressed out' perspective).

3. The SM is responsible for greater transparency.

In most or maybe all companies, there is a conspiracy of silence.  An agreement to ignore many things. Often this has to do with the biggest impediments, which might be people issues.

One of the roles of the SM is to help the Team see its biggest impediments.  And then see that these can be mitigated or eliminated.

One of the key problems having the SM as the people manager is that the person can no longer increase transparency.  In fact, due to power issues, one can be sure that he is decreasing transparency.  Things that might be mentioned in the Daily Scrum, for example, will not be said.

And it is hard to notice what is not said.  More broadly, it is hard to notice this overall decrease in transparency, compared to what it might have been.  It does not have to mean that suddenly everything is obviously opaque, just that things are not becoming more and more transparent.

 ***

Can it be that some of these effects will not happen or will be minor?   Well, experience shows that people will not notice, or at least seem not to notice. It is certainly true that for some teams power issues are more clearly pronounced than in other teams.  We suspect mainly due to the character of the people.  Still, this does not mean the effects are not still important.

 Does that mean the negative effects are not there?  No, that is not proof.

Can it be, again, that even though these negative effects are there and substantial, can it be that still this approach is better than what they were doing before?  Yes, I believe experience shows that it can, sadly, be better than what they were doing before, to have an expanded iteration manager versus a badly done SM.

Now, let us assume that we still disagree: that some people still believe that 'the expanded iteration manager' is better than a 'true' SM.  If that is the case, the best way to prove one or the other of the hypotheses is to do tests, and get real evidence.  To be far, several tests will need to be done.  It will take some time and some work, but the difference is worth knowing about.

There is much much more to say on this topic area, but enough for today.

 Your comments and observations, please.  

Agile Release Planning workshop - Comments

I have many comments to add to the blog, and many topics to discuss.  Let me start with this one.

Last week we had another Agile Release Planning workshop, in Montreal.  (We do one almost every week.)  The workshop is mainly about taking a real set of work (about 6 months of work for one team), and doing real agile release planning.  This is explained in this blog, and at LeanAgileTraining.com (for any specific workshop), and in my book, Joe's Agile Release Planning.

First, most everyone in the group said 'this is the best' or 'this is when it all came together'.  These are frequent comments from the workshop.

Today, let me talk specifically about Serge and his team, which were all from one company.

They took a brand new set of work, which the company has to do soon, and planned it out.

It was so good that Serge took the release planning information (the product backlog, etc, etc), back to the office.

***

They had two issues that struck me.

One:

They are used to developing the backlog in isolation from the Team, by one or two people.

And, to be fair, many of the people in the workshop were not members of what will be the real team.  Still, I think Serge started to see the value of creating the backlog with a Team.  And the team members did too.

And, later, all the individual detailed work could be done.  Research, cross-checking, etc.  So, the difference from what they used to do (have 2-3 'experts' develop the initial product backlog)....the difference ends up being mainly timing.  Now, the Team (with business stakeholders) does it first, and then the individuals can work on it later and make it better.

Why is this better?  Well, several reasons.  I will list two.

1. It greatly reduces the time before we start 'real work'...I'll call that real work 'writing code'.  And with code we can get feedback from 'the real world.'  So, instead of waiting 3 weeks before we can 'start', we can start the next day (well, honestly, usually it takes a few days more).

2. It enables the Team to have their hands in at 'the creation.'  This has two benefits.  One, it gets their creativity involved.  One consequence is that some of the 'missing' stories are identified now.  Two, it changes their motivation.  They no longer get the mushroom treatment.  And they start to see, by working on it, how all the pieces fit together.

The only downside is, this is a change, and to some degree some people may resist, and you have to explain it to them.  But I have always gotten people to do it fairly well the first time.  (Can you alone get them to do it the first time?  Maybe not.)

Two:

How to do Priority Poker?

In this case, the company has few 'business stakeholders' who will show up.  It is a small company, and one of the people who 'should' show up and do this is the CEO.  But he does not have the time.  And there is a sales person who also has some good insights, but who might take the Team in 'his own direction' ... we will say it that way.

And, Serge is right -- this is not ideal.  And, getting really good business stakeholders is hard and has problems.  Almost always, at least to some degree.

Still, we can get the ...well, best people we can get.  And then use the poker cards to vote, and then average the answers.  And put business value points on each story.

And, as is always the case, we will feel and in some sense know, that this is not perfect.  Except that, the BVPs are the best guesses by the best people we can get to do this at this time.

And then we can do things to improve the numbers.  Starting the next day, maybe.

One obvious thing in this case: Take the product backlog with the BVPs (business value points) and show them to the CEO, and then get his opinion.  And often he suddenly says something like "wow, I wish I had been there...I want to be there next time....but let's change the BVPs on these 10 stories."  And you realize that for 40 out of 50 stories, the CEO is agreeing we did a good job, and he is 'only' changing 10 of the stories.  And usually by not really that much.

AND...the exercise and the numbers enables the CEO to realize that he should act differently with the Team.  The information becomes evidence that causes him to change his behavior.

Well, I do not know that with these numbers and this CEO this has happened this time, but I do know that it can.  With the right CEO and with the right advocate.  (It may be that this CEO really really is too busy, for example.)

***

I hope these key observations (for me) also lead to useful thoughts and actions for you.

If you have questions or comments, please speak up (below or via email).

Scaling Workshop - New thoughts

David Muldoon and I just had a new Scaling workshop in Montreal.  Two days talking about scaling, and solving problems.

One quick observation

Scaling is ugly.  That is, scaling is always a compromise.

We talked about the ideal state; what would we ideally want things to be like.  One way of expressing part of that: We want to have 5 teams (of 7 people each) work together in such a way that 'everyone knows everything', and we are completely in sync from top to bottom.  And we want this communication to happen at zero cost and in zero time.  We want this because we want to work fast and effectively and with high quality. ...Of course, this ideal state could never exist, but at least we see the trade-offs more clearly.

First, we hope we get that in a single Scrum team, and if we play Scrum well, I think we can.  It is hard, but we can, in a pretty reasonable way.  Yes, not at zero cost, but at a very reasonable cost.

But to get this with 36 people (including the Chief Product Owner) is hard.  There is an additional communication overhead, and we almost always start leaving people out of conversations.  In part, because it is so messy to have a conversation (or meeting) with more than 7 people.

What is the overhead to scale?  Well, honestly I have not looked at the data in a while, and I think we need better data, but I think the cost is quite high.  10, 20, maybe 30% of productivity is lost.  Very likely more.  In any case, we have to be honest....with scaling more of the raw energy of the people is dissipated 'into thin air' as we might say.  We have to accept that, but we also want, within reason and in the context of other values too, to minimize that dissipation of energy.

A second thought.

Each scaling situation is different.  I was again struck by this.  Yes, some of the problems are similar from one situation to the next, but the solutions you need to bring are different, at least to some degree.

For example, in one situation, a company is trying to rebuild a large legacy core system (a huge payroll system).  The original system took, they think, 5 years to build with many people.  The problem: How to take 5 teams and rebuild it in 2 years, and deliver it incrementally over those two years (in part, to mitigate the risk of a big bang delivery).

In another situation, the problem was different.  Here we had a growing company that is innovating, and changing.  How do we get evenness of flow so that the 3 'departments' (or areas)....Inception, Build, Transition each have an even amount of work to do.  In such a way that the highest Business Value stuff is delivered quickly to customers, no matter how big each release might be.  By inception, they meant identifying good idea sufficiently to move to Build.  Build meant, in simple terms, coding and testing and getting to a minimum viable product that was done, done, done.  Transition meant taking a (newly built) product and delivering and installing it at many (say 35) customers.

Describing how the solutions for these two situations were different is too much to address today.  But the first thing is to recognize how different the problems are.

A third thought.

Implementation is key.  We must implement scaling iteratively and incrementally.  This was clear to everyone, and clear in all situations.  The full meaning varied, eg, because of the different political situations, from situation to situation, but that we should, indeed must, implement scaling iteratively and incrementally was clear.

Why?  One was the cost and the related approval for each part.  For example, in one situation, it became clear that each of the 5 teams needs a Product Owner and we need a CPO 9chief product owner).  But, they only have one PO now (for 3 teams).  There is no 'open requisition' for 5 new POs.  So, the feasible way to implement this was: add one PO now.  A bit later, get approval for another PO.  And so on.

Another reason.  Whenever you add something to scaling you must get them, and usually to some degree 'all of them', to agree to the change, to change, and then to learn how to use the change effectively.  It is easier for 'all of them' to agree to the changes iteratively and incrementally.  The changes are easier to implement iteratively and incrementally.  And you can manage the process of becoming professional in the use of each change better if each change is fairly small. (There are other factors, depending on the situation, but one of the bigger risks is with a 'big bang' implementation of scaling changes.

A fourth thought.

I continue to learn about scaling.  I think we all do.

Slightly related to this: We have or should have a strong bias toward KISS.  Keep it stupid simple.  Keep it maybe somewhat simpler than it 'needs to be'.  Why? Because we have so much complexity already that we are almost stopped in our tracks, and the more complexity we add to the scaling part, that complexity makes things harder by itself.  What do I mean by harder?  Communication is not as good.  We get confused.  Everyone in the scaled group does not understand how we are scaling well enough.  Hence, the do not use the official scaling effectively, and resort to doing nothing or to doing it in a personal or informal way (which often can run counter to what is happening in official channels).

But back to the learning. Let me give two examples.  My colleague Dave has a bias toward 1 week sprints, and I have a bias toward 2 week Sprints.  Maybe better to say: I think getting most teams to do 1 week sprints well is harder than getting them to do 2 week sprints.  And that 3 or 4 week sprints are only rarely good ideas (ie, useful only in a few situations).

So, that is a small difference between us, and we both knew about it.  I think it arises mainly from different experiences (different specific situations), and that we fundamentally agree on the principles (eg, the value of fast feedback, that one must save one's political capital for the most important changes, etc).

But, even though Dave and I have been talking about scaling frequently for years now, we discovered a new difference in this workshop.

Dave likes to talk about 'grooming' as one meeting, and a big grooming working of many hours, maybe even a whole day in a Sprint.  He has good reasons for this preference.  I like to talk about those activities as 'the red zone' (versus the 'black zone' of doing the 'real work' of ... in very simple terms, coding and testing).  In the red zone we do grooming and we do longer term release plan refactoring.  I like to call all of the red zone 'release plan refactoring and make it clear how connected the 'grooming before the next sprint' and the 'pre-planning' (as people often call it), it directly connected to the black zone, and to the longer term release plan refactoring.  And, for reasons I won't explain fully hear, I therefore do not define the contents of the red zone has strongly in other ways, but do usually propose at least two shorter meetings over a 2 week sprint, one hour each.  So, in simple terms, more meetings but overall less time 'all together'... or at least less time where we 'require' that we be together.

Dave and I had talked about these different views some.  But what became clear is how, for one situation, we were suggesting notably different options for the people to consider in scaling.   And they each had value.  They each made a different compromise about the different things we might try to optimize.  This was very interesting.

One key idea we discussed is the typical pattern of 'group-individual team-group'.  This is of course a typical pattern one find all over the place with scaling.  We need to discuss X at the group level first, then we need to discuss it at the team level to get into the details, then we need to bring back the learnings at the team level, and discuss again at the group level.  Perhaps you follow the idea enough so that, when I use the Yogi Berra quote ('Little things are big.') you see what I mean and why.  (If not, tell me, and I will explain more.)  Sometimes the concept is expressed succinctly in the aphorism (two versions): 'God is in the details" or "the devil is in the details."

Concluding thought

I was very pleased with this 2 day workshop.  The people wanted us to explain scaling, and all the different ideas 'out there' about it.  While of course there are a huge number of ideas out there, and it would take days and days to cover them 'fully', we gave them a decent summary in a time box.

And we talked about specific situations, and specific small patterns that might address those specific problems.  And we talked about the implementation issues for implementing those patterns (eg, the politics of getting approval or buy-in). And to enough detail that I felt they had 'enough' to go do it.  These became not just abstract suggestions, but rather palpable, do-able action items.

So, I felt (and I think the attendees felt) that it was a very successful workshop.  It was fun for me to work with them.