Do we need Project Managers in Agile?
The short answer is No, Project Managers have no place here. But the long one is not so simple. In this article, we will elaborate on the Project managers and their role in Agile systems.
Why Not?
As per the classic definitions, a project has a defined beginning and end in time, and it’s meant to accomplish a specific goal. Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. Project management is the responsibility of a Project manager. These responsibilities are represented by a set of functions, building up the role of Project Manager, which is taken by a single person, usually having the same job title.
The Iron Triangle
In Agile we have Products, not Projects. We aim for long-term value delivery, continuous change, and evolvement in an undefined period of time. We don’t deliver scope in time and budget. Being creative, effective, and producing fast nothing more than needed, we deliver value! There is no need to “manage” projects against baselines, we don’t have a predefined scope, the duration is continuous, and we must maximize the value and ROI within our budget. We consider change as an opportunity aiming at a competitive advantage, not as a threat to the project plan execution.
Maybe we can split the product into a series of goals, having a project for every goal? The reality is so dynamic, that we don’t have strict and specific milestones anymore. The goals we have are visions, directions, problems to solve. Modern goal setting techniques, like OKRs target outcome, not output. We set business goals, measured by value and ROI, rather than features and roadmaps. So, we don’t need someone to “apply skills and knowledge” to meet a bunch of predefined requirements.
Roles vs. Job Titles
It’s important, that we talk about the Project manager role and other roles as sets of functions. A role does not necessarily equal a person or job description. Part of the classic Project manager role (part of the functions) is still needed and is spread through different new roles. These new roles might be taken by many and different people at different moments. Don’t confuse Roles with Job titles. People with any job title (even Project Manager) may take different roles.
The Agile Project Manager Transformation
What happens with all Project management functions: Integration, Scope, Schedule, Cost, Quality, Project Resource, Communications, Risk, Procurement, and Stakeholder Management?
Following the Agile pattern of decentralization, we spread them to the closest operating people. For instance, Product owners take care of Scope and Schedule; Quality and Delivery are taken by the Dev Team; Process and Communication by Agile Masters. Functions like stakeholder management might be split between PO and Agile Masters; Risk management is taken (depending on the risk domain) by different parties. New roles may appear, for instance, responsibility for personal development and administration.
Moving to these roles is the natural evolution for the “old Project managers”. But the transition is where we fail. Despite how experienced and skillful we are, breaking the old habits and adopting the Agile Mindset is the key point of failure.
But, if the “new Project manager” has only part of the functions, does it mean he is doing less work? – Not at all!
Yes, stepping into the new roles, they must focus on a specific sub-set of the original PM functions, but they must deal with a whole palette of new ones.
Reverse the Pyramid
They must “reverse the pyramid”, create an environment for thinking and creativity, provide transparency and clear vision, support and be servants (servant leaders) for the Front line. The Front line has enormous power, but this power has must be unleashed, and this is a very hard full-time job to do.
Nota Bene! Be careful with (hidden command-and-control) roles like Line managers, Release managers, and XYZ-Managers.
Exceptions (Outsourcing)
In a Service (outsourcing) company, you most likely have a contract defining constraints, like time, budget, and at least high-level scope. Initially, everything looks like a traditional project and traditional PM skills are going to be needed. The good news is that Agile estimation and requirements management tactics like the whole team designing and estimating, scope breakdown into stories and epics, high and low-level complexity-based estimation, velocity measurements, etc., can help us sign a reasonable statement of work, following the agile principles within the constraints.
NB: We can use agile contracting techniques like point-based contracts, but you should be able to convince the customer to use them, which might not always be the case.
So, we need all the project managers’ skills back, but they should be transformed. We are Agile and we still value decisions to be made by the Front line and scope changes to be something good for the sake of competitive advantage. Having the Agile Mindset, the Project manager must be brave to delegate a lot of his power to the Front line.
More interesting, now we have 2 products, one is the product that we are hired to develop and the second is the service we provide. Our goals are still the same – the product (service) to evolve and transform in order to get better, to produce more value, and give a competitive advantage. Just like agile products our service should start with MVP, then we iterate, learn, and transform it. Traditional project management is needed to start and run the MVP; the customer will most likely expect that. But the Agile-Project-Manager’s responsibility is to iterate and educate the customer, to change the way we interact with him. Such Project managers must have an Agile Mindset and should introduce Agile organizational structure, culture, and tools. The customer should be coached and partnered through the learning curve of Agility and with time the client-vendor relationship will evolve into a real partnership.
Bottom line…
Plenty of the classic Project management skills and functions are needed, but reversing the pyramid, others are not anymore and new ones appear. In essence, Project managers should evolve, regardless of whether they keep the old title or not.
