Habits of a Successful Scrum Manager -- Part 1

A couple of posts back I posted my personal definition of what I believe makes a good Manager within the Scrum Framework.  I'll repeat it:

A leader who creates and maintains an environment that emphasizes trust, personal development and transparency while protecting the team from influences that would disrupt the Sprint -- including himself.

Starting with this post, I'll share some tools that I use achieve that goal.

Today, we'll look at the One-On-One or O³.

The One-On-One is a technique taught to me by one of my former managers who, in turn, learned it from the Manager Tools guys over at http://www.manager-tools.com/.  They have a number of podcasts on this topic, the first of which can be found here.

The One-On-One is an opportunity to invest in your employees as individuals.  It requires time and preparation to be done right, but it is the single most powerful tool I know of for getting the most and best out of your direct reports.

Again, Manager Tools is the canonical reference on the topic, so I'll just outline the process here.

The One-On-One is a somewhat informal half-hour meeting with each of your direct reports, scheduled at a regular interval and time, preferably weekly.  The meeting is divided into three ten-minute sections.

During the first section, the employee can talk about anything that is on his or her mind.   It doesn't have to be work related, though in the earlier sessions it typically will be.

During the second section, the Manager shares observations, instruction, corrective actions, etc.  Most of the items that a Manager discusses are items that were collected over the week that didn't require immediate action.  Collecting those items together allows them to be discussed in a comfortable setting and without interrupting normal work flow or causing Context-Shifting for the employee.  As anyone working with Software Engineers should know, Context-Shifting is a major productivity blocker.  Of course, there are often things that need to be discussed now, but most can wait for up to a week.

The last ten-minute section is devoted to the future: your employee's self-development, promotion plan and the achievement of established objectives.  This section serves as a constant reminder to the employee (and the Manager) that growth should be on-going and it keeps the employee's objectives in front of them.

Many Managers, after hearing about this, will immediately argue "I don't have time to spend five hours a week talking with my direct reports!"  The truth is that you don't have the time not to!  What you learn from your employees during an O³ will help you better understand how your teams work and what problems need to be solved.  Things come out in an O³ that, for some odd reason, never make it into the Daily Stand-Up.  And the O³ is the primary tool for building trust with your direct reports -- assuming you aren't otherwise doing things that would undermine that trust.

Initially, it's an awkward meeting.  The best thing you can do is expect it to be awkward, tell your employees that it could be awkward and then do it anyway.  After a few sessions, the walls will drop and the awkwardness will go away.

My current Scrum Team not only expects their weekly One-On-Ones to happen -- they look forward to them!  As an example, a couple of weeks ago, one of my Software Engineers, who was having a difficult week, told me "I can't wait for our One-on-One -- I've been saving up for it."  He then waved a sheet of paper with a list of items on it.

If you aren't doing One-On-Ones, I strongly advise that you listen to the Manager Tools podcasts on the subject.  They've seen dramatic changes using this single tool -- and so have I.

Scrum Glossary Added

I've added a Scrum Glossary to the site.  It's something I've been planning to add from the beginning, but didn't have time to get started until now.

Some of you may have noticed that there is some inappropriate capitalization in this blog.  This is intentional and should be considered a "domain thing".   Within the domain of this blog, certain terms will (or at least should) be capitalized that are defined in the Scrum Glossary.  I will do my best to link the first use of any of these terms in a post to the Glossary and, over the coming week or so, will add links to the existing posts.

Please use the comment tool below to let me know if this is useful or if anything in the Glossary needs refinement.

The Scrum Manager

One of the lesser-discussed roles in the Scrum universe is that of the Scrum Manager.  This can be a Software Development Manager, (who supervises Software Engineers and Quality Assurance personnel), a Software Engineering Manager or a Quality Assurance Manager.

The reason this role is not discussed often is because Managers are Chickens -- people who are involved in the process of delivering software, but who are not making the personal commitment to a Sprint's completion.  Scrum literature doesn't tend to focus on the Chickens.

While many Managers believe that they should be considered members of the Scrum Team and treated as Pigs, their job role disqualifies them: their presence on the Team would invalidate the Principle of Self-Organization.

That's one of the reasons I started this blog -- to talk about the role of Managers in Scrum.

