Try not to be yet another project management overhead

Context

Most of our teams in Thoughtworks India work for clients outside India, which results in an “All Thoughtworks team” which is quite high in the Agile maturity scale.

When I used to interview Project Managers in Thoughtworks India, I often struggled to find people who would sound reasonable to call in for an interview after a preliminary conversation.

Something I often end up asking is “Can you tell me about a difficult or puzzling issue you had to handle on the last project  or so ? “ and the answer to this would typically be

“I had to manage dependencies across multiple vendors which was really painful”

“I had people with performance issues on my team, and we could never deliver”

“Vendors did not deliver on time”

“Scope kept changing”

“Ran out of budget”

“No one was convinced about Agile in my organization”

While these were legitimate problems, no one would actually come up and say

“There were too many defects every iteration and I had a tough time figuring out the root cause”

“Our velocity was low and we did not know how to handle a particular new technology”

“We did not know how to write automated tests around a few legacy systems”

“Our build times were quite high and we had no good solution “

“We had to coach a really difficult product owner”

This made me conclude that even though it has been so many years since Agile, XP, Scrum have been around, project managers still try and manage the golden triangle of Scope, Time and Budget. And when you are a bit more senior in the organization, you are given the responsibility of managing vendors, and be christened as a program manager. There were a few people who had at least good people management skills which was a sign of hope.

What should you know as a Project Manager to be useful ?

The reality is that in a highly collaborative and self organized environment like an agile team, a project manager is considered an overhead. And a project manager who does not take interest in the product the team is building , the way the team is collaborating and some of the technical challenges on the ground, is downright useless for a team.

Solving some of the project issues in an Agile team needs a deeper understanding of the engineering practices that are used to build the product as well as an understanding of the domain and the business in which the product fits in.

If you need to be an effective project manager, you should at least have a good handle of a few things in your project such as

* What is a good User Story in your project  or are we slicing stories correctly ?

* How good is the Continuous Integration on your project and how can it be improved ?

* What is your functional automation strategy and how can you achieve the maximum benefit from it ?

* How much technical debt are you carrying on the project and what is the impact ?

* What are the difficult areas in the codebase to test, and how can you increase coverage in those areas ?

* What does the production deployment infrastructure look like and how you best utilize that information within the project to create more similar environments ?

* If you are in a stand-up meeting where a QA calls out a defect, you should be in a position to question why no test actually caught that defect before hand in the continuous integration ?

For the typical project manager who worry only about the golden triangle of Scope, Time and Cost at a high level this might seem weird. Some of them might even want to delegate it other people in the team.

In a matured agile team, the case for a project manager can be made only when he/she has a handle on some of the things mentioned above. Estimating using points, putting it in a release plan based on velocity can be done by anyone in the team.

The crux lies in understanding the product the team is building , the tools and techniques they employ to do it and the collaboration required to yield the best results !