Guardians of the Gantt Chart

The Project Manager in an Agile environment

With the shift to self-organized teams and Agile Software Development, we’ve seen the traditional manager role erode. The boss has been replaced by coaches and servant leaders. That’s the theory.

In most organizations, however, management has not disappeared. There is a new set of job titles and responsibilities. The hierarchy is not so clear anymore.

No job has been impacted more than that of the Project Manager. What does she do in an Agile environment? Is she part of the team? Does the Scrum Master report to her? Do we need one at all?

Developers tend to complain about their PM. The stereotype goes that they’ll ask for estimates and use that to sell crazy unhinged predictions to the stakeholders. They’ll say Yes to every half-assed change request and No to the important stuff. Oh, and micro-management…

Project Managers, on the other hand, often feel powerless when working with agile teams. The entire methodology feels designed to mess with them. So they’ll find clever ways to tame the chaos. They’ll abuse Story Points and Velocity because at least you can do calculations with them.

So, what does a Project Manager do in an Agile environment and how can she stay relevant?

What is it that you do?

As a project manager, you are responsible for delivering the scope on time and within the budget. That’s the lie most HR departments will put in their ads. It’s also why most dev teams don’t trust you.

Back when Fred Flintstone planned a Waterfall project, the PM’s role was clear. He was the Guardian of the Gantt Chart. Protector of The Plan. The scope was analysed and estimated and if the team wasn’t on track, something was wrong. Every day the PM would take the status and shuffle resources and milestones until it worked.

Compare that to a modern environment. Most managers don’t have authority over self-organized teams. They cannot change priorities mid-sprint without being berated. There’s a movement of developers that flat-out refuses to provide estimates. Teams tackle technical debt before they even look at your change request.

How the hell are you supposed to do your job? What is your job?

Be part of the team

Find a role within the team that doesn’t imply a hierarchy. Make sure you know the details of what the team is working on. That means joining Scrum Ceremonies as well as informal team lunches.

That also means communicating your work to the rest of the team. If the team decides they’re switching to a new JIRA workflow and you volunteer to do it, make it a ticket on the board. In fact: visualize all these servant leadership tasks and see how much your colleagues appreciate your contributions. You should follow as much as you lead.

Manage up

Since we’re all Lean and Agile these days, we don’t have a fixed scope anymore. Stakeholders, however, don’t always get that. They feel they can skip the expensive Analysis Phase and move straight to Development. That’s what the Agile Consultants have promised them.

The problem is that most of your stakeholders are sure they know what they want. They are convinced it’s all clear and everything has been communicated well. The interesting questions only arise during implementation and high-level ideas never hit the ground unscathed. When the thing gets presented, they break out the “What we meant was…”.

A project manager should mainly manage up. Set the expectations of your stakeholders and manage the influx of new ideas and urgent priorities. When you can unite all stakeholders behind a singular vision, you’re doing your job.

Report the truth

A project navigates by your status reports. You provide the compass.

These status reports are often twisted by office politics. People want to look strong in the eyes of upper management and make their status a little bit rosier than it is. Others want to blow up a mere issue to the level of a calamity to get the necessary attention.

Don’t fall into that trap. A bad project doesn’t make you a bad PM. Lying about the health of a project does.

Your work is the answer to the question “How are we doing?”. If sarcasm and irony are fueling the team’s lunch conversation and stakeholders feel the project is doing well, you are not doing your job.

Self-organizing teams might despise micro-managers, but they adore a leader who shows them True North.

Building software is hard, but don't let that stop you.

If you're building a product and feel like you could use a supportive techie in your corner, let's set up a quick chat to see if I can help you.