I blogged a while ago on the concept of a “ScrumMaster Manifesto” which I created in the confines of my own head, whilst sitting in a lonely train carriage home from London. I figured this would be a great summary of the values and principles of what being a ScrumMaster is all about. As a tribute to the 10-year old Agile Manifesto I tailored the style and structure to be more ScrumMaster focussed. The response from ScrumMasters, trainers and coaches with whom I shared the idea all gave positive feedback. The blog was posted, I hoped others would read it and take some value from it.
That concept was taken further in an Advanced ScrumMaster training class I ran with Geoff Watts, by asking the class attendees to re-create four “value statements” from a mix of their own perceptions and agreements of the ScrumMaster role. It worked well and we decided it was as exercise worth exploring again.
The idea lay dormant during the summer months, and only re-emerged in my mind when I noticed a trend in the training classes I was running and when I was coaching new ScrumMasters. When I asked the question, “Is the ScrumMaster a full-time position on the Scrum team?” the vast majority of people would answer “No.” My concern was that those ScrumMasters could already be compromising their teams (and organisations) chances of truly embracing Scrum, by not seeing the ScrumMaster as a dedicated person on the Scrum team. This is a trend that continued to grow over time and encouraged me to submit a session on this topic to the Scrum Alliance Global Gathering in London this month (I will be writing a separate blog post on the session content for those who didn’t attend later this month.)
This seemed like a great opportunity to air my concern with other practicing ScrumMasters, and canvass their opinions at the event by asking them for their participation in re-creating a simple guide for new and inspiring ScrumMasters who might be unknowingly compromising the role, or be unaware of how they can improve. This artefact wouldn’t be created by me, or a group of sage-like Scrum evangelists. It would be formed from the collective thought of those on the ground, with real-time experience of their own role, as they are best placed to know what that role entails. The ScrumMaster community should be the creators and owners of a ScrumMaster manifesto. At the gathering, I chose to apply some consensus techniques to trying to ensure each of those who attended my session at the gathering could feel they have contributed to the output in some way.
Forming the principles
Each of the 40-50 people who attended the session were given a blank index card and asked to write down a three word (logical) phrase which they feel summarises what being a ScrumMaster is all about. All of those people they played “35” prioritisation (a technique I picked up from Jimi Fosdick, Scrum Alliance Global Gathering Amsterdam 2010). The principles with the highest scores floated to the top, and the twelve highest-ranking principles were selected.
Peer consensus on ScrumMaster definition in 15 words or less
I asked each attendee to write a 15-word or less definition of a ScrumMaster in isolation. Then highlight their favourite three words, write those words onto three different post-its and placed them in the middle of the table. The table then created a new definition using the individual’s favourite words, adding in new words to form a grammatically correct statement.
Aggregated priorities of “least ScrumMaster aware” activities
As preparation for this session at the gathering, I created a survey for active ScrumMasters. One of those questions was based around “which activities should a ScrumMaster focus on”. I selected the ten least popular choices from that survey, and asked each of the tables to order that list into the activities they feel ScrumMasters neglect or forget about the most. I aggregated the results across all the tables into one prioritised list.
Capturing the output
One of the common failings of so many of the sessions I have attended at conferences and gathering in the past, is the lack visibility those sessions get beyond the session itself and those who attended. My pledge to the group that formed was to post all of their efforts into a single online webpage that would be visible to all. Using the power of social media I would make it easy for people to “follow” the webpage and share it with anyone who would take value from it. I didn’t want the first version to be fixed in stone forever. My vision was to iterate the manifesto content from training and coaching other ScrumMasters based on how the role is changing as the Scrum community grows and hopefully teams become more agile over time.
Whilst the vast majority of public opinion has been positive (and I thank people for that) there have been some negative responses to the creation of this artefact. From discussions with those objectors, it mainly seems to be around one of two misunderstandings.
Firstly, a lot of confusion and doubt has come from use of the word “manifesto”. People seem to think this is an attempt to “standardise” a ScrumMaster’s role by decreeing laws and rules under which every ScrumMaster must abide. Not so. This is only intended to be a mirror for a ScrumMaster to look at themselves. It’s a way that ScrumMasters can help each other get better. The word “manifesto” itself seems to have irritated a minor group of agilistas, but this is not intended to replace or compete against any other “manifesto”. The original agile manifesto has stood the test of time, and people (including me) still use it today to help new teams understand the values and principles behind doing their work differently. I wanted to use a proven formula to help a community improve itself. It disappoints me slightly that people may discard an entire artefact’s value from the use of a single word.
Secondly, the other common response I had from launching this can be summarised as “don’t tell your Grandmother how to suck eggs”, or “you are preaching to the converted”. There is a belief among some, that a great agile team shouldn’t need a ScrumMaster as the team just “gets it”. And I agree. In a beautifully agile world where every team delivers what the customer wants in every sprint, all in perfect harmony. And if this were the case, every team would be self-organising and collaborating with customers, with the ScrumMaster becoming almost indistinguishable from anyone else.
My opinion and experience would suggest that as an industry we are not as agile as we think we are. Teams are not as self-organising as they think they are. ScrumMasters are not as great as they think they are. A great ScrumMaster will constantly be looking for ways to improve the team’s productivity, and the focus of the role subtly changes to more of a coaching one in a more established Scrum team. That subtle feedback and improvement can still benefit even in the most experienced agile teams.
But those seasoned ScrumMasters are not the primary focus for creating this manifesto. There are a larger number of ScrumMasters out there still stuck in a waterfall culture, with a history of regimented project management, micro managing Scrum teams into submission. These are the ScrumMasters I was hoping this manifesto would affect and influence the most. And I think if those people have read one manifesto, there is a good chance they might read another one.