There was a time when programme management was regarded as an instrument of the non-agile world. This has caused a lot of uncertainty and a negative perception of agile ways-of-working in the professional community of programme managers. Programme managers could rightfully not understand how some of the complex change programmes they were working on could be handled without proper orchestration.
Now that a growing number of bigger organizations has made the transformation to Lean/Agile ways-of-working it fortunately becomes clear that there is still added value in programme management. An agile delivery organization does have an impact on the way the role of a programme manager should be performed but the result is a situation where the benefits of working in an agile way boosts successful programme delivery and vice versa.
Programme Management adds value
The majority of the larger organizations that transform towards an agile delivery uses a Spotify based model or a SAFe based model. In both situations the organization will fully benefit from all the goodies of autonomous agile teams in tribes (Spotify model) or ART’s (Agile Release Trains in SAFe). But as there are often hundreds or even thousands of those autonomous teams, the need for aligned autonomy (see this link to an article I published on Aligned Autonomy) was recognized. Both models have their own instruments for that like the QBR/Obeya instruments in the Spotify model and the Portfolio and Large Solution level parts of SAFe.
Large organizations will always have a defined corporate strategy containing multiple strategic change themes. The strategic themes will impact the backlogs of the teams. The tribes and ART’s will use the strategic priorities to balance them with their own tribe/ART objectives. This should not be interpreted as a competition between the two sets of objectives as preferably they should be aligned. For instance a team objective on Life-cycle Management (‘stay within supported levels of the software’) should be aligned with a strategic objective to offer secure and reliable services to the customers.
And this is where programme management in an agile organization hops in. The most recognized added values of programme management in the past were:
- Focus on delivering benefits;
- Using roadmaps with defined stepping stones (tranches) towards the perceived target;
- Maintaining constant alignment between programme delivery, evolving corporate strategy and actual business situation;
- Creating a governance as lean as possible to achieve this.
What often happened however was a situation where programme organizations created their own world and reason-for-existence. It sometimes felt that the programme organization was the target and not the benefit that the programme was supposed to deliver. It was often combined with a situation that a lot of time and money was spend on defining the target situation in terms of lengthy requirement lists. I think we all remember the programmes with huge lists of requirements describing all possible exception situations that in reality seldom or never occur, so a lot of waste functionality was created. But understandable from the perspective that the business considered this phase as the only moment for the next few years where things could be asked from the Change discipline. Those programmes also had the tendency to create a programme organization with a multi-layer governance leading to bureaucratic and slow decision making. And finally the programme increments or stepping stones were made available twice a year if you were lucky.What also didn’t help was the rigidness of the financial budgeting process that operates in yearly cycles granting budgets to programmes based on original plans.
When listing these characteristics, a lot of people will react that working from a defined set of requirements is still the best way forward. When the programme is supposed to build a 10-kilometre bridge I fully admit that requirement-based delivery is appropriate. But when it comes to a programme where the final situation cannot be fully described because for instance new technology is used with a lot of uncertainty how the end customers will react to that, a more incremental and iterative delivery of programme benefits is preferred.
Special attention should be paid to those organizations where an agile transformation is performed while at the same time the target business architecture (Systems and Processes) is implemented. This situation often occurs in large organizations where the current business architecture is not yet geared towards an agile way of working. At the same time the need to start working differently in order to realize the benefits of an agile way of working is also high leading to the complex hybrid situation. This can and should be orchestrated by experienced programme managers who can deal with all the complexity of the current business architecture in such a way that the teams in the agile delivery organisation can work towards that target in an incremental and iterative way. A solid alignment between the toolset of the programme managers in terms of milestone reporting, investment monitoring, benefit management and senior management impact reporting and the toolset of the agile teams (with user stories, features and epics) is beneficial. In practice organisations will often try to link the Portfolio Management administration to the Backlog administration.
Other characteristics I mentioned could be rated as a wrong way of applying programme management, sometimes the result of unexperienced programme managers doing it all according to what they think the cookbook describes.
Good programme management was always:
- looking constantly for the fastest way to already deliver (partial) benefits,
- looking for ways to deliver in the smallest possible tranches as long as it contains value for the customer,
- leaving HOW things should be delivered to the professionals,
- keen on the question if enough was delivered in order to dismantle the programme,
- focused on creating a programme environment where professionals were inspired to deliver their best performance.
Collaboration is key
Let’s project all this on modern agile delivery organizations.
The majority of change will come without the involvement of programme managers. But for some complex change themes programme managers really add value if they collaborate with the agile delivery organization (tribes/ART’s) in the best possible way, especially in the case where multiple tribes/ART’s are involved in the programme. But what is ‘the best possible way’?
Programme managers should excel in acting as the stakeholder for the objectives of the programme. This means that programme managers participate in all agile events where this stakeholder role is relevant, in close alignment with the Product Owners of the involved teams.
In the Spotify model this would be amongst others:
- In the QBR process where on a quarterly basis the flock of squads in the tribes are aligned with each other and the corporate prioritized themes. Programme managers participate in this process as well safeguarding sufficient priority setting by the teams for programme related features;
- In the Obeya events where for instance in a bi-weekly frequency the status of the delivery as agreed upon in the QBR is monitored. The delivery for the programme is also visible on the Portfolio Wall in the Obeya as well with a red or green RG-status;
- In the tribe/squad events for prioritizing backlogs and reviewing sprint results. The programme manager will be a stakeholder as any other business stakeholder with the ability to adjust the next steps inspired by what is delivered by the team and shown in the Review event;
- On portfolio level by connecting the tribe/squad objectives to the strategic themes;
- On portfolio level in the budgeting cycle. Organisations with an agile delivery organisation also switch from a strict yearly budgeting process towards a rolling forecast or Lean budgeting process.
In the SAFe model similar participation of programme managers will occur like
- Participate in Large Solution coordination;
- Participate in Solution demo’s;
- Participate in Programme Increment planning;
- Maintaining the Economic Framework at Solution level;
- Reporting on Portfolio level;
- Participate in a Lean Budget approach on corporate level.
In this way the usual competences of a programme manager as ‘stakeholder engagement’ and ‘connecting with people towards an appropriate collaboration’ are used to the max. And from a programme manager perspective it is extremely useful and rewarding to act as a facilitator towards the Delivery organization in such a way that all benefits of working in a Lean/Agile way-of-working are realized.
Also for programme managers it is very satisfactory
- if delivering value on a more or less permanent basis is performed in small increments,
- that leaving the ‘how’ to multi-disciplined teams boosts first-time right approaches,
- that waste is avoided as for all small deliveries the business value is validated in the sprint reviews.
One plus one is three
So, although an agile Delivery organization has an impact on the role of the programme manager (from command-and-control style towards more facilitating) the added value of programme management has increased related to the more traditional waterfall style of working.
Good programme management combined with good agile delivery offers more benefit to an organization than just the sum of the two. The agile way-of-working creates a situation where programmes can deliver what is required and when it is required, no more no less.
Henk Venema
Henk Venema is an experienced consultant helping organizations in their transformation towards agile organizations.
He combines his experience on programme- and portfolio management with his experience on large scale agile transformations.
