Imagine a project manager in a large organization. Let’s call him Charlie. He’s good at what he is doing. He likes to be in charge and control over projects. He knows how the work should be done, when the work should be done and what kind of work should be done within a given timeframe. All and all, he is responsible for the outcome so he better be on top of everything. He steers the project by controlling the scope, cost and time and ensuring the quality level, also known as the devil’s triangle. Generally his tasks have to do with:
- Budget stuff
- Inventorying stuff
- Resource stuff
- Planning stuff
- Delegate stuff
- Stakeholder management
- Monitor stuff
Source: State of Agile, 8th annual survey 2013
Then one day the company read some research on Agile (State of Agile) which concluded that similar companies use a form of Agile about 88% of the time. This made Charie’s company curious. Management wondered: “what’s so good about this agile way?” The research survey answered this question with a top 3 of reasons:
- Ability to manage changing priorities
- Increase productivity
- Project visibility
This all sounds pretty nice but what is Agile exactly? Charlie wonders. So he googled around and found the website Agilemanifesto.org where he found these 4 values:
- Individuals and interactions over Processes and tools
- Working software over Comprehensive documentation
- Customer collaboration over Contract negotiation
- Responding to change over Following a plan
Clearly stating: “That is, while there is value in the items on the right, we value the items on the left more.”
Charlie finds this a little peculiar; this is not how he was used to work in past projects. Most of the time it was done the other way round And how on earth can these 4 values and 12 principals be used in projects?(http://agilemanifesto.org/principles.html). There must be some methods or frameworks out there to put this mind-set in to work?
So he read the research of the state of agile a bit more. And he stumbled upon some statistics.
Charlie told his company that if they wanted to work Agile, then scrum or a hybrid version of scrum would probably be a good way to start. The research showed that a lot of of companies (73%) working in an Agile way use Scrum or a similar method.
Charlie again searched the internet for Scrum and found a lot of information. Yet he was surprised, where did his project manager role go?
Clearly this must be a mistake; a project can’t run well or succeed the project manager can’t perform his duty or tasks.Who else will be in charge and who will control the what, the how and the when?
“It seems these all were divided over the 3 roles, Charlie”, said a member of his company. “Look” and he started to write this down on a whiteboard. “This is how it was”
As a project manager, you are in charge of the project team members and need to be in control since you are responsible for what has been done, how it’s been done and if it’s all been done in time. He added a new drawing – “And this is how it’s going to be”
- The product owner – Controls the what and the when
- The scrum master – He doesn’t take control but he rather coaches and facilitates the team so the team can focus on getting things done.
- The developer(s) – Decide the how, heck they are the ones who have to build it and they know how to build it. So why not let them be in charge of how to build it.
Charlie nodded -Ok- and said “but my tasks, my tasks, there are still my tasks, they surely are needed, right?” “Let’s have a look at your tasks then” the co-worker replied. And he started to summarize.
“Your tasks involve budget,inventorying, resourcing, planning and delegating; monitor this so you can answer to the stakeholders if everything is going according to plan. If it’s not going to plan, communicate that. Discuss with the project team the work you delegated to them and set things straight.
Project managers tasks mapped on the scrum framework
The scrum framework: https://www.scrum.org/Scrum-Guide
How does this process work? First there is a vision of something to create. Within the company there are stakeholders with all kinds of needs, dreams and want to haves for this new idea. It’s pretty hard to manage all these things so Scrum came up with a product backlog (PBL). This is a log with all the stuff the stakeholders come up with to put on there. Yet a log with all these “needs” is still hard; to work with, so they created a product owner (PO), one of the 3 roles that exist in Scrum. He is responsible for the product backlog and he has to communicate and fine tune with the stakeholders what will be on it. Most of the time by ROI
So a part tasks that normally would be done by the project manager are performed here:
- Stakeholder management
- Inventorying (PBL)
- Plan (PBL)
- Budget (PBL)
Now that the PBL contains a list of wishes, sorted by which wish has the greatest value to the company, it shows which item(s) to build first. Now a PO doesn’t develop himself; he has a team of developers (or: development team) to build the code. The developers take the most important items of the PBL first and put these on the sprint backlog (SBL) so they can realize them in a sprint. The amount of work they manage to do each sprint is decided by the development team, not the PO not the Scrum Master (SM). The DT delivers a shippable product increment every sprint, which they present/demo to the PO and the stakeholders. The work done can be monitored in several ways: via the scrum board, daily stand-up, the sprint burn down chart or the demo. This means that other parts of the project manager’s tasks are performed as well:
- Stakeholder management
- Inventorying (SBL)
- Plan (SBL)
- Monitor (SBL)
To make the scrum team complete, there is a scrum master. He coaches the team and the organisation in the ways of Scrum. But also keeps the team safe from outside distractions. He facilitates the team so the team can focus.
To complete the scrum team, it needs a scrum master. A SM coaches the team and the organisation in the ways of scrum and keeps the team shielded from outside disctractions. The entire scrum team is responsible for the outcome and output of the product development. This is why they use the triple constraint a bit different. Quality, time and cost are fixed, but scope is the variable factor in scrum.
So as you can see, these isn’t much left for a project manager to do. All his responsibilities and tasks are already performed by the scrum team. So what can Charlie still do?
- Could he become a scrum master?
- Could he become a product owner?
- Could he become part of the Human resources organization?
- Could he help the organisation work with scrum?
- Should he keep on working on traditional projects?
- Should he change his way of working?
- Should he give up and quit his job?
What could, should or must he do? Leave your opinion in the comments and let’s discuss. I’m very curious
Jos Punter is an Agile Test expert. In 2007 he joined Sogeti as a Young Professional tester. In the last years he has gathered experience in testing in Agile and Ad-hoc projects. At the moment he works as a test expert who is always looking to automate his tests. He works mainly in agile teams and is a certified Scrummaster. Because he has experience working in agile environments and scrumteams he gives consult to others about these topics.