In my time working with agile, I’ve heard ScrumMasters described as many things:
- ScrumMasters are secretaries to the development team, doing the things the developers don’t have time for
- ScrumMasters are Project Managers
- ScrumMasters act between the team and the Product Owner
- ScrumMasters are an arbiter
- ScrumMasters are responsible for chasing customers
How do you know you’ve got a sticky-note on your back marked ‘Kick-me’ without someone pointing it out (or stumbling across a mirror)? Interactions between team members are similar, and according to Deming’s statement, cannot be understood from inside the team.
A ScrumMaster is like a football coach, standing on the side-lines during the game. A football coach doesn’t play a position but they are constantly looking at how the team are interacting with each other. They know if the defensive line is being held too high and how the team aren’t working together to achieve a common vision. After the game the coach helps the team look at their performance for strengths and weaknesses, they’ll identify actions for potential changes and implement them incrementally to avoid boiling frog syndrome. Although a football team may be able to play 1 or 2 games without a coach, other teams may eventually overtake them in ability and effectiveness. Does this sound familiar?
Describing what a ScrumMaster does every day is hard to describe because every team is different. As I’ve changed from team to team over the years my activities and levels of involvement vary depending on what constraintis holding the team back from increasing their effectiveness. This may be anything, from the obvious impediments like the team not chasing feedback from a Product Owner/Customer, right through to the team feeling demotivated when senior management impose a well-meant but miscalculated delivery of the latest process initiative. In Agile Development, we’ve moved away from requirements documents to value people over processes. We know the value of a powerful vision over detailed requirements when developing software. Why should our jobs be any different? I can’t remember the last time a job description actually described what I did every day. Instead of a Job Description why not buy into a Job Vision? A powerful and ambitious statement that inspires us to do our job well?
As ScrumMaster I am striving to make myself redundant.
Yes, I really mean it. In my opinion, a ScrumMaster or Agile Coach for a team should be striving to put themselves out of work. You’ll never get there of course but that doesn’t make it any less important to try. We should be identifying constraints and impediments to the team becoming self-organising (not necessarily self-directing – future blog post on this one perhaps?). This doesn’t mean chasing the Product Owner/Customer or writing code for them when the team are busy, why are they so busy? Why couldn’t they write the code themselves? As soon as you put yourself in the system you lose the ability to understand the system.
So what’s the Vision for your role in the company? I’d be especially interested to hear ideas on vision statements for Product Owners.