So where do Managers fit into the Scrum framework?  Explicitly, we don't, because Scrum is intentionally "incomplete" or under-defined, both to emphasize the parts of the framework that are defined and to remind us that Scrum is still an Agile process and requires customization on how the remainder of the structure gets built.

So the formal definition of Scrum appears to leave Managers out of the picture.  That doesn't mean we have no role in Scrum, it only means that Scrum doesn't define it.

I won't call it a series, but for the next several weeks, the bulk of the posts I'll be making will be related to how I see my role as Software Development Manager within the Scrum framework.  Think of this as an introductory post.

I'll be fleshing this out with specific practices over the next few weeks, but for now, here is the core of what I believe makes a good Scrum Manager: a leader who creates and maintains an environment that emphasizes trust, personal development and transparency while protecting the team from influences that would disrupt the Sprint -- including himself.

Weekly Story Sizing

The standard Scrum framework prescribes a Release Planning ceremony with a recommended time box of four hours to two days.  And this ceremony, when performed properly, works as one of the major columns in the Scrum architecture.

The problem for many teams is that it's hard to keep the attention of a team for two days on a single task -- and it's often difficult to schedule a quarterly two-day meeting.  This varies from team-to-team and company to company.  Some can facilitate the traditional Release Planning time box easily, where others find it much more difficult.  And as a result, unfortunately, many teams drop this very important structural element.

One of the groups I worked with was experiencing that pain, and was heading in the same direction of just dropping the ceremony.  I proposed we keep the ceremony but look for ways to make it work.

Those of you who are familiar with it, know that the great majority of the time spent in Release Planning is spent in Story Sizing.  For a typical team, a two-day Release Planning meeting is comprised of an hour and a half of presentations by the Product Owner with team and stakeholder input -- followed by over fourteen hours of Story Sizing.

My plan was to separate Story Sizing into a separate ceremony, leaving the rest of the Release Planning agenda intact.  This change allowed us to still "do Scrum" with only the timing and frequency of the Story Sizing task altered from the original framework.

Coincidentally, about two months after we successfully separated Story Sizing from Release Planning, I found a couple of blog posts from Scrum Masters who had come up with almost identical answers to the problem.  And about six months later, a Scrum Extension was published that documented the variation as well.

Here's what we do:

The Product Owner, who is also responsible for the Release Planning Ceremony, schedules a weekly Story Sizing meeting that lasts exactly one hour.  For our group, one hour a week was sufficient to keep our Backlog maintained and the relatively short time period helped focus the team on quick, from-the-gut sizing.

During the meeting, the Product Owner presents the highest-priority story in the Backlog that has no size to the team.  There is a brief discussion of the story and any refinements that might need to be made to it to make it sizable.  The team then plays a round of Planning Poker to determine the size of the item.  This process is repeated with the next-highest un-sized items in the Backlog and continues until we run out of stories or run out of time.

This has worked very well for teams I've worked with, and it has some nice advantages in that new stories that need to be brought into an on-going release don't require a special meeting in order to get sized -- they get sized as a result of on-going process and are normally ready before the team schedules them into a sprint.

I would note that teams starting Scrum should not try this first!  Always run the framework in its entirety and get some experience with it before seeking alternatives.

Also, this meeting is not the same as Backlog Grooming.  That is an additional process that is often employed by Scrum teams, but it is not the same as Weekly Story Sizing.

The ScrumMaster Manager

One of the most undesirable, but often implemented roles found in organizations is the ScrumMaster Manager.  It's usually the result of companies believing that they can't afford to have an independent ScrumMaster role and interpreting the role as a supervisory position.  It's also sometimes just the result of having only a limited number of staff available combined with a strong desire to implement Scrum.

In my case, it was the latter.

Wearing these two hats is very difficult, especially since it's hard for your team members to distinguish between the Manager and the ScrumMaster -- and for the Manager to know that he needs to shut up and be a ScrumMaster.  Over the past four years where I've had the combined role -- and believe me, I've tried hard to rid myself of it -- I've had to develop a set of skills that let the ScrumMaster clearly shine through when the Manager needed to take a back seat.

It's not a perfect marriage, and, quite honestly, it's one that should always be looking for a divorce.

