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.

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?