Agile PMO Series: A fresh start for project managers and team members
Holitza 270000N4XQ Comment (1) Visits (3227)
Confused by the title? Well let me ask you this, developers and testers, do you know the sound your project manager makes when they walks down the hall, which automatically triggers the fight or flight response in your hypothalamus, and the normal reaction is flight (like under your desk)? Project managers, do you have trouble seeking out team members for status and it becomes almost like a hunting expedition to track down developers to get status, like they’re the prey and you’re the predator? Why can’t we all just get along? Well hopefully some of what comes with agile adoption can help here.
So backing up a bit, just a warning, I’m not a project manager and I’ve never been a project manager, but I have been a developer, a tester and a test manager among other roles and so I’ve grown to appreciate a good project manager (Like my wife Leanne who project manages by profession and does a great job with our household too). But good project managers are hard to find and most that I’ve dealt with tend to come from a command and control mentality. That being said, at the end of the day, the project manager is responsible for progressing the project, managing risks, reporting status to management and assuring the product is delivered on-time, on-budget and on-functionality. So we have to make sure these responsibilities are covered somehow, but at the same time minimize the distractions and busywork we ask of the team members.
So how can agile help here?
Agile teams are cross functional and highly collaborative. What does this grouping of over used buzzwords mean? Well fortunately or unfortunately, the project managers and team members will be working together a lot more. The cross functional approach also brings with it the idea of generalizing specialists, so now project managers (who in an agile world tend to either take on the team lead or ScrumMaster role) might actually do some testing or write some code. There are many benefits to this, here are a few:
The team knows best
So it is possible that you will need project managers, depending on your setup. You may have a number of feature teams that have team leads and will integrate to form your product. In this case, project manager’s will still be a part of the teams and will work with team leads to manage risks and understand status. However, the command and control mentality won’t fly in an agile world. In an agile world the teams manage their work. This isn’t complete anarchy, the team leads will work/negotiate with the product owner, the project manager and other stakeholders to assure the teams are in lock step. The teams then take the responsibility to deliver the work. This approach tends to be effective, when you empower people to step up and “own” the work, they normally rise to the challenge. This also takes the onus off the project manager to be a constant nag.
Open lines of communication
Third, is the focus on frequent stakeholder feedback. In more formal environments, including most of the places I have worked, there are usually two times when the customer (end-user, stakeholder) is included in the project: The beginning, to define and approve requirements and the end, to acceptance test and approve the product/software to be made generally available. This presents obvious problems, What if you got it wrong the first time? What if the competitive landscape changes? What if the stakeholder changes their mind halfway through? What if, at the end of the project, the customer doesn’t like it or the product doesn’t integrate and major portions need to be re-written (best case) or re-architected (worst case)? I’ve been involved in every one of these scenarios and it’s not fun.
So the idea here is to deliver a potentially working version of the software every two to four weeks, this has multiple benefits for the project manager:
The IBM Rational Jazz team has found that more communication makes their lives easier, we not only make our Milestone builds available to customers, but allow them to see our plans, submit enhancements and defects. In so doing we are more likely to get our products right the first time.
There are many other benefits that agile provides to improve
team unity with respect to the PMO and beyond.
Please share your ideas in the comments below…
If you like my Blogs, please follow me on twitter…
Look forward to these future Agile PMO topics: