IMG_0365 6

My Team is Special – Do We Need a Fulltime ScrumMaster?

May 26, 20162 min

No…as long as the Team meets ALL of the following three preconditions listed below, a full-time ScrumMaster is most likely unnecessary.

  1. The Team is learning from their mistakes and refining their performance as they go.
  2. The Team is learning and adapting to the organizational idiosyncrasies, i.e. impediments, over time.
  3. The Team is improving continuously and getting considerably better month after month.

When Teams are at this state, I would say they have achieved a state of high-performance.  If they started in this state, then something like Scrum would not benefit them.  I would suggest letting them do whatever they want because it is clearly working.  If they are not in state of high-performance, Scrum (or any Agile process), might help.

So when do we need a full-time ScrumMaster?  When one, or more, these conditions is present within the Team.

  1. The Team keeps making the same mistakes over and over while product quality stagnates (or degrades).
  2. The Team consistently encounters the same organizational impediments and responds with the same coping strategy with predictable results.
  3. The Team fails to adopt the kaizen mindset and their performance as a group founders.

Working through these issues at the individual, team and organizational levels is a full-time job for most people.  As I have mentioned before, the ScrumMaster is eight roles wrapped in one and it takes time to master them.  Learning these skills is certainly not yet another unpleasant task for an overworked Team member (or the fictitious “Agile” project manager).  Nor can a ScrumMaster work in a different location as the Team.  Addressing the issues listed above takes time, focus and dedication.

Finally, Geoff Watts dedicates an entire chapter in his book, Scrum Mastery: From Good to Great Servant Leadership, on this topic.  In his book, Geoff walks through three common scenarios, Product Owner-ScrumMaster, Team Member-ScrumMaster and one ScrumMaster for multiple teams, talks about the potential conflicts of interests, the benefits (there are actually a few) and the risks.