The Specific Reasons Why a Scrum Master is Not a Project Manager

 

Companies new to Agile often fall into the crucial trap of mistaking the Scrum Master role with the role of a Project Manager. This often leads towards a dramatic detriment in productivity, since the Scrum Master role requires a very specific skillset which is entirely different from the more generalist role of a Project Manager.

 

This article will point out the main differences between those roles and help you to chose the right person for both positions to make your project a success.

 

The Classical Role of Project Management

 

The Project Manager leads the project on a day-to-day basis, controls, communicates and provides direction. His role can be summarizes into the four following categories:

 

#1: Manage Processes: The Project Manager gets the project “up and running”, selects the team, establishes milestones and project schedules with the team and leads the project on a daily basis

 

#2: Track Process: The Project Manager monitors the timely achievement of milestones, tracks team costs and investments, overseas the documentation and provides direction

 

#3: Facilitate Cross-Functional Collaboration: The Project Manager Identifies linkages between sub-projects and coordinates cross-team cooperation

#4: Communication: The coordination of key project-related messaging to internal and external audiences, as well as communicating project information to the line management are Project Management roles

The Specific Role of the Scrum Master

The Scrum Master on the other hand does not manage the team on a daily basis. His role is more of a coaching and a facilitation role regarding Scrum, which makes him the link between the project team and the client.

Scrum Masters cooperate closely with the Executive Sponsor. They ensure that the project complies with Scrum and that all processes are implemented properly. The role can be summarized into the 3 following categories:

#1: Overcome Stumbling Blocks: The Scrum Master steers the development, resolves problems and involves the right people in the development process

#2: Oversee the Groundwork: The Scrum Master keeps two eyes on user experience, functionality issues and feedback from all stakeholders

#3: Provide Guidance: Helping to facilitate changes and assist in the planning process while providing overall Scrum guidance is a crucial function of the Scrum Master

 

There you have the main difference:

The Scrum Master is there to help and assist with highly specific technical knowledge but not to manage the workflow.

Summary: The Scrum Master is not a Project Manager

 

The role of the Scrum Master is more specific and technical than the more general role of a Project Manager. Both are important. Confusing these roles however almost certainly leads towards failure in the execution of Agile – and towards huge losses.

 

Make sure you have these important positions covered with the right people.

Programme Management

I’m currently working with a multinational organisation to build out the strategy to empower the business to take advantage of new regulations coming in as a result of de-regulation in Europe (Hmmm). We are working on a Programme to implement the strategy to deal with these changes in our marketplace.

 

For me Programmes are not just a collection of related projects it’s significantly more than that, programmes are about strategy and projects are about tactics.  Programme management is overseeing the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisations strategic objectives.

 

Programmes deal with outcomes and projects deal with outputs (From MSP®). We do use Programme Management to coordinate related projects but that’s down the road and its not the primary reason to kick off a programme. The programme starts by taking the business strategy, targets, initiatives and policies and defining the vision, scope and priority of the outputs that will deliver the outcome.

How do we approach this.

Develop the Vision, this is the postcard from the future of state of the business. It is used as the focus for the programme and like any vision it should be compelling and clear. Failure to get a good visions statement weaken the programme, therefore time should be spent in developing it. Re-design the vision in the middle of the programme may cause confusion.

 

From a Vision we can tease out a target operating model for the future, the practices and process that will be need to be in place to deliver the vision.  The target operating model is the blueprint of the future and the programme manager has the responsibility to ensure that the blueprint is delivered.

 

The POTI model is useful in developing out the blueprint, for each element of the blueprint used it to analyse the processed, organisation change, technology and information required for the future

 

 Detail
Vision StatementWe want to enter new emerging market ABC
                PProcesses, Business Models of operations and functions including operating costs and performance levels
                OOrganizational structure, staffing levels, roles, skills required, organizational culture, supply chain and style
                TTechnology, buildings, IT Systems and tools, equipment, machinery and accommodation
                IInformation and data required for future operations

 

From defining these process, organisational changes, technology and Information the projects to deliver them become apparent.

The above is simplified method bases on MSP®. More details on the methodology is available with templates examples. Drop me a line to chat through it.

Focus Courage Respect Commitment Openness

Scrum Values apply to all the team not just the Scrum Master or Product Owner and they are Values that can be effectively applied to Agile and traditional waterfall methods. When moving from waterfall to Agile there values are the first thing for the Scrum Master to get the agile team to buy into.

 

Focus – Team focus and Sprint goals are important responsibilities for the Scrum Master. The Scrum Master should remove impediments from the Team and protect the Scrum team members from external influence.

 

The Product Owner and Scrum Master should be responsible for ensuring a well groomed backlog which is both estimated and ordered and the team should be fully be focused on delivering the work committed to in the sprints.

 

Courage – The Team member must have the courage to speak out and ensure that their contribution is heard but with an openness other. The. Scrum Master needs to have the courage to negotiate with stakeholders and the Product Owner when it’s right to do so!

 

Whilst at the same time the Scrum team needs the courage to commit to as much work as possible within the Sprint whilst respecting the definition of done.

 

Openness – This is a core Scrum Value that makes Agile so much more effective than traditional management.

 

The Back log should be fully qualified and visible so that everyone is aware of what work is up and coming. The retrospective must be fully open with problems openly discussed

 

Commitment – The Scrum team commits to what they will complete each sprint. They also commit to how the work will be ‘done’ and to meet the Definition of Done.

 

The Team commits to doing whatever is collectively necessary in order to meet their goals.  The wider organisation also commits to support the scrum team and to respect the values of Agile.

 

Respect –This is perhaps one of the important values in Agile… And sadly one that I often observe is not followed! The Product Owner gets to dictate what work gets done and in what sequence – And it’s the responsibility of the Scrum team to respect those decisions. However The Product Owner must trust and respect the team to decide how they will accomplish this and respect the team when they push back or if they believe the Product Owner is encouraging them to overcommit. The Scrum Master should be aware that they are not management but the servant leader responsible for ensuring that the Scrum team is able to run at maximum efficiency and to coach stakeholders, Product Owner and the Scrum team on all things agile!

 

At Althris Project Management Training we have some tool and Agile games to help get the team focused on these values. For further reading I suggest you look to see what Ken Schwaber says about the Scrum Framework for software development.

When interest levels of the project sponsors drop, it’s bad news for everyone. Bad for the business that has invested resources. Bad for the project manager and team who find themselves without an essential source of support. And bad for the end-user who may then get a product or service that doesn’t meet requirements or simply dosn’t get done.

Perhaps the wrong sponsor was chosen by the business and they were never interested in the first place. In any event is is critical to have and maintain project sponsor engagement, there is no formal methodology for doing so. Some project mangers are afraid to manage upward or don’t quite know how. Teamwork between the project sponsor and project manager is the way to create really effective projects.

Here’s a few suggestions

  • Common sense – Make sure you think your tactics through
  • Understand your sponsors perspective, agenda and how it does or dosn’t align with the project goals
  • Seek to understand why disengagement has set in, workload, disapproval of change, people issues
  • Communicate – as a project manager you are a senior staff member and tackling the head-on may be the way, Let the sponsor know you need the support

If you still cant get a re-engagement don’t undermine the sponsor but perhaps seek out other stakeholders that can provide the necessary support in the organisation. This can be often be done with the permission and support of the main sponsor. Particularly if the disengagement has happened as a result of workload.

If you are still stuck and the project effectiveness is being undermined you will need to go all the way to the top.