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.

1. what did I do yesterday?
2. what am I planning on doing today?
3. what’s in my way?

I’m amazed at all the grumbling I hear from new teams I work with about these evil Agile people are forcing you to stand-up when Ken’s book clearly says you don’t have to stand!  Actually, one of the team members actually threw that in my face so I re-iterated the purpose of the stand-up to them.

Bob Hartman tweeted me with a great idea a while back.  Why not let them sit?  Simply plot along how much time they take to do the standup when sitting vs standing.  The team admitted to me that when I wasn’t there they would sit down so I didn’t want to be forcing them to do something they were against.  Isn’t it a bit more Agile to let the team do what works for them as opposed to being worried about breaking the golden rule of standing up?

Here’s the observations after a few iterations of comparing sitting vs standing.  To put some context around it, our team isn’t completely co-located.  We’re all in the same general area and a few sit next to each other but since we’re in a huge environment we agreed (as a team!) to do our standups in a neutral area so we don’t bug the people around us.  Oddly enough there is a waterfall in the building, that’s where we do our standups.

When standing:

• people drift further apart as it goes on
• body language is terrible, they seem to be there out of habit, but they do still get value out of it without really realizing it
• they address me, the coach and temporary Scrum Master
• averaging about 12 – 15 minutes
• each person answers their 3 questions (except for blocks, I usually just recognize them and so do other team members)
• seems very regimented in nature and not natural

When sitting

• they sit closer together
• body language is MUCH better, they actually lean in towards each other
• they address EACH OTHER.  Sometimes they look at me but they are more team focused for some reason
• averaging 15 – 20 minutes, still followed by follow-up conversations
• they do get sidetracked by trying to address blocks and I have to reign them in more often to stay on track

So far the experiment is showing me that they are getting much more value out of sitting than standing.  Sure they are taking a few minutes longer and I have to pull them back on track sometimes, but they are much more engaged and working together while sitting.

I’m sure part of what helps with sitting is that we have to walk to another part of the building as we don’t have a dedicated team room yet so I’ll follow-up with another post once we have that environment.

Do your teams sit?  Would love to hear your stories.

There are a few problems with this but the main ones are:

1. product team isn’t exposed to REAL client feedback/issues
2. Implementation team gets bogged down with client requests
3. less team-wide knowledge sharing (read: specialists)

We had been operating in 2 week sprints and when you are supporting existing clients you can’t really tell them it’ll take 2 – 4 weeks for any request they submit.  As a result we re-prioritze often (which is good) but it’s definitly not in the spirit of sticking to Scrum (which is bad).

So here we are at day 1 and the plan is:

1. 15 minute planning session
2. 1 ‘daily’ standup (5 minutes at ‘mid-sprint’)
3. 15 minute retrospective and sprint review

This is going to be tough on everyone and there was some resistance to trying this method from the team but after a discussion they were willing to give it a shot which is great.  At first the phrase “it’s impossible to do anything in 1 day” was thrown around quite a bit but I think they will realize very quickly there isn’t much of  difference between 1 day sprints and 2 week sprints, you simply scale everything down to fit.

I expect some interesting results and would love to hear from others who have tried this method.  Leave me a comment!

Stories need to be dissected right about the time the sprint is supposed to start so the story is small, testable and can fit into the sprint.  That’s the easy part, in theory.  What about when a user story has clear business value, everybody gets it, the story is BIG (in terms of points) and nobody can figure out how to break it down?

Here’s  a technique we tried today and it seems to have been successful based on the output.  We set a timeboxed discussion to 15 minutes and the architect of the group took the lead and wrote what the main criteria of the solution was.  In this case it was building a new component that would interface with our product so technically it was a ‘build from the ground up’ type of thing requiring some architectural discussion.

The component needed to be:

• scalable so it would work in our environment (load balanced, redundant etc)
• restartable without manual intervention (watchdog approach)
• secure
• testable

There were a few other buckets, but that’s not so much important right now.  The architect drew 3 feasible technical solutions on the whiteboard pretty quickly and everybody got the gist of it.  Since we had 3 solutions, each criteria specified was ranked by each team member with a 1, 2 or 3 with a 3 representing that a certain solution was the best for each particular category.  Here’s a rough idea how the scores came out.

What was interesting is that some team members ranked certain solutions as a zero in a particular category.   This chart tells us that solution 3 is probably not an option.  Although we didn’t do this due to a time crunch, you could get creative and apply a weighting to the categories.

Solution 1 is still on top, however if the weighting for Category 1 and Category 2 are switched, the numbers are much closer for Solution 1 and Solution 2.

While not completely fool proof, this simple ‘Kano’ type of analysis (sans the questions) typically used for product development can come in handy in a pinch to quickly get to an answer without long and drawn out (read: exhausting and frustrating) conversations.