As a developer I’ve been happy with scrum, but as I’ve been more involved in project management I’ve felt that there is something missing. When I talked to two of our most experienced project managers at Kentor; Susanne Ribbing and Cecilia Andersson I realized that what I was missing was project governance.

Looking thoroughly, it is enough with a single sentence description of a scrum project to identify the need for project governance.

Throughout a number of sprints the team focuses on the most prioritized items from the product backlog to reach the project’s goals

I’ve highlighted a number of terms that are very much treated as predefined constants by the scrum methodology. I think that’s right, because scrum focuses on the developers. Still, those terms need to be defined and that’s what project governance do.

Number of Sprints

The number and length of sprints in a project is dependent on the project’s deadline, the amount of work to be done and the size of the team. To be able to define those, the goals for the project has to defined, the budget has to be set, deadlines for deliveries listed and the available people for the project known .

The goals, budget and deadline should be part of the project definition, which is the first thing produced by the project governance process.

The Team

Having the right team members is a key success factor to any software project including scrum projects. When the project is defined the competence requirements of the team have to be listed. According to scrum the team should be fully cross competence, with anyone in the team able to take on any task in the project.

In reality, that is hardly ever the case and trade-offs must be done. That makes the task of forming the team even more challenging and important. Among all less-than-perfect options, the correct trade-offs have to be done to form the best team possible.

Scrum itself assumes that there already is a team. To acquire the right resources before the project starts is one of the tasks of the project governance. In a busy organization it is important that the project sponsor has enough powers in the organization to ensure availability of key personnel.

The Product Backlog

The product backlog is the requirements specification in a scrum project. It is formed by finding all user stories required to fulfil the project’s goals. I’ll get back to requirements in the next post in this series.

The Project’s Goals

The project’s goals is the reason the project is even started in the first place. Without defined goals, it isn’t a project (although there are many “projects” out there that lack even the basic goal definition).

The goals of the project is the key part of the project definition, which is defined and decided upon within the project governance structure.

Project Governance as the Outer Feedback Loop

A scrum project is iterative, with each sprint being a full turn of the loop.

The project governance is an outer feedback loop, surrounding the scrum loop and providing the boundaries of the scrum project. All the parameters that are taken as predefined constants in the scrum methodology must be set by the project governance process.

Project Organization

With the role of project governance defined it is time to look into the project organization. Scrum in itself has a very flat organization, it’s essentially a team of peers with the scrum master being the spokesperson.

Note the wording spokesperson. The scrum master is not the manager of the team. The scrum master is the team’s representative.

Project Governance Organization

With the scrum master as the team’s spokesperson there should be someone to talk to. That someone is the project manager. The project manager reports to the steering committee.

The steering committee is the core of the project governance process. It consists of the project’s sponsor and other stakeholders. The project manager participates in the steering committee meetings. Project governance models focus on how the large picture of the project is defined. The details of how the goals are reached are deferred to the project manager. That’s where scrum takes over and supplies a model to get the maximum productivity from the development team.

Combining Scrum and Project Governance

Scrum alone cannot handle the full complexity of a project. Project Governance alone won’t deliver anything but meeting minutes.

I’ve been in a project focusing on project governance. It was well defined and all plans and meeting minutes where in order. Technically it was a mess and nobody knew what to do when. At the end we delivered, but the project was very close to complete failure.

I’ve been in a project focusing on scrum. As a developer it was great, but the project failed to meet the goals, failed to keep the budget and failed to meet the deadline.

A successful project requires both project governance and project management. Scrum defines how to do the tactical project management. On top of that a strategic project governance is needed. There exists a number of different project governance models. The restrictions they set on the project management are different, which means that some models fit rather well with scrum and some don’t. If the project steering model (which is usually dictated by some policy) does not allow an agile process, then maybe scrum isn’t right for that project.

As a Developer, Why Should I Care?

I’m a developer too. I prefer to not have to care about project governance, budget, funding and the political issues of a project. I prefer to keep my focus on the development team and ensure that we deliver high quality software.

When project governance works I don’t have to care. I can spend my days coding with the team. The problem is when project governance fails. Failing project governance results in constantly changing requirements, short-sightedness and unrealistic expectations.

As developers I think that it is important that we recognize the signs of failing project governance as it will make the project as a whole fail. Then the blame game starts. The rules of the blame game are simple.

The last one to see the blame game coming loses.

I prefer not being the last one.

This post is part of the Scrum series.

<< Scrum – Nowhere to HideRequirements in Scrum >>