Agile Programme Management
A Little Idea I've Been Playing With
I feel that there is a capability gap in the suite of methods making up the formal Agile methodologies. Specifically a programme management method to govern large organisational change programmes and the related projects that support them. Let's call this concept Agile Programme Management or APM (I never said I was good with names). This would need to provide a series of processes to manage high level concepts such as risk & issues, benefits, communication, stakeholder engagement, quality control, and business cases as well as govern iterative Agile project management methods such as Scrum (though we shouldn’t fall into the Agile=Scrum trap).
Wikipedia defines programme management as “the process of managing several related projects, often with the intention of improving an organization's performance.” (Wikipedia)
Not wanting to get into the methodology vs mindset debate, let’s accept that any programme management methodology must support the agile manifesto/mindset while providing generic tools and processes to help practitioners.
No discussion of programme management would be complete without comparing it to MSP®. MSP® was developed by U.K.'s Office of Government Commerce (OGC) alongside the traditional/waterfall PRINCE2® project management methodology though can be implemented separately. In fact I have run several MSP® programmes interfacing directly to Agile/Scrum projects with minor modifications. A purely agile programme management method would make this process much simpler.
Let’s look at some (this is by no means a complete list) of the key components of a Programme and how they can be Agile.
Risk and Issue Management
Risk management is an area where Agile doesn’t do so well. Like non-agile programme, an agile programme should be keeping a risk and issue (realised risks) log which is regularly reviewed. A good place for this review would be a scrum of scrums (or equivalent) where impediments for each team is raised. In other methodologies, issues also include requests for change, but these are already handled appropriately by the agile project management (assuming transparent reporting).
Change Control
Agile already knows how to manage change; accepting change is one of the core concepts values of Agile. The programme needs visibility of each projects backlog/card wall with summary information of the stories/requirements that have an will be delivered. There is no need to keep separate change or configuration management information; it’s already all there. However it may be useful to create a high-level synthesis view of the major stories to define the change to date without going into too much detail.
Business Case and Benefits Management
The business case defines the rationalle for and expected benefits from the programme and it’s constituent projects. These should be developed prior to the programme or projects commencing, but in minimal detail. As the programme progresses and the outputs of each project are refined, the benefits and rationalle will also be refined. However it is very important to have enough information up-front to be able to decide to abandon a programme if it does not seem to be delivering on the benefits. A benefit can be thought of as an Epic User Story;
- As the organisation, I need a 10% reduction in costs; so that we can deliver on our shareholder targets.
- As the organisation, I need a 25% improvement in help desk response times, so that we can reduce the number of customer complaints.
Stakeholder Engagement and Communication
Agile encourages close collaboration between Customers and the delivery teams; programme management should be no different. All progress (or lack of it) should be transparent and stakeholders should be invited to be part of the design, planning and status meetings. I’m not sure if being more proscriptive about stakeholder engagement would help.
Reporting
Each project needs to undertake regular reporting to the programme office, but this should not be onerous or complicated. Existing processes such as the daily stand-up or extracts from the workload management system/card wall should be sufficient to provide enough information. The scrum masters or project managers (and yes I know that a scrum master and project manager are different things) for each project should hold a daily scrum of scrums with the programme office to share this information. The programme should be responsible to synthesise this information into a regular programme level status report suitable for all stakeholders. It may even be possible to hold a programme level daily standup for executive stakeholders.
Project Integration Points
Agile programmes need to have processes to govern iterative and incremental projects. There are four suggestions that immediately spring to mind;
- The start and end of the iterations for each project should be aligned.
- The user stories and priorities for each project will constantly change, so the programme needs full access to all project documentation (such as the backlog) and included in all communication with the Customer.
- Apart from the retrospective, the programme office should be invited to all project meetings such as the daily stand-up and planning sessions.
- For IT projects, releases into production and the subsequent end-user communication should be managed by the programme.
This describes how to “Do Agile”, but what about how to “Be Agile”. How would an Agile programme management methodology work with values and principles of the Agile manifesto.
- We value Individuals and interactions over processes and tools: Agile programme processes should be generic and non-prescriptive. Programme offices should work closely with each of their constituent projects to understand the Customer’s needs, priorities and stories. If a process doesn’t work, don’t use it.
- We value Working software over comprehensive documentation: Replace “Working Software” with “Outcomes” to support non-ICT programmes and we have a great starting point. Up-front documentation, such as programme plans, strategies and business cases should be high-level with minimal detail to provide context without being restrictive.
- We value Customer collaboration over contract negotiation: Less relevant for internal programmes, but the programme should work closely with the “Customer”, whether the CEO or an external client, to develop an understanding of their current and changing requirements.
- We value Responding to change over following a plan: An agile programme should be flexible enough to meet the changing requirements of the organisation. In general; a programme implements change and, if I may be meta, the specific change needed can also change.
Finally, I’m not recommending a one for one replacement of existing methodologies, like MSP®, but rather a complementary programme management methodology to support and govern Agile project management. One that integrates with iterative and incremental projects factoring in changing scope and integrated Customer engagement. The goal of which is to ensure greater transparency across projects and the associated organisational change.
Attribution
Image is CC BY NC ND - 2create (via Flickr)