Purpose of this Guide
Introduction
The DSDM Agile Programme Framework represents the core guidance for managing Agile programmes. It considers the whole lifecycle of a programme from initial inception through to closure.
There is often a requirement in an organisation of any type to transform the organisation from its current operational state to a new operational state. The reasons and the type of change may vary greatly.
The characteristics are the same. A series of initiatives are carried out to move the organisation from the old state to the new state. The initiatives may be projects, business change activities or other activities. A programme is formed to manage this series of initiatives and to ensure that the new operational state is successfully reached. The length of the programme is likely to be years, and quite often a stepwise approach to implementation may be taken.
Programme management is concerned with ensuring the programme will successfully deliver its outcomes and expected benefits. In many ways, programmes are already Agile by nature, autonomous project teams deliver outputs that contribute to the programme outcomes in an incremental approach to delivery.
Agile Project Management places more emphasis on incremental delivery and recognises that the programme will evolve over time and cannot be fully defined up front. Whilst a roadmap to the future can be created, only the relatively immediate future state can be defined in any detail.
Agile Programme Management embraces an iterative approach, where the best solutions will emerge based on frequent review and feedback. There is constant review back to the programme’s goals and to the business strategy. This ensures that changing circumstances are routinely incorporated into the programme.
There is a culture of empowerment, where teams at all levels understand and accept that they are free, and indeed expected, to make decisions within the scope of what they have been asked to deliver, but equally they are clear on the boundaries of their empowerment. Management becomes facilitative rather than command and control.
This guidance assumes that the reader already has some experience of programme management and a programme management method. It builds on that knowledge to show how those involved in programmes may need to think, act and react differently in an Agile environment. At the same time, it is self-contained in that it provides guidance for running Agile programmes, together with a complete programme lifecycle and product descriptions to support that lifecycle.
A potential structure of an organisation’s initiatives can contain portfolios, programmes and projects.
The portfolio will itself consist of portfolios, programmes and projects. The portfolio is created because the organisation has a reason to collect the subset of initiatives together, perhaps for control, budgeting, area of business or other reason. There is no specific single version that the subset is to fulfil.
The programme is formed to achieve a specific vision and is the focus of this guidance. As defined “a temporary, flexible structure created to deliver outcomes and benefits related to the organisation’s strategic objectives by driving, monitoring and coordinating a set of related projects and activities.”
The project is formed to deliver specific outputs to the business. As defined “a temporary structure created to deliver one or more outputs that contribute to one or more capabilities.”
Anyone involved in Agile programmes will benefit from the guidance.
Philosophy
The Agile Programme Management philosophy is that an Agile programme delivers what is required when it is required – no more no less.
Principles
Five principles support the Philosophy. They direct those involved in the programme in the attitude they must take and the approach they must adopt in order to ensure a successful outcome of an Agile programme. These principles are:
• Programme goals are clearly and continuously aligned to business strategy
• Benefits are realised incrementally and as early as possible
• Governance focuses on creating a coherent capability
• Decision-making powers are delegated to the lowest possible level
• Agile programmes are iterative and have the ability to contain both Agile and non-Agile projects
Lifecycle
The Agile Programme Framework includes a programme lifecycle. The lifecycle includes the six phases:
• Pre-Programme
• Programme Feasibility
• Programme Foundations
• Capability Evolution
• Tranche Review
• Programme Close
Roles: Responsibilities and Characteristics
An Agile Programme may have both Agile and non-Agile projects as part of it but will have at least one Agile initiative. The structure of the projects in relation to the Agile programme should reflect the governance model defined for the programme. This means that project governance layers such as project boards or steering committees become subsumed into the programme governance.
Each programme-level role is described. When defining a Programme Management Team, there are certain Agile leadership characteristics that all members should possess.
• A role in a programme can comprise one or more individuals, and sometimes an existing organisational group
• An individual (or group) can take on more than one role in a programme
Programme Management Team
Roles are Business Programme Owner, Programme Manager and Business Change Owners _ the directors, managers and coordinators of the work for the programme. They may be part of a programme board or steering committee and, collectively, have authority to direct the programme. They are responsible for the governance of the programme, liaising with corporate management outside the programme.
Capability Delivery Team
Roles are Stakeholder Engagement Coordinator, Programme Change Architect, Programme Technical Architect and Project Teams. These roles respectively deal with stakeholder engagement and commitment, business architectural design and consistency, technical design and consistency and delivery of the outputs that enable capabilities and undertake enablement activities.
Supporting Roles
Specialists, Change Agents and Programme Support Office – provide assistance and guidance to the project on an ad hoc basis throughout the lifecycle. Each role is described in detail.
Products
The DSDM Agile Programme Framework includes a series of artefacts that may be of value to the programme, the organisation in which the programme is running, or to the teams involved in the enablement of the capabilities.
DSDM Agile Programme Management identifies three distinct types of product:
• Evolutionary Products are initially produced in a specific phase, typically starting life as an outline. They then continue to evolve, becoming more detailed as the programme progresses
• Milestone Products are created in a phase and typically fulfil a specific purpose within that phase
• Foundation Products are the fundamental drivers of the programme. They are normally baselined during the Programme Foundations and set the basis of all programme activity
There are four products that are central to defining and driving an Agile programme. These are interrelated and emerge incrementally and iteratively, mainly during Pre-Programme, Programme Feasibility and Programme Foundations, with the main definition work being carried out in Programme Foundations
Initially, a Vision Statement will be produced. This will form the basis for the definition of the Business Architecture Model and Prioritised Benefits, which emerge in parallel. Development of the Business Architecture Model and Prioritised Benefits Definition will in turn clarify the vision. Once these are relatively stable, a Programme Plan can then be formulated. The Programme Plan includes:
• A Roadmap, describing how the organisation can progress from its current state to the desired future state in incremental steps
• A Benefits Realisation Plan, describing the incremental realisation of benefits that is aligned to the steps in the Roadmap
The Programme Plan will only be in outline at the end of Programme Foundations – the first steps may be fairly well defined but future steps will be less certain and may change with experience from the earlier stages. Formulation of the Programme Plan will in turn potentially create feedback that updates the Business Architecture Model and Prioritised Benefits and possibly the vision.