Agile Portfolio Management Briefing

Tuesday night, I was the guest speaker at a joint meeting of the Denver chapter of the International Institute of Business Analysis (IIBA) and the newly formed Denver chapter of the Agile Project Leadership Network. We had a good crowd of 50-60 or so Business Analysis, Project Managers and the like. While most of the Business Analysts in the group were fairly new to agile, the attendees from APLN, of course, had more agile experience.

My topic was “Moving to Agile Portfolio Management”. The topic was of great interest to many in the group and we had a lively discussion about the issues of evolving the enterprise to take a more agile approach at the portfolio, as opposed to project or program, level. Of course much of this discussion revolves around the legacy (fixed budget-fixed scope-fixed timeline) thinking that is predominant in so many PMO offices, and how that thinking can be a major inhibitor to the achievement of real agility at the enterprise level. More importantly, we also discussed some ideas as to what to do about it.

I promised to post the slides from that presentation, so here they are. agile-porfolio-management-denver-apln-mar-2009

If you are a business analyst or project manager starting to see agile in your present or near future (and who isn’t?) you owe it to yourself to join one of these organizations.


2 thoughts on “Agile Portfolio Management Briefing

  1. I have looked at the enterprise agile topic from a number of sources, but I have yet to see one that addresses the problem of IT organizations maintaining ERP, CRM, and other similar packaged software over long periods of time.

    There seems to be an assumption that you can execute a number of projects and or programs and walk away. The reality is that you must deal with the maintenance of any implemented features and simultaneously make it possible to implement new features. This intertwining of build and run creates both technical and portfolio management problems.

    On the technical side, teams that are building are in constant code interference with those that are maintaining. On the portfolio side there are often projects in the range of 500 – 1000 person days of effort. That size project would only amount to a relatively small handful of agile iterations and teams would be constantly forming and reforming as they move from project to project.

    Has anyone documented what an agile IT organization looks like that has these sorts of issues?

    • Russ,
      Most teams (IT or not) do have significant ongoing maintenance which they build in as a velocity allocation in their planning. And I have seen agile applied quite well in environments such as ERP and CRM maintenance. Often this is done with a pull type kanban system, rather than with Scrum, although many do use scrum like iterations as a planning, commitment, and velocity feedback mechanism.

      As for teams constantly forming for small projects; that isn’t necessary in the case of feature teams, which are longer-lived teams that just flex to whatever backlog is presented to them. But agile or not, all teams must flex to the current backlog, or the enterprise cant address its real business requirements.

      I’m going to point this thread to a friend who is also a development director in an agile IT shop, with just these types of challenges. Not sure if he’ll comment or not, but the agile pattern is well proven in these environments.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s