Agile projects - can a PMO manage them?
In fact, let’s rephrase that. Can any part of the business manage Agile projects? Or are PMO professionals and other business managers doomed to listen to endless tales of stories and sprints and who said what at the scrum, without even a clue as to what business value has been delivered, or whether any progress has been made?
It sometimes seems that Agile was invented purely to stop busybodies in the PMO from finding out what is happening (or quite often not happening) in IT development. There are serious problems to letting an IT department run riot with Agile without supervision from the business. For one thing, IT teams are focused on big ticket items, and large amounts of money can be wasted before any not-so-Agile manager realises that nothing of value has been, or is likely to be, produced.
The problem often comes from the fact that the IT team are allowed to use Agile as both their working method and their reporting tool. The reports are incomprehensible to managers, who listen to statistics on variances and unit testing and why the Sprint needed to produce more infrastructure for an upcoming Sprint. They are none the wiser at the end of it
This is where the PMO can play a vital role. It’s the adult supervising the sandbox if you like. An experienced PMO manager will be aware of the problems of reporting progress and relating it to spend on an IT project. They’ll also be aware of the way that Agile can be used to baffle business enquirers. So at the start of a project with IT deliverables being run by Agile methods, they’ll ask the team to agree some big picture business deliverables.
The PMO manager can make it clear that precisely how these deliverables are produced is a matter of professional expertise for the IT team. But reporting will be against those business outputs and deliverables, with a percentage complete and forecast finish date in each reporting round. How many sprints are involved shouldn’t involve the PMO. They should stand aside from this, and take a coolly objective look at how much business value is being achieved, as stated in the project business case and initiation documents.
Actually, really talented Agile team leaders understand that user engagement is key, and they’ll actually invite business managers, including the PMO, to attend scrums.
The job of the PMO is always to remain objective
There’s a process that the Americans call “agency capture”. It’s when an agency is set up to regulate an industry or a group in the public interest and then gradually gets drawn into siding with the special interest groups that it was meant to be regulating.
Make sure that doesn’t happen with the PMO and Agile, because people can suddenly adopt it like a new-age religion.
The PMO is there to smooth out the differences between an IT project using Agile and a transformation project using LEAN for example. It must explain to corporate management in understandable terms, what each is delivering, how much they’ve spent, whether they’re on time and so on.
It's one of the real value-added functions of the PMO: standardisation across projects. The PMO Manager needs to appreciate the good parts of all the project methods in use, while not letting anyone off the hook when it comes to reporting results.