Management Scrum Team – Part 1

This is an important idea that more and more people are talking about.

One reason: Managers need to learn about Scrum. They can take a course, but they also need the ‘reality’ of being in a real Scrum Team. (Real does not have to mean a software dev team.)

Another important reason: Managers can be more effective in a multi-functional Scrum Team. Often, we need to help them be more effective.

Now, the purpose of this post is to learn. Start to define this idea; kick it around, and see how it might be improved or be more useful. This idea may not be totally figured out. In fact, my main purpose is for others who have tried this idea or something similar, to give me (and you) feedback on their experiences.

Now, knowing our situation better, I hope you will provide feedback.

___________________________________

What do I mean by a Management Scrum Team?

A stable team of managers working toward one vision, and working ‘one set of work’ and ‘one product’ (even if broadly defined).

Below I will make my comments specific and practical, in case you want to try them. Ideas expressed in a practical way are less likely to be misunderstood, and I will explain some of the underlying principles.

Reminder: Other people have a similar but different idea. Who is right? (Too early to tell.)

USE WITH CAUTION.

Also, I am making a number of assumptions, and have not expressed all of them. Use caution, and I am not suggesting the ideas below will work, or should work, in all situations.

___________________________________

A team. Again, we want to call it a Management Scrum Team or MST.

Get a bunch of managers at almost any reasonable level. They of course need to be similar in some way, and have a reason to work together, a common purpose or goal.

We need about seven people. A team too large does not work well, and a team too small is ineffective usually.

Next, form them into a real, stable, Scrum Team.

___________________________________

Now, distinguish ‘leaders’ from ‘managers.’ Sadly, this distinction needs to be a long conversation. For now, a leader needs leadership qualities, including setting a compelling vision for the people they work with, be decisive and have the ability to inspire. In the managing area, they are not ‘command-and-control’ at least, and hopefully well-skilled at being a ‘servant leader.’ (The short version of a long topic.)

Some people think ‘management’ is a bad term. I like Peter Drucker, and I think the word management is abused and needs to be clarified, but can be useful, as well as manager. I agree that when an organization tends to say ‘management’ and seldom ‘leadership,’ it is a smell — it causes me concern.

____________________________________

OK. Maybe we have the CEO and six key managers (leaders, gurus, coaches, call-them-what-you-will).

The next thing is to think of them as a Scrum Team. Probably each person is representing other ‘doers’ who are not in this team.  So, the team is (mostly) reporting on the work done by others. To me the key idea now is: The people in the team are not doing ‘real work’ (as they always say) but rather are reporting back what their ‘home’ team has done. (The home team may or may not be a Scrum Team.)  It is probably OK if one or two ‘real work’ people are in the MST directly. That is, they are doing real work themselves.

What’s next?

Notice that I have not (yet) used the word scaling. Partly because, few people agree on what the word means.

And because I am not assuming that the org has or has not already done ‘team-level Scrum,’ which might be called ‘Scrum with real people.’ To me, we can start doing Scrum first with the MST.

Next?

Back to the composition of the MST. Well, obviously one person is a PO (product owner). Maybe that is the CEO. One is a SM (ScrumMaster, the key impediment removal driver for the MST itself). The rest are the ‘doers’ (well, they represent the doers in each home team).

We have a Product Backlog. It is prioritized mainly by Business Value.

It includes, at this level, all the most important work for the firm. It might include any type of work (or it likely represents a wide variety of needs). The composition depends on many factors, including the nature of the firm’s business.

It includes ‘real work,’ innovation (if you think of that as different than real work), impediments from the Scrum Teams or the departments/divisions, Agile adoption issues, cultural change, etc. Whatever work needs to be done. Maybe some of the work is easy and some of the work is hard. Maybe some work is ‘always there’ or recurring in some sense and some work is ‘temporary.’

Again, the work is prioritized mainly by Business Value or, more accurately, bang for the buck, as best understood — other factors intrude, too.

Perhaps I need to say again…. The people in the MST maybe do not do the work with their own bare hands. They may ‘represent’ other people or teams that are actually doing the work. In fact, that is much more likely the case.

Sprints. The MST has Sprints. The shorter the Sprint, the better, usually. I am thinking two-week Sprints.

With managers, you know, they don’t need any feedback, so maybe the Sprints are three months long. Oh, sorry, I was being sarcastic. With manager work, getting good feedback and fast feedback is even more necessary than with other work. “The bad news does not get better with age.”  So, seriously, try to get the Sprints to be two weeks, or maybe a month.

Agile Release Planning. This MST team must do something like what I call ‘Agile Release Planning’ periodically. Maybe every three months, looking forward for the next six to 12 months. It is complicated, because this team, at a practical level, is often managing multiple ‘releases’ of different products. And they are managing BAU as well (business as usual), which is often a zillion widgets or tickets of CSRs or whatever. Generically, they define goals and metrics to achieve in some relatively short time frame (in software dev, we call this a release or two or six over, say, six months). Then they define the basic work items (stories or smallish epics) to ‘get there;’ delivered.

_________________________________

This has to be some combination of top down and bottom up.  That is, one would expect ‘new ideas’ to have ‘gone to the top’ (no matter where the new idea originated), to be considered and prioritized. And one would expect lots of basic ‘necessary’ and continuing work to have been identified (or re-estimated) at a lower level and submitted to the top for ‘overall’ consideration. The CEO often has little choice on the ‘necessary’ or ‘previously approved’ work, but at least in terms of allocating people and resources, the ‘management team’ needs to put it in the picture.

Obviously, this is adaptive planning. Enough said for now.

Sprint Planning. The MST needs to set a Sprint Goal. At least a somewhat coherent Sprint Goal. As Yogi Berra said: “You have to be very careful if you don’t know where you’re going, because you might not get there.” In other words, a typical failing is to ‘focus on everything,’ which is the same as saying ‘focus on nothing.’ Which means that nothing gets done.

This is a classic problem. It affects individuals. It affects Scrum Teams. And it is probably even harder for the MST. So, get some focus each Sprint. “Try to do less, and you will accomplish more.” In Agile we  have a similar phrase: “Stop starting, and start finishing.” Or, put fewer things in motion. Or minimize WIP. Say it whichever way you want… Do it!

___________________________________

End of Part 1.  Three more ‘parts’ to follow.

Part 1, Part 2, Part 3, Part 4

« « Honesty and Scrum || Management Scrum Team – Part 2 » »