I've been able to make it work, to a degree -- I'll never say it really worked -- by creating an environment of trust not only between my team members, but between each individual team member and me.  The most valuable tool for doing that has been my weekly one-on-one meetings with each team member.

That level of trust is what has made it possible for me to still act as ScrumMaster during team retrospectives.  But there again, it's been a hard role for me.  My natural bent as a Manager is to contribute and steer the meeting that I am officiating.  But as the ScrumMaster, my role should be more in line with a Master of Ceremonies -- keeping the team on the agenda, but not steering the direction of the conversation.

Even though I've done it, and with a significant margin of success, I think the blended role of ScrumMaster and Manager is a Bad Thing.  It's another one of those Agile Smells to be avoided.

Why do I mention this now?  I just read a good article on Len Lagestee's blog called "A Managers' Guide to Attending Agile Team Events".  In it he tells Managers "Don't attend [Sprint Retrospectives], ever."  I really wanted to kick at the goads and say "but... but.. but...I've made it work!"  My experience is the exception but I also know that my blended role has interfered with the retrospectives, though not as drastically as it could have.  Even so, in my remaining time at my current blended role, I plan to step away from the retrospectives.  My team is certainly mature enough in Scrum to do it on their own, and has in the past when I was the SM for multiple teams running simultaneous Retrospectives.  Len's advice is a good wake-up call -- and advice that I would have given to anyone else... just not to myself.  Sigh.  Sometimes you really can't see the forest for the trees.

Once again, it's time for me to Be Brave and Do What's Right.

Do you need to be brave as well?

Scrum Time Boxes Visualized

For a couple of years now, I've used a diagram created in an Excel spreadsheet to explain to new team members how the various Scrum time boxes interact.  Here's a screenshot (click to enlarge it):

The columns in the SPRINT portion of the diagram represent work days.  It should be noted that a Scrum work day doesn't necessarily start in the morning -- it starts with the Scrum.

Feel free to use this image in your team training.

If you don't recognize the "Story Sizing" ceremony, it's something we do a bit differently from traditional Scrum, but that has been adopted by many organizations.  We came into it organically before I saw mention of it in other Scrum literature.  Perhaps that will be the topic of a future Scrum Now!

Don't be afraid to make course corrections

About two years ago, I made a change to our Daily Scrum.  Instead of having each person answer the Three Questions*, I had someone volunteer each day to M.C. the Stand-up and call off the stories that were currently in-progress.  Each person who had worked on the story since the last Scrum then answered the Three Questions in relation to the current story.

This was a Scrum Extension** that was proposed sometime back called the "Feature-focused Daily Scrum" and it seemed like a good idea for mature Scrum teams.  And the truth of it was that for well over a year, this "advanced" format worked very well.

Recently, though, I'd noticed that I was getting less and less input from some of my team members under this format.  Our Scrum was starting to feel stale.  On top of that, the team dynamics had changed significantly and I had some new people who were getting their first real exposure to Scrum.

It was time for a change.

In our Sprint Retrospective I announced that we would be going back to the classic Scrum format where each person answers the Three Questions for all of the work they did since the last Scrum.  This was greeted with some minor support from my developers and, oddly, disdain by my QA personnel.

But this was a Scrum Master decision, not a team decision -- that's the nature of some procedural things in Scrum -- and I asked the team to try the classic format for a Sprint.

And it worked.

Everyone is contributing again and I'm getting more interaction than I got before.  Oddly, the perception of the team is that they are interacting less under the original format, even though the meetings are running about 2-3 minutes longer.  We discussed the change after the trial period at the next retrospective and, for the most part there was enthusiasm for the change.

Scrum requires that you and your teams be brave.  You don't bully, you don't command, but you often have to be brave -- even if it means admitting you were wrong or that the environment has changed and left you behind.  That's Agile.

-------------------
* Three Questions: "What have you done since the last Scrum?" "What will you do today?"  "What roadblocks are in your way?"

** Scrum Extensions are a now-maligned idea where Scrum.Org was hosting moderated white-papers on extending Scrum.  This practice has been discontinued in recognition that Scrum should be intentionally simple and incomplete -- a framework that teams fill in with the processes that work for them.