Every member of a Scrum Team should be a Project Manager
Except maybe the Scrum Master
I worked with a team once where we did short projects of 2 to 6 months. At first, the plans for these projects were made for us by sales and project managers. Most of our clients insisted on an old-fashioned plan with deadlines, fixed scope and fixed prices. We worked with Scrum but Agile was not such a big thing back then, so most of our clients were rather sceptical about it.
We were forced to compromise, presenting the client with a typical waterfall planning but working on the project using Scrum. To bridge this gap, we looked for new ways to communicate with the client. And we continuously did our best to help them understand the Agile way of working, guided by the Agile Manifesto:
Customer collaboration over contract negotiation
As we matured as a Scrum Team, driven by the need for some kind of whole-project preparation, we learned as a team how to iteratively prepare a project and involve the client throughout. As a result, we gradually took over more and more of the planning, until the point where sales and management realised we were so much better at it that they left the whole thing to us.
Project preparation
To be able to have some idea of our capacity as a team we worked hard to make sense of it over time. Velocity is such a brilliant tool for this. I spent hours trying to find reliable ways of visualising our velocity over time,especially the variations and how to smooth them out.
The graph below is an example. The thick green line is a rolling average with all kinds of corrections. It worked brilliantly in relieving stress both in our clients as well as management, as here they could finally see a velocity that looked kind of reliable.
Mike Cohn has a similar tool that is very easy to use on his website.
At the same time, we learned how to quickly break up a project into parts and estimate them roughly. We got to the point that we could literally prepare a rough backlog with estimates and a rough prioritisation in a matter of hours.
The estimates were always a challenge because it was just impossible to make our clients understand what the word “estimate” actually means.We were finally able to resolve this with a technique I read about in “Agile Estimating and Planning”, by Mike Cohn. The idea is to make a second estimate for each project part, an estimate of the worst-case scenario, which is then used to calculate an error margin. A bit like a standard deviation.
Combining our velocity calculations with the project estimate and its error margin we were able to effectively visualise the project planning and its uncertainty. Basically, it's the good oldcone of uncertaintybut applied to the project in a way that we gradually learned to make more and more understandable for the client. That is why we for example used a burnup chart as shown in de graph below, because clients instinctively like things that go up.
With this approach we were able to change the conversation with the client into one which was all about choice:
invest more in research and design, hoping to reduce the error margin to a more acceptable level,
accept the error margin as a calculated risk, and get started with the project to resolve the risks more effectively.
The combination of transparency and choice created a lot of trust and goodwill, often leading to improved collaboration with the client. Having a choice meant a need for information which resulted in motivated and involved clients. At the same time, it made it natural to share other decisions with the client, such as deciding on priorities during the project.
Impact on the Team
The interesting side-effect of all of this was that because the whole team was involved in preparing the project, everyone had a clear and shared idea of the whole project from the start. Suddenly, managing the backlog became a team endeavour, in which the Product Owner acted mainly as a mediator between the team and the client.
If you want some more detail about our approach regarding refinement, check out this article:
The Challenge of Backlog Refinement
My experiences with backlog refinement and how, together with my teams, we made it work for us.
Usually, Scrum Teams focus on the sprint, while the Product Owner sticks to the backlog. But in our team, our shared vision meant that we all participated in the bigger picture. This resulted in better estimates and better choices regarding priorities, mainly because the technical knowledge of the developers was directly considered from the beginning.
Also, Sprint Goals became the reference for our discussions, instead of Sprints. In other words,we started looking at outcomes, not at the output.This was not a conscious idea we had, just simply the result of being able to visualise the complete project, of having such a clear product goal.
The impact on our events was profound.
We organically evolved as a team:
from simply trying to fill the Sprint every Sprint Planning and formulating a goal then and there depending on the user stories selected,
to a situation where we would come into the Sprint Planning with the goal in mind and focus all our energies on laying out a plan to achieve it.
At Daily Scrums we found that everyone was so involved in achieving the Sprint Goal that we stopped using a screen to see our Scrum Board. Everyone was so clear about the plan to achieve the Sprint Goal, that we carried the Scrum Board in our heads.
We also noticed that individual user stories lost significance as a vehicle for communication. User stories only became interesting in the context of a Sprint Goal, just like the Sprints.
The Sprint Goal as a vehicle for communication meant that the Sprint Review became a place to discuss, obviously, the Sprint Goal and its context in the project. How helpful was the Sprint Goal to reach the Product Goal? What did it uncover and what new choices did it give rise to? Choices that we of course presented to the client, strengthening their participation and the sense of collaboration.
Our Sprint Goals gave a new focus to our Sprint Reviews. Talking in terms of goals automatically made the conversation with the client one about outcomes. The status-like role of the Sprint Review also disappeared, simply because we stopped communicating in terms of user stories.
At first, we didn’t realise this. We found out with a Sprint we managed to seriously muck up (barely 10 story points on a commitment of 30). We had however managed to realise the Sprint Goal. During the Sprint Review, we were applauded by the client, who completely ignored the burndown and velocity!
Since everyone was so vested in the Product Goal, the results of a Retrospective became more obvious for everyone, and involvement and ownership increased. Stakeholders actually showed an interest in joining us!
Conclusion
I’ve always loved the way Agile accepts human behaviour for what it is and tries to find ways to harness it and give it direction, instead of trying to force it. Project management is I think the most important example of this. Ownership, purpose, autonomy and craftmanship all start with a complete understanding of the whole project. Once a team reaches that point, so many other things fall into place.
I always tell my developers that being Agile is the difference between being simple code-writers and being knowledge managers.Our job as developers is not to write code, but to manage the complexity of all the information involved in the project. And you can only manage information effectively if you understand the full context.
In other words, it's the difference between:
coding something somebody else has thought up. This is the old way of doing things, where the complete project was prepared in advance and the only thing a developer did was write the code,
or doing it as a result of your own understanding of the goal. This is the Agile approach, in which those who do the work are also the ones best suited to decide how to do the work.
Since then, whenever I start working with a new team my focus is usually on the backlog and the team’s ownership of it. Simply because this is often the most effective way to start Scrum working properly.
And as for the Scrum Team I describe in this story, I remember a Retrospective in which we evaluated our approach. We were proud because we had just done a brainstorming session in one hour using Liberating Structures, a session that previously would have easily taken half a day or so. My team was very enthusiastic about it, but they did tell me one thing: they really had to work hard now!
Nowhere to hide, so much information to manage, gone where the times where they could just sit back and code. In fact, coding became the easy part of the job.
As for me, this was the first time I realised that the evolution of a Scrum Team would logically end in both the Scrum Master and Product Owner roles dissipating into the team.