What is the role in Agile for Project Managers, Program Managers, and the PMO (part 2)?

This is a follow up to my previous posts about role changes for project managers and program managers working in an agile environment.  My last post talked about project managers and in this post, I am going to focus on the program management role.  We might have to tackle this over a couple of different posts!

First, let's start with the role and defined activities for the program manager.  In the PMI Standard for Program Management, the program manager role is described as:

1. Supporting and guiding the individual project managers, in particular to help them understand how their work fits in the big picture
2. Achieving the program and organizational objectives
3. Structuring the program and related processes to support the teams to complete their work and to integrate their deliverables to achieve the program end goal, product or service
4. Ensure projects are organized and executed in a consistent/standard way

Each of these activities plays out in an interesting way when program managers begin to incorporate agile teams within their programs.  This is exactly the thing that I have been challenged with over the last 10 years.

I had my first real experience with Agile back in 2003.  I was asked to lead the IT portion of a large program charged with large-scale data collection in the country of Qatar.  We had a number of teams working together to develop data collection tools and instruments.  Only one team was using agile methods (scrum primarily).  A highlevel project schedule is shown below with the agile activities called out.

 

At the time, we didn't think of this team as being anything different.  We created traditional plans based on a form of waterfall and ignored the fact that they were doing daily standups, they were self-organized, and that they pulled prioritized features and defects from a central backlog.

My next experience with the collision of agile and the program was in 2008.  I was working with an organization that was piloting and preparing to roll-out a vendor software product within their network of hospitals.  The product was an existing off-the-shelf software and the vendor was adding significant new features based on the feedback from our pilots.  A high-level timeline for this work is shown below.

The challenges with this particular product were mostly around the prioritization (and payment for) the added features.  Our pilot teams were providing feedback in the form of specific requirements that the vendor needed to deliver.  Though not written in user story format, the 100 or so statements of functionality were the features that the teams needed. 

Unfortunately the vendor wasn't very clear about how these features would be built.  We worked through an account rep and sometimes interacted with an internal product manager.  They considered our list, and our 'must have' features.  But they had an internal roadmap, that wasn't shared with us, that they used to drive their development.  This lack of clarity and expectations was a major risk for the program since we could not be sure of the functionality that we would get and we needed that to plan the rollout. 

It's also important to note that agile was appropriate for the development of the product.  However, we still needed to have traditional plans for training, rollout, technical support and other functions. 

Also in 2008, I led another large program.  This effort was actually a program within a larger program to support the launch of a global web platform.  There were 4 main components:  a program to develop the web platform (external to our program), development of an administrative system, development of back office application interfaces, and integration testing of the three efforts.  This is shown on the high level timeline below.

One of the challenges in this environment was the synchronization of schedules for the various teams.  For the back office integration teams, this development was done in a traditional way and was mostly completed.  For the platform and the administration systems, the development was being done using agile methods.  Unfortunately these two teams were not synchronized on their sprint cadence or their release points.  This caused numerous headaches for the integration test team who could not be sure what functionality would be delivered at what time.  We also ran into challenges with the development backlog, or more specifically the prioritiztion of development for items on the backlog. 

The last significant example of agile in the program environment occured in 2011.  I had joined a large business re-engineering program with multiple teams.  All the work was being done in a traditional waterfall manner and in fact, months had been spent trying to lock down requirements.  When a new program leader was brought on, he drove the transition of this program to adopt agile methods.  Within 6 months, we had moved to 10 scrum teams who were working from a single prioritized backlog and were delivering against one high level roadmap (see below).

With 10 agile teams, this became the standard method for organizing and driving the program.  There were 4 other teams that were operating in traditional methods but that became secondary to the scrum teams. 

The main challenge in this fourth example were that the Roadmap became the main driver for the overall program.  This replaced the function of the project schedules that were developed for other programs.  There were necessary points of communication and integration with all the teams - including the traditional teams - and these integration points became the main focus for program management.  Finally, it was critical that the program manager become versed in agile and champion the agile practices.

Some of the consistent challenges or takeaways across all 4 of these programs includes:

1. The greater the proportion of agile to traditional, the more important it is that the Pgm Manager embrace, champion, and enforce the use. 
2. Program Manager must be well versed in agile and champion agile practices.  Program managers should understand and leverage the flexibility that Agile teams can provide. Conversely, Methods like scrum actually require a lot of disclipine and the Pgm need to be aware of that.
3. Program Manager needs to understand the critical dependencies between teams and between the development backlogs.  Program needs to align team efforts around the roadmaps and release schedules for the agile teams.  Where possible, all teams should be on the same or a related cadence to simplify communications, training, UAT, and other downstream efforts.
4. It is critical to understand who is going to prioritize the items on the development backlog.  The program manager should be involved in decisions that affect the bigger picture and the other teams in the program to avoid sub-optimization.  A related issue is managing internal customer expectations is critical – feature priority and timing!

It seems inevitable to me that Program Managers are going to need to be comfortable incorporating agile methods.  Hopefully this post will help them thinking about what is required.

As always, I'd love to hear your thoughts.

Anthony