• Home
• News
• Resources
• Books
• Glossary
• Archives
• Blog
• About
• Contact

Agile Interfaces - PMO Integration

June 28, 2007 @ LeadingAnswers: Leadership and Agile Project Management Blog from Mike Griffiths

(No Ratings Yet)

 Loading ...

I spend a fair portion of my time working with Project Management Office (PMO) and Project Support Office (PSO) groups helping them integrate agile methods. One simple concept I’d like to outline today is the idea of Agile Interfaces.

Agile methods provide a great feature delivery engine, they iteratively feed on features from the backlog and produce tested functionality of high business value.

To external stakeholders this also represents a daunting and unfamiliar process to connect to. Its cyclical, seemingly never ending process is about as appealing to interact with as putting your arm in a washing machine while running. However there are a couple of friendly, safe interfaces that can alleviate mid-cycle arm twisting (how we normally extract information from the team.)

As mentioned, while agile methods focus on delivering features, they often do not provide the information required for PMOs, PSOs and other supporting groups. They typically do not encompass the entire enterprise lifecycle omitting important pre-project work and beyond delivery activities, as shown below.

Fortunately we can safely extract much of the required information without unduly disturbing the process by interfacing with the product backlog and retrospective processes.

Adding Requests to the Product Backlog
The Product Backlog (prioritized requirements list) is the input hopper for the agile engine. So, if the PMO wants something done by the team, then rather than interrupting a daily stand-up meeting or calling a special meeting that disrupts the velocity of the team, an alternative approach is to add the request as a feature (story or requirement) to the Product Backlog.

This feature will then be accessed, estimated and prioritized within the backlog for processing. The only snag is likely to be that the priority assigned falls somewhere below fixing the report footer full stop inconsistencies (i.e. very low). This is because agile projects aim to maximize business value and many external stakeholder requests are seen as non-value adding compliance work, just the sort of stuff to minimize. To make sure these requests actually occur, we need to get a sponsor or other influential stakeholder to give them a business priority. Just as some system features may be required for contractual or legal reasons and just have to be completed, so too are some metrics.

The important distinction here is that the request needs to come from a sponsor or business user, the people responsible for prioritizing the backlog (feature list). The PMO should not just insert a high priority feature, it should be business driven. In most cases the business recognizes the value of project status reporting information and gives it a decent priority. In instances where the sponsors and business do not value the PMO request – this highlights an issue regarding lack of effectiveness/communication from the PMO.

If the PMO cannot convince the sponsor or business reps why its requests are valuable then why should the team be consuming business dollars to fulfill them? Usually things resolve quickly, the obvious items are included and anything with suspect value is renegotiated until all parties can see the value.

Some reporting requests will recur every month, these can be kept in the backlog of features and taken into account when determining the total number of hours available for development work each iteration.

Getting feedback from the project
Agile teams undertake an evaluation of user feedback, technical development, and process effectiveness as part of the retrospective conducted at the end of every iteration. These Evaluation and Learning’s portions of the development cycle can provide great information for a Project Office, but many organizations are oblivious to their existence.

A Project Office can really benefit by capturing these evaluations and learning’s and working with the agile team to facilitate the retrospectives . The process improvement and root cause analysis that occurs at retrospectives is similar to the “Continuous Improvement” actions promoted by CMM level 5, (but without all the compliance to consistent, documented process that characterize levels 3 & 4).

Since project evaluations and learning’s should be happening as part of the agile cycle anyway, it pays project offices to make use of these outputs. Recommended actions for a PMO include:

• Tracking the project Velocity statistics as alternatives to earned value metrics and for trend analysis.
• Capture any “Recommendations for the next iteration” in an ongoing Lessons Learned log for the project.
• Capturing any “Impediments” or “Blockers” reported by the team in the corporate Risk Repository.

Agile projects need not be the unfathomable black box they first appear. With an appreciation of how agile projects operate external groups like a PMO or PSO can interact productively with little disruption to either group.

(Unfortunately this is probably the wrong audience to post this to, I need a “Process driven PMO” forum, please feel free to pass it along to your local PMO.)

Comments

Copyright © 2007 PMToolbox :: Tools and Resources for Project Management