From the Mist

Everyone in the agile community will understand this (I expect 😉).

If we talk about “managing” we agilists understand that the team “manages” itself. That difference with “traditional” projects, managed by a project leader or -manager, is constantly emphasised by scrum pundits.

This article is not for that in-crowd but for people attempting to understand the agile approach to projects. There is no difference in opinion as to why we have projects: we want to deliver maximum value to the business in a controlled environment. The boundary conditions are also not debated: we are limited in resources, usually categorised as money and time. A big difference however is already present in the definition of “value”.

In “traditional” approaches rigorous attempts are made to define “value”, almost to mathematical precision. Only after we achieve shared (that is, shared between the business and the delivery vehicle: the project) understanding of what is meant by “value” can we start work on delivering that value.

For an agile project we choose a different approach, one that is believed to be overall much more effective in two aspects:

• total value delivered over the same time
• the quality of that value in terms of maintainability, usability (or fit-for-purpose) and other non-functional quality attributes

In agile projects we may have a shared understanding of “value” between business and project, but that understanding is much more vague and only present as a general sketch. It is only through time, as the project progresses, that parts of that functionality are made explicit. Those parts are always “small”, that is: small enough to be completed in one sprint, usually a two-week time period. And these bite-sized portions of functionality are placed in what is called the sprint-backlog.

The difference with the more traditional approach becomes clearer: the total value delivered by the project team becomes clearer and fully defined over a longer period of time. However, the premisse is that this total value is more than can possibly be delivered otherwise. In fact the general view is that this value is much more.

However, there is another important difference: the entire process of defining portions of value is done by the team itself. In close cooperation with the product owner, a person responsible for the business value by being the voice of the business, the team commits itself to delivering those portions within one sprint, and the team learns to do so without failure: within the time frame of the sprint, usually two weeks. Plus the team delivers the functionality in a complete state: including testing and deployment, using what is called continuous integration.

What is the role of the scrum master in all this? The scrum master might be seen as the closest equivalent of the project manager. If the team is doing all the work, including most of what a traditional project manager would do (such as planning and reporting), what does the scrum master do? And how does she do this different from a project manager?

The main quality of a good scrum master is that she is not “steering” the team, not doing any planning, and not “pressing” the team when it seems the plan is under siege. The plan is what the team itself manages. Processes installed in the way the team works make sure that the team is able to steer itself more than sufficiently. The short feedback cycles help with that. The product owner is part of the team, the delivery cycles are instantaneous, multiple times a day, and the backlog items the team tackles are small enough.

The main responsibility of the scrum master is making sure that the team can maintain the high pace, that all conditions are optimal, and that the team is sufficiently “isolated” from the politics of the enterprise (funnelled through the product owner who is the link with the actual users of the functionality that is being realised). This facilitating mindset is sufficiently different from the traditional one that it needs extra attention. For some it may be difficult and even impossible to make this transition. For others it may feel like a relief.

I have found that this transition can be eased by another transition that many enterprises are moving through: a change in leadership styles in general. Modern management theories resound with facilitating leadership, flat hierarchies and holocracy. The reason is clear: productivity is higher, work satisfaction is higher, costs are lower. If your organisation is going through a similar transition you will find that it helps tremendously in your transition from a project manager to a scrum master.