After attending a Certified Scrum Master Training session, the discussion about the difference between the Scrum Master and a “traditional” project manager raged long with many good arguments. The part that most people from the “old school” had problems with was the fact that the Scrum Master is without authority! The only way a Scrum Master can force a project result is through good coaching and to make sure all impediments are removed so the team has nowhere to hide. The rest is up to the team (and some praying maybe?). But what kind of project managers fit into the Scrum Master role?

Lets do a quick review of the Scrum Masters responsiblity, before we go through the different types of Scrum Masters.

The Scrum Masters responsibility

  1. Facilitate the Scrum Process (keep daily Scrum meetings, make sure the product owner prioritize the back-log, and the development team estimates, holds sprint reviews, sprint planning and so on)
  2. Facilitate the project towards the organization (make sure the development team is protected from outside forces, that organization rules and policy is upheld with the project)
  3. Work as a coach with the development team
  4. Coordinate Product owner / development team interaction (both when to connect, and when to stay away from each other)

The administrative project manager:

This is the traditional project manager, a person educated in business and organization. The traditional tools are clear defined processes, action plans, milestones / deadlines and so forth. The administrative project manager can still be an effective scrum master, but first of all he/she must accept the loss of power of delegation and giving the customer full power over the backlog. Still, efficient organization skills are important in terms of handling the environment “outside” the team sphere: setting up meetings, make sure the infrastructure is in place, and protecting the team from outside noise and hindrance. The administrative project manager will most likely have more of a “how are things going?” approach to the team by attending Scrum meetings.

A conflict scene might erupt when the team realize they’re falling back on their own commitment and need to remove features from the Sprint back-log. This might cause frustration for the project manager who cannot delegate nor impose extra hours on the team. Only “encourage” to work harder / smarter / better / produce desired results. Hence, the secret skill of “project management manipulation”.

The Technical Scrum Master

This is very common in technical environments. A technical lead accepts the role as a Scrum Master. However, this might be devastating since the Scrum Master, per definition, is not a developer and cannot commit to any tasks in the backlog. Any development work a Scrum Master might do would be “hidden work”, and that road might be dangerous. A good solution would be the Technical Scrum Master to act as a coach: helping team members with tasks by sitting with them, helping them coming up with a good solution. This might be an alternative to the imposing of Pair Programming. However, the Technical Scrum Master must make sure not to commit to the task AND be able to prioritize which feature and developer to work with at any given time.

The danger erupts when the sprints lags behind and the Technical Scrum Master realize the team is spending much more time per task than he would, hence giving in to temptation and starts to work with the tasks directly in order to get “done”. This would be an act of “trespassing” into the domain of the development team.

The Business Scrum Master

This might be a former salesperson, manager or stakeholder that takes the role as a Scrum Master, often because he / she has a “ownership” to the business about to the implemented. The Business Scrum Master might be a projects worst enemy: the customers / product owners might be overridden by the decisions from the Business Scrum Master, and the team might be imposed unrealistic time boxing deadlines with a huge backlog they have problems committing to.

However, the Business Scrum Master might be a very efficient Scrum Master as well, but he / she needs to put aside personal ties to the project and accept that the product owner owns the product, and the team owns the implementation. However, the Business Scrum Master can use the skill of “management manipulation” and knowledge on both the product owner and the team in order to make sure the back-log is prioritized in an optimized (business value / development cost) form. The team will get the best possible coaching help when the Business Scrum Master knows the domain very well, understands the difference in cost between solution options, and gives “helpful advices” to the team to make them solve the domain logic implementation in the best way possible.

So to conclude how to be a successful Scrum Master based on your background:

  • Organizing Scrum Master: Facilitate the project infrastructure as well as possible, make sure the team has the best environment to work in. Lend an ear to customer / team in order to help them think / realize, even though the details might not be understood.
  • Technical Scrum Master: Be a coach by asking the right questions to the team so they realize the better solutions. Be part of technical discussions and solution, giving your advice in the best form possible, but allow the team to make the decision.
  • Business Scrum Master: Facilitate so the Product Owner is well connected with the development team. Use management manipulation or “coaching” on the team and product owner put the project on an optimized (business value / development cost) path.