/ scrum

Does Agile Scrum need a Project Manager?

I was just talking earlier about Agile Scrum rejecting the command-and-control paradigm in a favor of a more flat collaborative paradigm based on enabling.

Later on I had this article brought to my attention. This article succeeds at sounding like a cry of a now-obsolte way of looking at projects. In a moment I will nitpick its main points.

But first I will play the Devil's advocate and add the one thing I've heard repeated over and over by supports of Project Manager role: Agile Scrum does not specify a cost-control mechanism. What Agile Scrum seems to lack is a firm hand ready to make though decisions in order to limit mounting costs. This largely refers to oursourcing companies which face this problem continuously.

Having added that, let's look at a few points from the article mentioned above:

  • People are not perfect - the article suggests that since people make a lot of mistakes, they need a whip next to them to bring them in line. I am really not sure what to make of this conclusion given the premise. If people are not perfect, why put a person in charge? That person is also not perfect. Is that a suggestion that Project Managers are superhuman?

    • Agile solution: no process can make up for people's imperfections, but team work can mitigate that. In addition, Scrum supports letting developers in charges and making them responsible for the work to do. The only pressure one needs is their own recognition of the importance of the project, while a Project Manager in between will only wrap the team in a bubble outside the "real world" of the project.
  • Controlling the change - change happens. You can't control it. The whole point of Agile in general is embracing and working with the inevitability of change. Controlling and managing change are the old way which has already failed, otherwise Agile wouldn't have risen.

    • Agile solution: in Agile Scrum, change is inherent to the process. The whole concept of iterative development is to allow change to happen. You produce some work, then you add and change next iteration. It's as simple as that. You may record at every step what has changed, what has been added, what has been removed, etc and follow the flow. It's a transparent process that can be followed by any stakeholder.
  • Communication causes gaps and conflicts - indeed, but this is largely specific to control-and-command structures where communication suffers from severe overhead and opacity. A project doesn't need an information processor, everyone should participate in dissemination.

    • Agile solution: in Scrum, the PO is a communication nexus. He does this only to the extent of allowing the team to work without distraction as long as no immediate changes require attention. The team is assured that the only valid communication comes from one source and doesn't need to manage relationships directly with stakeholders at all times.
  • Processes are not perfect - processes are not perfect in general as in there isn't one process that applies in all situations and to all projects. But for every particular situation there will be a process that works for it. A Project Manager is not a role to consider by default because not all processes need it and a Project Manager isn't an expert in all possible solutions (and would certainly not be able to exclude himself if the process requires it).

    • Agile solution: Agile isn't a framework, is a set of principles incorporated in several distinct frameworks. All of them have pro's and con's and it's well conceivable that they may not apply. However, before judging a certain process you should ensure it is implemented correctly and expertly. The top failing in any Agile implementation is that the enterprise top management either doesn't bring expertise into the enterprise to manage transformation and/or doesn't empower the knowledgeable people to correctly implement the transformation
  • Processes not implemented properly - as mentioned above, this is a reason why some processes may be perceived as inappropriate to a situation when they might work if properly implemented. This is definitely not an argument supporting the role of Project Manager but one against it. If Project Manager isn't a role in a certain process but you insist on having it for fear it might fail, then you are actively sabotaging the process and ensuring failure.

    • Agile solution: the Scrum Master is the person in charge of supervising the process and to work on its implementation. Empowering the Scrum Master and getting behind a proper Agile Scrum transformation is the only way to experience Agile in your enterprise. Half-baked attempts do not prove that Scrum doesn't work, they only prove lack of will to evolve.
  • Cost control - and to end with the point added by myself - much like transparency and predictability, cost control is built into Agile Scrum.

    • Agile solution: When the cost unit is the sprint, the product backlog groomed and estimated for a reasonable period ahead, the cost becomes transparent. At any time the client needs only to look at the charts and backlog to check what the cost will be and what has the project costed so far. Once enough empirical data has been observed (velocity in different situations), assessments can be made. Is the cost mounting? Then perhaps repriotizing the work is in order. Or removing work. Or changing things like DoD. When properly implemented, Scrum provides reasonable predictability even on long term as long as the process is respected. When it comes to costs, the 'optimizing the value of work' role of the Product Owner is paramount as it's often true that simply shifting product backlog items completely changes the way one looks at the product and it's also a form of cost control.
Does Agile Scrum need a Project Manager?
Share this