Whether you work with a Project Manager or you are one, you may have wondered: Is there a need for a Project Manager in my Agile organization? And if so, where does that value become most realized?
The Project Manager role is changing, constantly, and with a tight relation to the change in the overall project world.
The days where a Project Manager would instruct the delivery on what to do, in which priority, and when, are declining. In the era of Agile software development it comes down to a much closer 'working together' relationship where everyone needs to contribute value to the progress of the team. That is regardless of role, rank, or title.
Some call this a change to 'servant leadership' while others even see the role as completely redundant when working Agile. Robert Greenleaf established the phrase of 'servant leadership' when he said "Good leaders must first become good servants". But what does that mean for the Project Manager? Walking around being a servant leader is not a concrete enough role and responsibility, one that the Project Manager can add concrete value with and be measured against.
Since many traditional Project Management duties are shared among others, for a while we have been applying different approaches to run our Project Management department with Agile. Until something happened: scaling up and crossing oceans gave us clarity.
After many companies have made the transformation towards the Agile model for software delivery, the role of the Project Manager needs to change along with that and be redefined in order for the Project Managers to remain relevant and provide their value adds.
Over the years, I often interview candidates with years of experience in the field of Project Management where I ask a simple question: "What do you see as the top responsibilities and value adds of a Project Manager, in an Agile delivery organization". And I'll tell you what, the answers are usually not focused and not concise. If the 'traditional' Project Manager doesn't understand clearly how to adapt and bring value in new ways to the Agile delivery groups, she or he will find themselves irrelevant.
Looking at a typical Agile team, who takes care of the traditional project management tasks?
If one takes a typical scrum team the traditional duties accomplished by Project Managers in the past are being distributed between the different roles. The Product owner for example puts priorities in place for the team, and serves as the 'voice of the customer' for the team.
The scrum master takes several project management traditional duties by facilitating the teams' forums, raising the needed flags when commitments are at risk, and handling impediments interfering with the delivery work.
And, the team itself takes some of the duties, like reflecting on their own capacity, committing to scope, and spreading the tasks among the members according to skills and availability.
But there are two conditions where you want a Project Manager in your Agile organization:
- When you scale. Or in other words, when a single project or product, starts scaling to beyond 4 to 5 teams.
- When you go global. A multi-site program with globally distributed delivery teams.
With these two conditions being met, the project manager has four areas of ownership under his or her responsibility:
1. Teams Synchronization.
When the program is scaled and several teams need to work together and join forces to deliver one product, with the same look and feel, the project manager should assist with making that happen. One version being certified and delivered, one system end of iteration Demo, standardize templates and tools to be used by the team, and one program engagement model including unified ceremonies and heartbeat.
2. Outbound liaison.
The project has globe global and is being developed by cross border teams, and in these conditions we'll want to allow the teams and their scrum masters to focus their attention within the teams, rather than on global alignment that may take a lot of time and late or very early hours for bridging time zone gaps. If working SAFe, the project managers on different sites serve as on site RTE delegate. They work with 3rd parties and vendors, work out the communication matrix, and make sure the updates and general communications are being delivered to the team and backwards.
3. Delivery tracking.
If the tech lead owns the professionalism and HR of the team members, the project manager will track and own delivery and commitments. Leading the PI planning or mid-term planning of the team according to the milestones set by product marketing is part of that. Setting clear milestones, handling risks and mitigation on the wider program level and release level rather than on team level, remove external impediments the teams have with their outside world, and manage stakeholders along with the product managers.
4. Glue the team together.
I have witnessed many cases where extremely talented middle management personnel walked into a room but harmony did not exist. The project manager should know all aspects of the project, like product, architecture, development and testing, well enough to get the best out of the others. Get the best out of everyone. One example can be conducting and facilitating the discovery retrospectives. The Project manager in this area of responsibility should think as a chef in a Michelin star restaurant: Even when he is not in the kitchen working on the pans, his reputation and accountability is on the line for whatever result will be delivered.
