The Management Scrum Team

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

One aspect: Managers can learn best what Scrum is and what agile is by being on a ‘real’ Scrum team.

A more important aspect: Managers can be more effective on a multi-functional Scrum team. (Often.)

***

STOP!  Why am I writing this post?  Well, it is not because I or we have this idea totally figured out.  The main purpose is to get others who have tried this idea, to give me (and you) feedback on their experiences.

Now, knowing the situation better, I hope you and others will provide feedback.

***

What do I mean?  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 miss-understood.  I will explain some of the underlying principles, maybe less than others.

Reminder: Other people with a similar idea or somewhat different will disagree with certain particulars.  USE WITH CAUTION.

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

***

A Team. 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.

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

***

Now we need to distinguish ‘leaders’ from ‘managers’.   Sadly, this really needs to be a long conversation. Let us say these people need to  have real leadership qualities, including setting a compelling vision for the people they work with, being decisive, and the ability to inspire.  In the managing area, they are not ‘command-and-control’, and hopefully well-skilled at being ‘servant leaders’.  Short version of a long topic.

Some people think ‘management’ is a bad term.  I still like Peter Drucker, and I think the word management is abused. It needs to be clarified, but can be useful.  As can similar words, such as manager.  I agree that awhen an organization tends to always say ‘management’ and seldom ‘leadership’, it is a smell…it causes me concern.

***

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

The next thing is to think of them as a Scrum of Scrums, if at all possible.  To me the key idea now is, they 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 of them is reporting into 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’, sometimes phrased as ‘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 is a PO (product owner).  Maybe that is the CEO.  One is a SM (ScrumMaster, the key impediment removing 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…what it ought to include, obviously.  That is, the most important work for the firm.  It might include anything.  It 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’ (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 they can understand ).  Other factors intrude too.

Perhaps I need to say again…. the people in the MST may 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.

With managers, you know, they don’t need any feedback, so maybe the sprints are 3 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 every 2 weeks, or maybe every month.

Agile Release Planning.  This team must do something like this periodically.  Maybe every 3 months, looking forward to the next 6-12 months.  It is complicated, because this team, at a practical level, is often managing multiple ‘releases’ of product.  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 used to call this a release or two) and then the basic work items (stories or smallish epics) to ‘get there’.

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.  Always remember what 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.  Maybe another way of saying this is: ‘Try to do less, and you will accomplish more.”  In agile we also have a similar phrase: “Stop starting, and start finishing.”  Or, put fewer things in motion.  Or minimize WIP.  Say it whichever way you want to….Do it!

Now, the work of the sprint needs to be defined in small ‘stories’.  To me, for two weeks, 8 stories for a team of 7 is reasonably small enough, and maybe 16 stories in a month.

Did I mention that this is and should be a cross-functional and multi-functional team?  The ‘people’ within the MS Team are all about the Team accomplishing the Team goal(s)!  So, we are expecting the people in (parts of) the MST to help each other.  We expect multiple people (parts) to typically work on each story.

We also expect the stories in the sprint (the work of the MST) to be ‘completed’ by the end of the Sprint.  To be ‘working product’ that can at least be ‘inspected’ by someone independent (eg, some independent business stakeholders).  The BSHs could look at it and say ‘this is good; customers are really gonna want this stuff’.  Or, at least, this is the feedback we want at the end of the sprint, on each and every story.

So, each story must be demoed at the end of the Sprint.

Writing small stories that can be demoed is a new art for the MST people.  Well, they can write stories that will never be demoed (Sorry! I mean stories that can be demoed after they have left the company…. Sorry!  I meant stories that can be demoed in 5 years).  Seriously, writing stories that can be completed and demoed in 2 or 4 weeks is hard for them, because they have never done it before.  If you have never done something, it usually feels impossible!  It is not impossible at all, but they will feel like it is.  These are tough guys to coach.

