Today, many air traffic management (ATM) system modernisation programmes still follow a V-cycle engineering methodology and are organised into several sub-projects, each working relatively independently of each other. Experience has shown that in ATM environments, this can lead to escalations in project timescales and costs. Egis experts explain how and why an ‘agile’ approach can help.
ATM modernisation programmes are complex, based on the deployment of one or more complex systems, often derived from commercial off the shelf (COTS) products and difficult to evolve due to safety standards and certification requirements. Added to this is the difficulty of deploying the same system or group of systems for different air traffic control agencies with parameters, constraints, needs and requirements that are sometimes very different from each other.
In V-Cycle you define something at the start of the project and then work for months (even years) without being able to show the results, leaving people in the dark, something we call the ‘tunnel effect’. In addition to this, the typical problems encountered are:
- The need for system supplier involvement to improve overall cooperation but also for supporting the supplier at different levels (methodological, technical, documentation, etc.) to liaise with the sites Air Traffic Units and implement the system, especially when it needs to integrate with a pre-existing system or integrated in a pre-existing context.
- The lack of visibility on the progress or production of duplicates (or the omission of certain elements) due to a lack of coordination and information sharing within the programme and sub-projects.
- The fact that multiple activities are launched and carried out in parallel (workshops, features to be specified/implemented/tested, etc.), creating frequent (if not too frequent) context changes for the teams involved to achieve convergent progress across all activities.
- Finally, some transversal issues, cross-cutting to several sub-projects in one programme, do not seem to be addressed or tackled until it is too late.
At the same time, the aviation world is increasingly looking for new processes to deploy value as quickly as possible, providing management with a good level of visibility on project progress, being economically and humanly sustainable, and involving all players in integrated teams – from end user to developer.
The challenges of a new approach are therefore to increase collaboration/cooperation at all levels (from industrial to end-user), while ensuring compliance with commissioning deadlines as well as the efficiency and value of what is produced.
Agile development methods are based on a group of iterative methodologies, where requirements and solutions evolve through collaboration between self-organised multidisciplinary teams. These methods encourage frequent inspection and adaptation, a leadership philosophy that emphasises teamwork and accountability, a set of best engineering practices to enable the rapid delivery of high-quality software, and an operational approach that aligns development with customer needs and business or project objectives.
The Agile Manifesto includes the following principles:
“The highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
“Business people and developers must work together daily throughout the project.”
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
It should be noted, however, that although the Agile approach can be used for short development cycles on a system, it is not always possible to deploy this system at the end of each cycle because it may not have the minimum functionality to be operationally usable.
Recent experience with the purchase of COTS systems and the application of the classic V-cycle development have highlighted the difficulty of mastering the planning, costs and content of the developed systems. It’s against this background that forward-thinking engineering teams in aviation are moving to Agile development methods.
Two examples of Agile in practice
One ATM customer decided to apply the Agile method to replace a flow management tool. The process was simple: every six months maximum, a new version of the tool had to be installed in several en-route control centres, first in testing and then, once the system was deemed mature, by operational users. It took only two years become operational in the en-route control centres despite their differences. Since then, new versions have been developed and put into operational service every six months.
Our role in the project was to create, maintain and prioritise the “functional agile backlog”: ie provide a common vision in Agile format of the needs and priorities of control centre operations, all in line with the strategic objectives. We also provided support to the “Scrum Master”, liaised with the system supplier so that they can propose a solution in line with future expectations and helped the project manager build an Agile roadmap by equipping him with the right Agile tools and team support.
Another customer used a scale agility methodology called SAFe (Scaled Agile Framework) with international and remote teams to successfully deliver remote services within three years – meeting deadlines and budget. For this customer, a single Agile train was set up that paces and synchronises the production teams, who are themselves operating in agile mode. Compared to Scrum or Kanban Agile methodologies, SAFe includes a program-level layer that organises synchronisation between teams by setting the rhythm of work through pre-defined iterations and common objectives.
Our engineering teams adopted a range of roles to support the project: at the program level, as “Product Manager Proxy,” to define the program-level backlog, prioritising the list of activities and ‘feeding’ the program teams. And at the Agile team level, by working on transversal topics, thus ensuring definition and consistency on the overall system definition (architecture, technical choice, etc), as well as on the technical specification and system level validation. We also supported the development teams working on each component or business group, to ensure the system behaved in line with customer expectations.
No silver bullet
We know from this experience, as well as from the application of Agile in airport and avionics environments, that Agile can make a real difference. So, why was it not adopted sooner and more widely for aviation system transformations? The answer lies partly in the safety-critical nature of aviation systems. When safety is paramount, decision makers need to be sure that components will pass safety tests and that safety can be assessed. The safety aspect is an ongoing (but not insurmountable) challenge. Another factor is that Agile methodology in inexperienced hands can translate into ‘rushed’ implementations that lack direction. It is vital to ensure that there is a clear and agreed vision for the end results before embarking on an Agile development. And finally, when the deliverables are iterative it can be difficult to tie down contractual requirements. Again, this is not insurmountable.
Agile and integrated
Being integrated into customer teams on long-term projects has enabled our engineers to share best practice experience from outside the organisation and apply that know-how appropriately and effectively. Increasingly, our teams are applying Agile approaches to the engineering challenges they face, because the results speak for themselves: faster implementation, reduced costs, objectives met. That’s why customers like DSNA, Airbus, skyguide and ADP choose Egis to support their system transformation projects.