Why Managers Should Crave Agile

One idea in the Agile community is that with Agile, we do not need managers anymore.

For those of us who have had Dilbert managers, this is a happy thought.

But actually, a silly thought.  Because even pretty good managers add value and we should have good managers.  And ‘good’ means not only morally sound, decent, reasonable, and fairly logical, but also well-trained and capable.  It is my view that many managers in the US have not been trained well.  (This ‘bad training’ presumably happens around the world.)

So, we need good managers if Agile or Scrum is to be successful.  And it is generally true that the Agile/Scrum community does not devote enough attention to what ‘good managers’ would be with agile or scrum.

But first, we must address the issue of why a manager should want agile or scrum.

Who is good at explaining this?…please raise your hands!

Here are some reasons managers should crave agile.

1. It gives more to the customers.

The customers get more product, the product has higher value, higher quality, delivered sooner, and at lower cost.

It is not at all clear that your company can prove these things, mainly because the current ways of measuring these things are poor or non-existent.  But where we can measure these things, and where we do not have a dysfunctional Team, we see these results.  To a high level.

All managers should care about the customers, and should consider this a big win.

2. Finally it gives us a handle on whether we are making progress.

Before, people were working hard.  But how would a manager ever know if any real forward progress was happening or not?

In the old way, we had ‘paper’ deliverables.  Not helpful at all, really.  And we had conformance to schedule (and budget).  Again, not very helpful.  And we had an ‘instinct.’  Again, often not helpful.

If you had a really good group that you knew and trusted, and they had succeeded with the previous work, and they were a small group and the effort was fairly small, and the new work was pretty darn similar, and if the first release was fairly soon, then you started to believe them when they said they had made some good progress.  But notice how many conditions I had to add.  Lots.

In Scrum, with the definition of done, and velocity, we can get a real sense of how much progress we are making toward a release.  That sense of progress is quite real.  It is subject to two things, at least in terms of hitting the original date:
(a) that relatively few ‘new’ features will be identified later that ‘must’ go in the next release, and
(b) the team has a strong DOD and are not hiding things.

3. Agile and Scrum do not require you to micro-manage.

Is there a single manager who truly enjoys micro-managing?

Surely some appear to.

I think all reasonable managers hate it.

4. Agile and Scrum provide substantial help in motivating the Team.

Getting a team motivated is hard.

In fact, I think the experts say that you cannot really motivate anyone.  You can, as a manager, do only two things: (a) remove de-motivators,  (b) explain why someone might want to be motivated.  It is essentially a choice by the employee, based on an interior value system.

How does agile and Scrum help?  Well, in many ways.

The Team has a clear mission that important people think is important.  The Team is building the highest BV stuff first (as a general rule), and that is visible.  The Team is in it together, and the sense of camaraderie engenders fun and a sense of commitment to each other.

The Team only commits to one sprint at a time; this is much less forbidding.  The Team sees in the Sprint Review each Sprint whether it is making progress, and gets immediate feedback.  And mostly makes forward progress.  This fills their sense of hope about the release.  And the Team devotes some time each Sprint to getting better (eg, the Retrospective).

In Daniel Pink’s terms, Scrum helps Autonomy, Mastery, and Purpose to grow.

5. You only have to manage the Team.

You do not have to manage 7 individuals, you only have to manage the 1 Team.

And, to a large degree, the Team manages itself.

This does not mean you have nothing to do.  Far from it.  But it does simplify the ‘noise and confusion’ that so many managers feel.  No longer do you have to manage 7 people (or 7 x 5 people).  Now you can manage just 1 team (or 5 teams).  A far simpler thing to manage.

Because this is simpler, you are able to focus more, and should achieve more success.

Now, it is true that managing a team is somewhat different than managing individuals.  And it requires different techniques and approaches.

6. Better cycles of control.

Every sprint you have a new ‘cycle of control.’  This is far better than in the old way.

In the old way, people would show you ‘stuff’ that was hard to evaluate, and say ‘look at how much I or we have done.’  And you had to struggle to assess it.

Now, at the beginning of the Sprint, the Team promises 8 small stories (features), and at the end of 2 weeks (or whatever the sprint length is), they have to show the working product.  And get feedback from people who represent the customer.  (I call those people business stakeholders, and they might include real customers.)

So, what is happening (or not happening), or whether we made progress (or had lack of progress) is much more transparent.

And this is simple: It is easier to manage if you can see what you are talking about.

In addition, the cycle of review is a nice period, every 2 weeks.  All the hourly daily ups and downs go away, and you see what the team can do in a relatively short cycle, such as 2 weeks.  That cycle is also not very long and it allows mid-course corrections usually numerous times over an initiative or product life (which might include multiple releases).

7. Impediments.

In Scrum, the Team identifies for you its biggest impediments.  So, with that hard part done, you get clear about how to help.  It is not perfect, but it gives them responsibility and gets them engaged.  It changes the dynamic between workers and managers.

Also, the Team quickly understands the ‘social contract.’  You, the SM and the firm will help them with the top impediment.  This is good. At the same time, despite nothing being done (now) on the next 19 of the top 20 impediments, the Team is still expected to get serious work done.  Because the SM and you are helping with the impediments, and that is more visible, they waste less time just complaining.  And spend more time on useful work.

In some sense, most of your work now is fixing the top impediment (today).

8. Happiness

In general, Scrum work is more successful and people enjoy it more. (This assumes several things. They are really doing Scrum, rather than something they just call Scrum, and  doing it somewhat professionally.)

Once the Team jells, and you see them having more fun, and you see them being more successful, it starts a virtuous cycle. And it is fun to be part of it.

***

I have only explained why someone should want to be a manager with agile/scrum.  That was the purpose of this blog post.  I have not explained how to do that job (although I did give a few hints).  A subject for another blog post.

Your comments are welcome.

 

« « EPMO for a Smaller Company || Impediments – Charlotte Course July 2014 » »