I often find it awkward to say I am a project manager in an “agile” workplace. Aside from a Project Manager not having a defined role in the agile-scrum methodology, it seems disturbing to some to hear the word manager, in any context. How did being a team or project manager - or really a manager of anything - become so lame, passe or downright dirty?
We could blame it on decades of TV sitcoms spinning out countless jokes about a stereotypically hapless, clueless, overburdened and therefore ineffective manager. And some of that blame would be appropriately placed. However, in an increasingly agile-focused work place, I am curious if the role of project manager is one that is still needed, only needed sometimes or is actually a leftover from an older business paradigm that is not dying quite as quickly as some might hope.
Now I have to preface all of this with an admission; I am currently a Project Manager on a select number of contracts (in parallel with the other business tasks that keep Coshx rolling along the cutting edge of tech development). In these cases, project management leverages the value we provide to our clients rather than inserting a boss-like persona that gets in the way of our developers. When the project is complex, when the stakeholder-group is large, if there is a technical knowledge gap between the client and the development team, or if the development team is less experience in handling clients’ needs, it might be a good idea to add a team member who can keep the communication, ideas and productivity flowing. But some modern development shops would argue that when executed properly, self-organizing teams, ala Agile, should not require such an intermediary. Some could say that relying on a Project Manager instead of developing the self-reliant skill-set of the development team diminishes the rare air of agile software development.
Are software development project managers superfluous or outmoded in an agile setting? Recently we had a good fortune to work with a unique client; a group of 15 individuals from three partnering organizations who formed our “collective client.” Dealing with all the personalities, communication styles, competing, conflicting and sometime political points-of-view that emerged as we began to articulate the needs of development, was a daunting task, even for a trained project manager. For an engineer who may usually deal with one or two stakeholders at a time, this was an overwhelming prospect. And one that threatened any hope of getting the work done in an efficient manner.
It’s funny how the trends of our culture force us to reinvent ourselves, rebrand and label what we do in a way that is currently popular and marketable. The whole “management” role has undergone great scrutiny and been found lacking in many cases. However, in the software industry, project management never really went away, it has simply been called something else; team leader, scrum master, lead developer, lead engineer, product developer, and so on. All of these roles have aspects of project management imbued in them. But none of them include all the various accountability aspects of a traditional PM, like referring explicitly to the contract, SOW and original budget to be sure the project is developing according to the plan proposed. In addition to drafting contract amendments, change orders and all those technical details related to the business transaction that still need to be handled. If the self-organized development team is ill-equipped in these areas (no criticism here, a great developer doesn’t have to be a great people-person, contract writer or accountant), then the business relationship can suffer. And so to, will the end product suffer.
However it happened that “manager” became synonymous with superfluous, I assert that there is a place for a good manager to relieve the pressure on development teams and to put clients at ease. I think of this as a “User Interface” role where the client can easily access, inform and engage the development team without distracting them from the work and through the context of our project plan. The inverse is true as well; the development team can rely on me to communicate their needs and clarifying questions to the client(s). Truth be told, many projects don’t need a dedicated PM. But for those that do, a PM can save costs for our clients, deliver a better product and reduce headaches for everyone.
Going back to my original query, it seems that a smart team would keep someone around who has the skill-set to rise to that overseeing level of manager/communicator. But a word of caution is called for, we need to be mindful that team leaders who can assume this role are at least given the chance to try. The decision to utilize a PM needs to come from the development team and client as part of the overall solution for the project.
Most software development PM’s are so much more than leftover dinosaurs from a dysfunctional corporate structure, at least the good ones are. A good PM offers real insight and clarity along with an empowering stance that facilitates evolving dev/client communications, encourages new pathways to success and helps make sure the team is saying “yes!” throughout the development process. We may not be completely useless, after all, if not completely required, either. I’d say that as long as there are complex projects to build, the role of project manager won’t soon be relegated to history as the unneeded “pinkie toe” of development teams.