It also happens to be the question I struggle the most to answer. Not because the most common agile “frameworks” are largely silent, or outright hostile to the concept of “management”; but because it implies that you should somehow act differently.
The truth of the matter is, there is no such thing as an “agile project manager”. You are simply a project manager working on software projects. As a PM you use your knowledge and training to know that the process and activities for software efforts are different than say, construction, and tailor them appropriately. It is really no more, or less than that.
In reality, you will need to fundamentally change how you think and act about project management. Frustratingly, that should not be the case. You should already be working in a leadership mode, not a management mode. This “transformation” should be an easy one, but I know in many places it is not.
The fork in the road shouldn’t be one of “to be an agile PM or not to be an agile PM”, but more of “Am I a leader and enabling the people around me to be successful”, and if not, “how do I get better at that”. That is the value of a good project manager. Being a leader and constantly working to get better will make you successful regardless of what environment or domain you work in.
For example, do you think a construction PM is walking around making sure their sub-contractors are utilized 40 hours a week? Do you think they’re spending 8 hours a week extracting metrics from 10 disparate systems to create a 12-page PowerPoint status one person reads? The answer is simply, no. They are getting shit done, and so should you. In fact, you should be demanding the ability to do so.
The core challenge we face within large corporate software development is the association of “project management” to heavy command and control processes organizations have layered on top of software development. Frankly, the reason why “agile” came into existence is because these actions do not help us (and in many cases, hinder) our ability to deliver software. For better or worse, PM’s are the living embodiment of these processes.
If your organization is going through an “agile transformation” now is the time to use that activity as a cover to reset your role and carve out a more interesting, stimulating, and valuable work environment.
While I abhor serialized blog posts, there is simply too much here to jam into one post. I’d get finger cramps, you’d lose interest and stop reading, and then no one wins. So, we will use this post as a jumping off point and a tease for more detailed posts to follow. The goal is to discuss
the traits and actions of a well-rounded PM that can succeed in any environment, not just agile software development. In the end, if we can help you shed the yoke of status reporting, hours tracking, and utilization justification then we will call that a win.
In future posts we’ll examine:
* Leaders vs. Managers
* Lifecycle types and their desired outcomes
* One-size-fits-all methodologies
* The goal of software development (hint, its WORKING SOFTWARE!!!)
* GSD: Getting Shit Done
Who knows, maybe some others will float in. Remember, I’m agile. If another topic pops up, we’ll throw it on the backlog and blog about it. Until then stay agile.
About the Author: bdub is a card-carrying member of PMI and has had his PMP since 2003. Since 2004 he has been in the agile program working to help teams and companies apply change-based methodologies to high-risk creative endeavors and #suckless one day at a time. You can reach him at bdub@sketchdev.io or @agilebdub
*PMI, PMBOK, PMP and PMI-ACP are registered marks of the Project Management Institute, Inc.