Search This Blog


4 August 2008

Agile PMO

Some time ago, I wrote a post about building a new department during a restructure. We've been working on how to institute processes that are not too much overhead since we have a very small staff with many customers to support. However, we are required to meet some very strict reporting and accounting guidelines for legal reasons. That's why I've been agitating for an Agile PMO.

In this article by Tamara Sulaiman, she talks about how the PMO fits into an Agile environment. Ms. Sulaiman makes some excellent points but two of them really jump out at me.

The first is "Establish a “Meta Scrum” that is tasked with mapping projects and features to corporate strategy.". This is a problem I've been struggling with in our current situation. The article references This article at the Agile Journal by Brent Barton. This is an excellent idea for what we are trying to do. In the article, Mr. Barton talks about how the Product Owner should run the Meta-Scrum since they have the roadmap. This is exactly where we are trying to go. He also mentions that the group has to be ready for full transparency. I don't know if everyone is ready, but I think this is a step in the right direction to get teams out of the stove-pipe style of work they've been used to and into something that works better for everyone.

How do we, as a small group supporting a large number of projects, make sure we all have the information we need to keep up with the current portfolio? How about a Scrum? How about using a Scrum board to track where projects are and which team has the current responsibility for them? How about a nice, obvious place to store the project backlog so everyone knows what projects are coming up that need to be planned for?

I'm working on creating a board that will help answer these questions. I'll let you know how it works out after we've used it for awhile.

The second point that I want to mention is "Gather and communicate portfolio level metrics to the organization.". If the only type of project I was concerned about was software development, then I would be all over AgileEVM. However, we are trying to manage projects in all areas of IT - systems, networking, applications, security, telecommunications, etc. This makes it somewhat harder to find consistent measures. We may just use separate measures for progress but try to find some common measure for business value.

Any way you look at it, we are playing Jenga in our implementation of Agile. We'll see how solid our players are.