Remember that ‘completed’ means having a good ‘definition of done‘ always includes some ‘verification and validation’ by a competent and independent V&V person (in software, we call this well-tested by a good QA person). This also is trouble for them, since they have never done this before.

Daily Scrums.  Daily.  Any questions?  I mean, seriously, can there be any question?

You will start to hear some really lame excuses.  ‘I have another meeting at that time.’  ‘A customer called.’  ‘The President of the US wants to see me in 5 minutes.’  You can’t make this stuff up.  Honestly, some of these ‘distractions’ are important.  But the root cause is: They do not think the Team is important and they have forgotten how to work as a Team.  And they do not see how the Team is going to help their career.

Jon Defriese thinks this is because the Leader (in our case, the CEO) has not established the right culture.  Often the Leader himself has not dealt with these issues in his or her own head.

In any case: Daily Scrum.  Daily.  Answering the 3 questions.  Slightly rephrased.

• What did I (or my home team) do yesterday that helped the MS Team meet the Sprint Goal?
• What will I (or my home team) do today to help the MS Team meet the Sprint Goal?
• Do I (or my home team) see any impediment(s) that prevents me or the home team from meeting the Sprint Goal (of the MS Team)?

No impediments is almost never a reasonable answer.  (We focus on the most important impediment, of course.)

Also, we want them to tell each other the truth at the Daily Scrums.  (Stop that laughing! We are serious here.)  And not make ‘political’ statements.  And help each other.  (Stop laughing!)

Seriously, it can be tough to coach this team at first.  Often they have totally forgotten how to work together with any team, and especially each other.  Some of you have a better culture, so be mindful when a new person joins the MST, often he or she comes from a company with a very different culture.  Give that person some time and some coaching to adjust.

Sprint Review.  Alright then!  First, the MST has to ‘review’ things over this Sprint.  Blah, blah, blah.  Keep this part short!  These guys are all good talkers.  The BS meters are running high at this point. Watch out.

Quickly, they have to demo the working stories.  Whoa!  (Neither demo nor ‘working’ imply that product must be released every sprint.)

We need good independent ‘business stakeholders’ (BSHs) to be there to give good, independent feedback in what has been accomplished.  We need to know if we have made real progress.  Or, have we just been ‘working hard’ and accomplished nothing?!  Hence, independent feedback.  Feedback that represents the ‘customer’ for each story.  Some stories are ‘product’ for external customers and some stories are ‘product’ for internal customers. And ‘external customers’ much too often these days means ‘the regulators’.

We need people at the demo who can quickly give us feedback that these different customers will like what the MST has finished this sprint. I call these people (BSHs).  Note: your firm may call them lots of things.  Examples: customers, managers, dept heads, SMEs, gurus, wise old heads, customer relationship managers, product managers, etc, etc, etc.

Often the word ‘business stakeholder’ already has a meaning in your firm different than my meaning.  Watch out for that.

And we need the BSHs to give complete, detailed feedback now.  You will not ever get perfect BSHs, but do the best you can.  “The bad news does not get better with age.”

For the MST people, receiving honest feedback can be tough.  They have often not heard that in a good while. All kinds of ‘acting out’ can happen. Some want to ‘shoot the messenger’.  This can be tough on the CEO in at least 3 ways: (a) he or she is getting way more negative feedback than in the past, (b) the direct reports are complaining loudly about the negative feedback they are getting, and (c) the CEO can see that the ‘team’ culture that had been ‘talked about’ for ages does not really exist in they way they had hoped.  This can be tough to swallow.

If there is not much negative feedback, there are two possible reasons.  (a) Everyone is Steve Jobs (or pick another business icon).  Unlikely. (b) People are lying or don’t know how to give feedback.  Often because we picked patsies as the BSHs (and deep-down knew they would give only ‘sweet’ feedback).

Get good and honest BSHs. Insist on the truth.  Remind people that the bad news is the good news.  Because “the bad news doesn’t get better with age.”  Meaning: now that we know it, we’re gonna fix it now, before it becomes more expensive to fix.

