Why managers should crave Agile

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

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

But actually, of course, a silly thought, if we have any good managers in our company today.  And 'good' means not only morally sound, decent, reasonable, and fairly logical, but also well-trained.  It is my view that most managers in the US have not been trained well.

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

But first, again, we must address the issue of why any manager would want agile or scrum.

Who is good at explaining this?...please raise your hands! (Usually few if any hands go up.  Sadly.)

So, here quickly are some reasons managers should crave agile.

1. It gives more to the customers.

The customers get more product, higher value product, higher quality, and sooner. And at lower cost.

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

2. It finally gives us a handle on whether we are making any progress.

Before, the people were working hard.  But how would a manager ever know if any real forward progress was happening or not?  The basic answer was: no clue.

Well, not quite.  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.

With Scrum, with the definition of done, and with 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 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, and (b) explain why someone might want to be motivated.  But you cannot make someone be motivated.  That is essentially a choice or arises 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, immediate feedback.  And mostly 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).

5. You only have to manage the Team.

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 8 people (or 8 x 8 people).  Now you can manage just 1 team (or 8 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.'  And 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 can represent the customer well (I call them business stakeholders, and they might even include some real customers).

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

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

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

7. Impediments

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

Also, the Team quickly understands the 'social contract'.  You and the SM and the firm will help them always with the top impediment, but always despite the next 19 of the top 20 impediments, they are still expected to get serious work done.  They can complain and bitch and moan (as people always do), but some clear rules have been set.  And, generally, 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 impediments.

8. Happiness

In general, Scrum work is more successful and the people doing it enjoy it more. (This assumes several things, but especially that they are really doing Scrum, rather than something they just call Scrum, and that they are 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.  If someone has explained your new job as a manager with an Agile team.

***

To be fair, I have only explained why someone should want to be a manager with agile/scrum.  And 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.