I am regularly asked for help from people with a distress call along the lines of, ” I am a Scrum Master now, apparently, what do I need to do?” This is roughly my response:
There are some teams that have chosen to adopt Scrum, and I wish them the best, although they probably won’t need my well-wishes. Merely the fact that they have CHOSEN to try scrum exposes all manner of values and behaviours. To start they clearly have a degree of empowerment over their ways of working, and they also likely have a sense of commitment and passion about what they do, enough to try something to improve their situation. If they have chosen Scrum, it is likely that they have considered their context and their situation and believe that either it is a good fit, or that they can make some internal changes to enable it to be a good fit. Either way they will either look to recruit a Scrum Master or one of the team will look to adopt the role with a view to, if it works, make it a permanent full time function.
There are some teams in an even better situation, they are formed as Scrum teams in a context that is suitable, often referred to as “Agile by birth” and will often be supported by dedicated Scrum Masters – I had the good fortune to work in a team like this – the most rewarding experience of my career.
In my experience though, this is not the norm, due to their size many, many software delivery professionals find themselves inside large corporations where the freedom of working practices are more than slightly constrained. Often there is a degree of close interaction between teams that rewards aligned working practices within a value stream (for adaptive organisations – or skill based departments for others). Now in this context the choice to use Scrum hasn’t really been taken by the team, it has been suggested, encouraged, expected, requested or mandated depending on the culture of control within the organisation.
This brings interesting and typically unconsidered challenges, especially for the unfortunate scrum master who has been unwittingly appointed. In the type of organisation that has imposed Agile there is likely to be the expectation that the Scrum Master will impose the practices of Scrum. Typically this is in service of a wider Agile transformation imposition, and we are now looking at command and control from the top, through the departmental level and down to each and every team member. Attempting to achieve Agile values through rigidity is unlikely to be successful. People choose to do things, people choose to change or adopt new things and whilst they may do this in light of new information, it remains THEIR decision. You can’t forcibly change someone, attempting to forcibly impose working practices is deeply destructive, the team need to choose to adopt them. Here is the heart of the challenge of the expected / imposed scrum, because the team didn’t actually CHOOSE Scrum, it becomes very hard to hold people to its practices.
My suggestion in this situation is simply, not to. I think it is reasonable to have someone explain what Scrum is, and how it is different to their current operation, but then shift the focus of this coerced Scrum Master from working within Scrum guidelines to working within “Team Agreed Practices”. The role of the Scrum Master then becomes an enabler of continuous improvement rather than some Agile process police.
The role of a Scrum Master that was appointed, not aspired to, in a team that has Scrum requested of it, rather than chosen by it, is this:
To be the voice of conscience, to hold the team to account against how the team has chosen to operate; and to facilitate the regular discussions of how the team should operate.
When we start to talk about how things SHOULD be, then you’ll trigger questions like:
- Why are we doing stuff?
- What is going on?
- How can we be better?
With a little support the teams will start to increase transparency, value delivery starts to become more important. The team will reflect on what they are doing and look to change, to inspect and adapt. The team will slowly build up to something pretty close to Scrum, and if they don’t it will ultimately be because they have found something better than Scrum given their unique context.
Remember that Agile is not the goal, Agile and all the practices and terminology that come with it are just other people’s ideas that helped them be better. Try to enable your scrum masters to be “betterment people”, rather than “enforcers of a process I didn’t choose”. This approach will encourage your people to be proactive about improvement, rather than instruments of repressive control.
Comments are welcomed – even criticism. It is only through feedback that we learn.
Follow me on twitter: @philagiledesign
or reach me on LinkedIn here
philagiledesign 