The textbook definition of a Scrum Master is someone who “removes impediments” and facilitates the process for the team.  I suppose from a process perspective the Scrum Master does do management type of work but in general terms the Agile community doesn’t agree that the team’s manager makes a good Scrum Master.    The general thinking is that a manager can circumvent team self-organization and creativity by directing the team and in theory this is fine but in practice it’s just not reality for medium to large sized organizations.

Let’s consider this complex, enterprise organization structure:

(click to enlarge)

This example is loosely based on an enterprise organization I worked with.  A Scrum Master will have extreme difficulty trying to cross the boundaries presented in an enterprise organization.  Removing impediments are going to be extremely challenging, if not impossible, in this type of organization and there are a number of reasons why:

1. Functional Department Objectives: Team members will be taking direction from conflicting objectives.  QA’s mandate may to be to reduce bugs while the PMO’s objective is to get the project out on time and on budget therefore sacrificing quality in the process.
2. Exposing Dysfunction: Managers are happy in their silos, crossing boundaries to remove an impediment can be seen as a threat to the responsible manager.  I encountered a situation where the team I was working in was consistently losing 1 – 2 days of productivity per sprint due to environment problems.  When I began removing this impediment all I did was piss off a lot of people and nothing happened.  They were quite happy with the current state because it was just too hard and expensive to have proper environments.  Even better when I asked “so what do you expect the team to do during these blackout periods?”.  The answer was:  “nothing”.
3. Team member fear: Having multiple managers providing process and direction to the team makes self-organization difficult.  Team members will struggle with the courage to do the right thing over getting into a conflict with their manager.
4. Impediment is technical in nature, control outside scope of department: I personally ran into this quite a bit.  In many cases a back-end system was not available and the organization had a complex support system that seemed to be designed to block all progress by bogging down people in process.  Let’s say the team is working on an application that interfaces with a service layer controlled by IT.  The process dictates a complex ticket system for resolution and escalation requires moving up your silo to the appropriate level, across to the responsible department, down that stack and then back up, across and down.  Sounds confusing doesn’t it?  It is.  This encourages silo-type behaviour, mis-trust and a whole host of other dysfunctional behaviour designed to follow process over getting results.
5. Resistance: I’m not a fan of the term ‘resistance’ personally.  Resistance is simply a symptom covering a reaction to change.  In the diagram above, if there is fear or resistance at any management level (and there usually is), a Scrum Master’s job is all that more difficult as the SM doesn’t have any power or authority to remove impediments.

So what’s the solution?  To be honest, I don’t entirely know.  Creating a matrixed organization where the team reports to the Scrum Master may work.  Firing all the managers and flattening out the organization may work.  Moving from a project-based organization to a product-based organization may work.  Pushing the fluff of “hey, can’t we just all get along and work together” may work (although I doubt it).  It’s probably going to be a bit of all of these actually but hiring Scrum Masters is the wrong first step.

Based on the sessions I attended at Agile Tour Toronto, no one has Enterprise Agile figured out to any degree of certainty and my opinion is that people are focusing on the practices, not changing the system in which those practices are used.

All I’ve figured out so far is that a Scrum Master in a large organization has no power or authority and a smaller sphere of influence to help with change. If you are expecting to hire a bunch of Scrum Masters to make your enterprise Agile, just wire the money you plan to spend on them to any registered charity, it’ll be money much better spent in the end and you’ll get some nice tax breaks.

Let me tell you story about a team I worked on and why we were successful despite the number of constraints on our team:

1. Extremely strong Product Owner: she knew the domain, she knew the politics, she knew was battles to fight and which ones to let go.  If our team was technically dependent on a group outside our influence and they wouldn’t help, she’d drop the backlog item and promote something else.  Then she was manage the stakeholders appropriately.
2. Achiever-level(1) Team Members:  We have 1 tester and 1 programmer who were very much achievers that were intrinsically motivated to learn about Agile and technical practices and were genuinely interested int he work they were doing.    They inspired the team and were greatly responsible for creating a high performing team.
3. Catalyst(1) Scrum Master: I don’t like taking any credit for the success, the team did the work, however I did get some great feedback that I was able to provide a team system that allowed them to step up and take risks.  I listened to their concerns, I had one-on-one sessions with them, I gave them timely feedback and I was a pain in the ass when I felt I needed to be a pain in ass.
4. The Perfect Storm: Having said all of that, this team had something special.  There was a great mix of personalities, domain and technical knowledge/skills and we had a very open and honest relationship across the board.

