The hardest part of being an Agile Project Manager

Brian Button recently described The hardest part of being an Agile Project Manager for him on a project: Staying out of the way. He’s found that to let the team effectively grow and work well together, they need to be able to identify and resolve some problems on their own. Based on my own experience, I couldn’t agree more, though it’s a seemingly paradoxical idea. Brian says that at times he takes this to the point of letting the team identify and resolve some issues on their own – even when he thinks he can see the problem coming before the team realizes it.

Stepping back, my view is that on an agile project, the job of a team lead/project manager/scrum master/whatever is to clear roadblocks. A daily stand-up meeting helps team communication and also helps to uncover problems people may be having sooner during the process of development. The team lead is responsible for making sure that someone addresses any problems that are identified. Additionally, having a self-sustaining team is important – because the team lead may not always be available, but also because the effectiveness of a team increases when they have confidence that they can address problems as a team, without the always requiring involvement of the team lead – or the team lead will become a bottleneck.

There’s a balancing act here between short-term effectiveness and long-term effectiveness. To me, this is the same trade-off people make all the time: mentoring and building people within an organization vs. impact on daily duties, corporate quarterly results vs. long-term sustainability of the business, day trading vs. investing in mutual funds, etc. To be successful, you need a healthy balance of both: one eye on current priorities and one eye on building for the future.

In the past, I have personally struggled with how much to involve myself in everyday decisions of the team – and making sure that my involvement was for the right reasons. Though each scenario is different, one of my approaches was to try to contribute my knowledge and experience to the discussion, but to refrain from influencing the decision beyond just helping to work through the problem and possible solutions. However, some decisions warrant more involvement and in those cases I wasn’t shy about expressing my opinion about a specific resolution.

It’s another case where it’s a tough call and you need to think about what is right for the situation and for the specific team involved.

About Scott

believes software development is more about people than technology; believes in agile processes; software developer, engineer, designer, architect, or whatever they're calling us these days; enjoys discussing software design; working on a program to write other programs (but it hasn't written itself yet).
This entry was posted in Agile Processes and tagged , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>