Be patient.  “Little things are big.”  And step by step they can all accept that they are imperfect, and improve. Be firm. Be kind. Be honest. Be patient.

Well, a bit more honesty, at some point the CEO is very likely to see that someone ‘needs a promotion to another company’.  The CEO again needs to be patient. These people are good people in various ways.  And the company’s culture (or someone’s culture) has miss-trained them for many years now.  So, it will take more than 2 sprints for all the dysfunctions to come out and for all the re-training to occur.  So, give people a reasonable chance to adjust.  At some point, someone is likely to be ‘at the far end of the scale’ and you have to give them a ‘promotion to another company’.  (Often we say “It’s not you; it’s me.”  I say this only partly to add a bit of levity.)  And it is tough, but it is also the best thing for that person at that point.

Retrospective.  Again, telling the truth here can be difficult.

We discuss the good and the bad.  We identify the biggest impediment for the MST itself.  And we start to fix it.  As examples, the MST might:

1. devise a solution together
2. plan the execution of the solution
3. build a business case (is it clear that benefits are much higher than the costs)

The business case might go to the CEO or even the Board for a decision.  Often it simply enables the team to work through the information and convince themselves of the best solution.  Often, also, the MST starts the business case, and someone else (the SM?) refines it, improves it, fleshes it out, completes it later.

Who ‘fixes’ the impediments?  Well, it depends.  The SM, the MS Team, or people outside the MS Team.  Depends on several factors.

The key thing is that the Retrospective enables them to get better each Sprint. And in a bigger way than the SM working in isolation, or from identifying the (usually smaller) day-to-day impediments in the Daily Scrum meetings.

***

How much difference could an MST make?

Hard to say.  We do not have enough experience in enough situations to know well.

My experience suggests that in about 2 sprints, the MST is working at ‘normal’ level.  Maybe 3 sprints.  Typically.  But the problem is you had no ‘before’ metrics on the ‘velocity’ of the MST.  So, there is nothing to compare the new Scrum velocity to.

The good news is you now have a metric for the productivity of the MS Team.  They may not estimate the ‘story points’ well yet.  But they are learning.

Usually you find that ‘the velocity is lower than desired’.  Is that really a surprise?  (CEO, you did know that already.)

Now you have an approach to getting better as a Team and for voiding your weaknesses and drawing on your strengths.

The difference can be huge.  If people engage, if you allow yourself to see the truth, and the courage to take reasonable action.

***

One key issue.  I think it is typical to find that the people you have in the ‘management team’ are not the right balance of people in the MST.  The MST must be balanced against the vision and the items in the PB.  Often you see an imbalance.

Thus, you often need to move some of these people outside the MST, and probably add some other ‘skill-sets’ to the MST (new people).

This is a feature, not a bug.  Meaning: seeing what kinds of people you really need in the MST is a big help.

***

Those are my simplified and initial ideas on an MST.

I hope my humor about the problems of life and the problems we often have being managers was taken the right way. Manager work is hard, and being a manager is hard.  I do have sympathy, despite my sometimes sarcastic tone.

One could cry about the situation, cry at the measureless waste in the lives of the managers and the people they manage, and the impact on the customers.  Or one could laugh. I choose to laugh.

This problem of measureless waste and ‘not good enough yet’ is true for all of us.  It is sad and we can be sarcastic.  Just to be sarcastic is not good enough.  We must act to improve things, as best we know how.

In this vein, one must have sympathy for managers.  In my opinion, they are usually not trained well to be managers. In fact, they are generally miss-trained (trained wrongly).  In the Peter Principle (they rise to their level of incompetence) is too true.  And their ‘boss’ is too…hmmm….lacks the courage to fix it when the Peter Principle occurs. These are good people, some of our best usually, but badly trained and often badly positioned.  To the degree we can fix this (and I think we can, at least some) it can make for a big improvement.

***

Please give your feedback and suggestions.

 

« « Changing the culture through invitation and engagement || Question: Automate Testing! » »