Projects are agile. Programs must become too
In digital transformation’s times, companies frequently struggle with the difficulty of piloting in agile mode their program. The program must coexists with traditional projects (Plan-Build-Run), application development projects (products) by agile teams, study projects, deployment phases affecting large populations, general management governance subject to the budget cycle, without mentioning the rate of reporting to shareholders.
In recent years, methodologies (such as SCRUM or KANBAN) have been developed to support projects in agile mode. They are based on principles such as:
Prioritization of high added value needs by the “customer” (User Story)
The delivery at regular intervals of a functional product (Sprint)
An organization of the project team aiming at a strong autonomy and a strong collective weight (Agile Team)
Une approche et des rituels favorisant l’amélioration continue de l’équipe (Vélocité )
[See Manifesto for Agile Software Development].
But at the program level, difficulties arise
A team operating in agile mode benefits from strong flexibility and autonomy of the product to be delivered. The aim of this autonomy is to allow the delivery of a first version of the functional product (integrating the main basic functions) and thus optimize the ROI. However, within the framework of a program, the different products are part of an overall objective for which there are functional, temporal or resource interdependencies.
For example, how to position in the roadmap of product A (backlog) the non-priority functionalities for this product A but priority for a product B? How to coexist date imperatives (hard milestone) for example for deployments or training when the agile logic is rather sequential and progressive? How to guarantee that a budget is delivered for the delivery of a set of pre-defined functionalities?
The agile approach is confronted with difficulties external to its functioning: global constraints linked to the interdependencies of projects / products in the case of a global program and the traditional functioning of companies, in particular at the level of management committees, used to working with financial and time commitments.
How can these two philosophies coexist in order to guarantee the delivery of the main deliverables of the program? Should an agile team commit to delivering a product with a minimum functional scope defined on a certain date, or should a management committee work with a project scope that may change regularly? The solution necessarily involves a compromise.
Feedback from support in recent transformation programs has enabled us to identify 3 key success factors in delivering a program of projects in AGILE methodology.
3 keys to guarantee the delivery of a program of projects in AGILE methodology
1. Limiting technical complexity upstream
This axis is essential to limit the uncertainties and risks regarding the delivery of the main elements of each project or product. We have often seen that too many projects or product developments start their sprints without the technical prerequisites being sufficiently defined. Consequently, technical unknows are added to functional roadmap. Some of the prerequisites included can be:
• Validate and implement architecture principles and technical layers.
• Document data repositories, in particular those shared by the products to be produced.
• Define, implement and tested interproduct procedures and methods (API layer)
• Improve the skills in new technologies
This implies a scheduling of the program and sufficient phasing.
2. Establish coordination of Agile teams
In addition to the rituals to which agile teams are used to, it is necessary to set up moments of sharing and coordination of the teams among themselves. Different moments of meeting, short and interactive can focus on specific operational aspects in the same logic as agile rituals and articulated around a global roadmap built from product backlogs. For example, at a pace set on the duration of the sprints, a meeting could focus on functional prioritization in a similar way to a sprint planning. Thus, the scheduling of the delivery of the functionalities will be done in an optimal way so as not to block the delivery and the release management of the products.
To focus on the difficulties encountered along the way, a “critical path” meeting may focus on the operational difficulties linked to activities on the critical path; this meeting should follow the principles of a “daily meeting”. In addition to the usual actors from agile teams, other participants may be invited on an ad hoc basis such as architects, representatives from test, production, support units, etc.
In the event of disagreement, the agile teams must seek arbitration from an ad hoc representant.
3. Establish a committee capable of arbitrating and taking decisions.
This committee must have the flexibility of an agile team and be able to act quickly on the prioritization of its products and functionalities, as well as analyse the associated impacts and risks. Ideally, this decision-making committee could be reduced to one person: a “Super Product Owner”. In general, we met people carrying out this role but on a limited perimeter to a line of products. The scope of responsibilities and activities of a Product Owner for all of the products in a program level is very large. If the size of the activities and the level of responsibilities couldn’t be carried out by one person, an ad hoc committee must be set up. In this case the stake will be that of agility!
3 keys to set up in a way that is adapted to your business context.
Several methodologies such as Scrum of Scrum or SAFe have proven themselves to answer these problems. But since it is a question of making an Agile approach coexist with the program management habits of your company, it is advisable to cover the three keys to success by adapting a methodology to your context.
Nexance teams can support you in setting up a tailor-made system to support your company in managing its Agile transformation