While this team and project was successful, as a whole, the adoption was not. (sidebar: it’s been 18 months since the adoption started and it’s just now hitting critical mass)  The point is, organizations often think hiring a bunch of Scrum Masters to make their projects ‘Agile’ and yet don’t consider the system is not designed to support Agile processes.  I spent most of my time at this organization acting as an Agile project manager all the while kicking up to influence change.   This organization perceived Scrum Masters as just Agile project managers and didn’t understand that in order to be successful with Agile, the system must change.

Before you decide you need a Scrum Master, take a step back and understand your system and context.  A Scrum Master that reports to a manager who may end up looking incompetent from the visibility Scrum will create, isn’t likely to help remove impediments.  There’s a reason why courage is a value of Scrum, without it you’re just left with a dysfunctional Agile process instead of a dysfunctional…whatever it was before.

(1) For more information about developmental models, check out Michael Spayd’s article on Agile leadership with references to Leadership Agility by Bill Joiner.

It’s MUCH more important for teams to understand how to work in an Agile process BEFORE they adopt a tool.  Agile teams that are co-located use sticky notes, spreadsheets and whiteboards to manage their work and it is extremely effective.

What this poll isn’t saying providing is context around who is voting and what their environment is.   A decision maker who knows nothing about about Agile is probably more inclined to pick the tool first and base that decision on the most well known or “enterprise” version of the software that they hear other people use.

Remember, we value individuals and interactions OVER processes and tools so figure out what Agile is and learn the process BEFORE you worry about the tool.

What tool would I recommend?  Well, first I would recommend sticky notes, whiteboards and spreadsheets/wiki until the team learns and really gets what Agile is.  Once they know what being Agile is all about and management “gets” what it means, I would recommend either JIRA, Rally or Scrumworks.  Rally is GREAT for enterprises, JIRA is great if you want a tool that can do it all and Scrumworks is really lightweight and simple.

Here’s the poll is you’d like to see the results.

Recommended Agile Project Management Software | Agile Software Development Made Easy!.

Our iterations are 1 week (we’re re-implementing Scrum, so the shorter the better to allow the problems to surface quickly) so we use these guidelines for time-boxing:

• sprint backlog: 1.5 hours – this is where the team commits to their work and break stories into tasks.
• development activities:  1 hour -  If you’re stuck after an hour, ask a team member
• ‘stop the line’ discussions:  15 minutes -if a team members runs into a roadblock, the whole team stops and a quick 15 minute brainstorm session happens.  All potential solutions are written on the whiteboard and then the line resumes work.

The biggest question the team always has around time-boxing is “what happens if the meeting is over and we haven’t finished our task breakout?”  The answer is simple:  The meeting is over.  If you didn’t meet your goal, schedule another discussion or in this case, when it comes time to work on that story, time-box the task breakout to 15 minutes.

The lesson is, by time-boxing your efforts you force yourself into focusing on the issue or discussion at hand.  It’s tempting to allow a couple more minutes here and a couple more minutes there, but avoid the temptation.  The team will get into a rhythm pretty quickly and be much more efficient at time-boxing.

The key meaning I picked up from that is your tools and processes should be valuable enough to support your Scrum process and not hinder it by introducing more overhead than necessary.

JIRA: We’ve been using JIRA for just over a month now for all customer projects, internal projects and customer support. We’re using a ‘virtual agile wall’ plug-in that makes it easy to see what’s in progress, not started or done in a sprint. We’re also using a pretty cool plug-in from Green Pepper software that allows for easy manipulation of backlog items as well as creation of burndown charts.

One of my favourite features is being able to easily print out story cards for our real agile wall so we get the benefit of tracking and the visuals in our work area. We’re also using Atlassian’s wiki (Confluence) which will be the topic of a future post.

It also can integrate with various IDE’s as well as SVN so you can associate defects (which there should be none, right?) and backlog items with your code.

Card Meeting: It’s not ready for prime-time yet, but this is a wicked electronic version of the Agile wall.

Scrumworks: I have limited experience with this one, but it’s a really quick and easy tool to manage your product backlog. If you just need a simple tool to manage your software development projects, this is a great one. It also integrates with JIRA and Bugzilla but the biggest benefit over JIRA is that it has out-of-the-box metrics like ROI and business value calculations.

I’ll be posting more information with details around our JIRA implementation in the future.