We spoke to CCS team members,  Valentina Piccinelli, Fabrice Boutet and Laura De Stefani to find out how the AGiLE approach has changed the way they work, and the impact it has on the CCS project. 

Could you start by introducing yourselves?

Valentina: I work in Rome for ENAV in the Technology Department. In a traditional approach I would be the Project Manager of CCS. In the AGiLE terminology I’m the AGiLE Release Train engineer with the responsibility of supporting and coordinating the different teams to achieve the CCS objectives, step by step.

Fabrice: I’m in charge of the development of the provider gateway used to connect Coflight with the customer. I work in Toulouse for the DSNA, at DTI. I’m in charge of SCALP, the main component of the provider gateway, and I’m in charge of the 4-Flight simulator.

Laura: I’ve been a consultant for ten years for the International Activities and Technology Department. I am the deputy RTE engineer of the CCS project, which is similar to a project manager in a classical organization. My role is to lead the train so we try to focus on where we have to go, how and when, to remove any impediments, and generally facilitate coordination between all teams.

How does the AGiLE method work at CCS?

Valentina: There were lot of expectations regarding CCS, an innovative program involving 3 different ANSP with a year and a half to implement the STEP 1 activities.

The customer needs were not all fully detailed at the beginning of the program due in part to the interdependencies with programs such as SESAR or SWIM.

We wanted tangible results quickly, so we moved from a traditional waterfall approach to an AGiLE development one, to build the CCS solution iteratively and incrementally, through “program increments” or PI.

We deployed the Scaled agile framework which involves a CC Program Backlog with a set of macro activities or needs from the customer, and we organized the available time into 5 PI, in which we injected part of the backlog. Each PI was then organized into a short five week timebox called “Sprint”  during which a complete lifecycle is implemented (specification, development, testing). The process and the team are organized to follow this approach. 

Laura: At every sprint, we actually have something, a little part of software, that works. And we get feedback very quickly with every increment, with a real product at every moment. 

How has the methodology changed how you work?

Laura: I would say the very high level of involvement of all the teams, requirement, validation and software developers in all project phases with the management team.  We meet once a week in short, informal, pragmatic meetings to address what is happening together, discuss each deadline, any problems, and the plan for the next picture. The Customer is always involved and at the same level, he is really part of the project with full transparency. This fosters strong team engagement.

Fabrice : It is also very important in terms of bug management. It enables us to correct many issues very quickly in a very short time and It is very effective to improve the quality of the software and manage priority correction. It is very new to be able to choose what is most important to correct, to allow more validation. I think this is a crucial aspect of the method and a main optimization of our development. At the end of step one, we had very few bugs because we were able to correct them as we went along. We adapted the functionalities and the evolution relative to bugs in the specification too.

Valentina: It was a significant change for me as I shifted from Project manager to Release Train engineer or RTE, who is the servant leader and coach for the AGiLE Release Train (ART). The RTE is  responsible for facilitating ART events and processes and assisting the teams in delivering value. We communicate with different actors, escalate impediments, help manage risk, and drive relentless improvement. facilitating and continuously aligning a large development program.

Both PM and RTE are management roles – the difference is that PM manage resources and are primarily responsible for delivering the product in a timely and cost-effective manner, which sets their focus on keeping to a set budget, schedule, and scope.

What were the challenges involved in implementing AGiLE?

Valentina: It was not an easy task, especially in the first phase, because we had to change our mind set, moving from a traditional to more flexible, agile approach. Most of the people working in the project had no direct experience in the methodology, me included. Additionally we needed  proper collaboration and coordination tools for planning and monitoring activities.  

Fabrice: Yes, it took about a year to really work efficiently. We were working with four or five teams in different countries and languages, and three organizations, and we had to adapt the methodology to our needs and constraints. It was a very big challenge. 

Laura: The approach is usually for small projects and teams, but we adapted it to a very big project and complex organization, and now it is working really effectively.
Another challenge is that with two teams developing software, one on the provider side and one on the customer side, they need to be perfectly aligned and synchronized because at one point you have to put the two software together without errors…..

Fabrice: Yes, you mention development but it is also important for both the definition and validation teams. In fact they are integrated in the SPRINT method and I think this is incredibly valuable because all the development loops are integrated in the AGiLE method and all teams work together to achieve a real target. While the development part is especially important, with many people involved, definition and validation are also key aspects to optimize the project build. 

Laura: In addition, CCS is always aligned with the SESAR project, in particular with Project 16.03, a European initiative providing standards and requirements. This means CCS is a standard product that respects requirements from Europe, but it was also challenging because we had to inject inputs from other projects. 

What are the benefits?

Valentina: I see a lot of positive points. The risk of rework is reduced with the collaborative approach which gives an active role to the customer as part of the team. And getting feedback very frequently means you solve issues a soon as they come up.

The organization based on small timeboxes is helpful for monitoring and allows the flexibility to make the needed adaptation in due time. Then the autonomy of the team fosters genuine engagement.

 I appreciate that the RTE is frequently in touch with the team and collaborates as a supporting figure, rather than a traditional management one.

Fabrice: With AGiLE, Customers have excellent visibility on the work being done on the product, discovering new functionalities incrementally every five weeks. There is a lot of exchange at many levels and it’s very enriching: developers meet the management and definition teams and this is a key advantage. It has been very satisfying to meet new people from different countries and to learn new ways of working.

Laura: As the teams are so involved together from the start in the planning and decisions, rather than acting as separate units, it is much more likely to be a realistic plan and in the end you have something that is achievable.

In particular I appreciate the AGiLE custom of holding a confidence vote session at the end of each Plan Meeting when we all stand together and vote about how confident we are that we will respect the plan we made. Sometimes there are thirty people present! Naturally we discuss the result. It seems a small thing, but it creates a really high level of team commitment and understanding.

How did the AGiLE approach shape your response to the lockdown?

Laura: Confinement changed very little in terms of how we work: we were used to working with Webex and other collaborative tools  from different places….

Fabrice: Yes and I think that the approach during confinement and the restart (on going) is an important element that has allowed us to limit the consequences.

The sudden drop in our development capacities forced us to quickly review the content of our sprint without any visibility as to recovery. We kept the same pace for the sprints (5 weeks) and were able to quickly adapt their content as the situation changed (adaptation of the development means working at home, taking into account new instructions etc.).

Finally there were 3 sprints involved during the confinement period and in terms of production we lost only one.

Valentina: there are some key events where the F2F meetings are really the best option. This is the case of the Program Increment  (PI) Plan Meeting in which we agree on the list of activities to be done for the next period (it is a kind of kick off meeting but more interactive). Thanks to the experience and the long term collaboration among the different teams, we could organize a remote PI Plan with quite good results. In general developing by sprint with small content and very defined objectives helped to limit the global impact, this is also thanks to the flexibility of the development team to adapt and rearrange activities.