Going Agile in FP7 research projects

(This post is a summary of the material I had the opportunity to present at EGI TF Lyon 2011, thanks to Marc-Elian, check it out)

Three years ago, I had the fantastic opportunity to study the confluence of Open Source community developments and large enterprise Agile setups at Ericsson. It was tough work but very fun. A year later, at i2CAT Foundation, we where kicking off the Mantychore FP7 project. Mantychore FP7 is a quite software intensive project, with ambitious NaaS objectives. Beyond that, the project also presented an interesting project management challenge itself: it was meant to be run as a consortium-wide SCRUM implementation. Later on, we could re-apply lessons learned to the RAISME Fp7 project, and learn a bunch of new ones. In this posts I’ll try to provide an overview of the lessons learned with the hope that it will helps others draft and run better and more successful research projects.

An innovation project is a perfect candidate for an Agile methodology:there is a lot of uncertainty, users available and eager to deploy, unplanned liaisons, etc. However, the very same nature of Fp7 program projects is make them a very arid place for agility. Some examples:

Individuals and interactions over processes and toolsFp7 projects are done by collaborative consortia distributed all over Europe. This often leads to distributed development teams, shared dedication spread over a 30 months time line.
Working software over comprehensive documentationDeliverables and Milestones are the primary tool the EC uses to track the progress of a project. Unfortunately documentation deliverables and milestones are a one-shot snapshot of the state of the project and do not match well with evolving documentation.
Customer collaboration over contract negotiationYou probably have your end user as part of the consortium. You also have a contract, not with them, but with the EC. This can get twisted.
Responding to change over following a planFp7 projects are approved and executed over a work plan. The central axis of this work plan is a Gantt chart that coverts a 20-30 month time line. To make matters worst, there can be almost a year of delay between the final Gantt draft and the actual start of the project. If you want to iterate, you’ll have to iterate on those constrains.

But don’t lose your hope. Agile in an Fp7 can be done, with good results.

However, there is one advice I would like to arise over the top: talk to your Project Officer. The Agile way of working is counter intuitive to the straight FP7 project orientation and you’ll need his buy-in. Make sure he understands what you want to do and the benefits of it. You’ll need him on board.

The Work Plan

As said above, you will have to operate agile inside the constrains of the work plan. In that regard, the project will only be able to properly iterate when this 3 tasks happen concurrently:

  • Requirements elicitation and refinement.
  • Development.
  • Deployment and user feedback.

In Mantychore Fp7, deployment is a complex tasks that involves specialized personal and expensive equipment. This is why we consider a task on its own, apart from requirements elicitation and refinement. Your mileage may vary here, but in any case, they both fall under Product Owner’s responsibility.

With that in mind, classify your projects work packages and tasks in three groups:

  1. Those who you want out of the iteration loop (management and dissemination work packages, most probably).
  2. Those who evaluate releases (generate requirements and feedback).
  3. Those who contribute to releases (architecture, design, development, etc)

Mantychore FP7 work plan task classification

 

Then, let’s analyse the second and third groups in detail, as they are the ones that fall into SCRUM scope’s:

Product Owner Committee

Consortia are complex to manage and the project will most likely need a Product Owner committee. Consider having a face to face meeting just to bootstrap this committee. Even if expensive, the shared vision and momentum such a meeting will bring can save a lot of trouble and waste of efforts later. Take into account that partners come from very different backgrounds and may have divergent visions and expectations on the project outcomes.

Still, there must be a single person appointed as Product Owner that provides a single point of contact, specially in front on the development team. An unresponsive Product Owner can severely impact the project performance. Availability, as well as familiarity with project’s vision, should be the key indicators to decide who it best fitted to take this role.

The Product Owner is responsible of the project road map. When other projects or institutions get interested in one of your outcomes, the Product Owner should be the one giving them realistic estimates, not the development team. If these institutions get interested to the point where they would like to contribute requirements and feedback, the Product Owner can invite them to the Product Owner committee.

Development Teams

The third group will be composed of the different development teams. Here you will want to have as less fragmentation as possible. While this is not something that can be easily avoided, distributed development has always a high performance cost. Be aware of it.

You might be tempted to join all the developers from different organizations into a single distributed team. We have found this to be a bad idea, sprints will be dragged down by communication overhead. Moreover, a team is, by definition, a group of people with shared goals and objectives. According to your project’s description of work, each organization will have defined different complimentary goals. Treat every organization developers as an independent team, fully responsible of their own sprints, even if it is just one person, or half.

You should also identify the main development team. This is the one that is central to the development, will take care of integrating the different parts and, most likely, concentrates most of the effort. You will need the Scrum Master to be there. Two thirds of implementing SCRUM is coaching the team into it. Having a Scrum Master that is co-located with the team and spends time with them is key to success.

Before we move into the Scrum Master role, let me emphasize the importance of having a consortium-wide demo. The Product Owner, and any interested end user, should join the team over a video-conference to inspect the latest release and provide feedback.

Scrum Master

Co-locating with the main development team and knowledge and experience with SCRUM are key characteristics for a successful SCRUM master. However, unlike a regular industry settings, his work cannot remain purely indoor.

Most likely, a big part of the consortium will not be familiar with development methodologies or the Agile concepts. A big chunk of the Scrum Master’s role will be teaching other institutions to interact on an Agile way, both with the development teams and among them. If this can be challenging inside a company’s four walls, a consortium can take it to the next level. For this reason, it is important that the Scrum Master holds a position in the project with both visibility and authority to perform such task. In Mantychore FP7 the Scrum Master happens to chair the TEC, who supervises work package progress. Two responsibilities that certainly go well together.

Deliverables and Milestones.

The key difference between FP7 and Agile is a different risk model. Projects are monitored for sticking to a contract made of deadlines, while Agile proposes an exploratory and evolutive approach. Specially difficult are those deliverables that are closely tied to the iterations, like requirements documents or user manuals. In those cases, the deliverable will become a snapshot of the document at a given time.

An approach that Mantychore FP7 is implementing is a set of Key Performance Indicators. They show the evolutive nature of key project aspects, while providing to the EC the monitoring capabilities they need in order to ensure the proper investment of public funds. However, a KPI implementation is complex and out of the scope of this post.

Whatever you do, make sure you are at par with the Project Officer!

About Joan A. García-Espín

M.Sc. Joan A. García-Espín (joan.antoni.garcia@i2cat.net) is the Director of the Distributed Applications and Networks Area (DANA) of the i2CAT Foundation. He received his Telecommunication Engineering degree from the Technical University of Catalonia (UPC) in 2007. He wrote his Master Thesis in design and implementation of TE-enabled, DiffServ-aware MPLS networks for providing end-to-end QoS, also in 2007. He is a PhD candidate in the Telematics Engineering Department of the UPC. He is currently working in European projects FP7 GEYSERS (WP3 Leader) and GÉANT3. He has also participated in various European projects such as FP6 PHOSPHORUS and FP7 FEDERICA, and national (Spanish) projects including Enigma, Enigma Enhanced (Enigma II) and E3MS. He owns experience in optical networking, dynamic switching and management systems for networks, QoS and DiffServ for MPLS networks and infrastructure virtualisation. He is an active contributor to the NSI-wg and ISOD-rg gropus in the Open Grid Forum. His main research interests are cooperative agent interaction for network service provisioning, infrastructure virtualisation and network resource sharing and allocation.
This entry was posted in Ongoing Projects, Projects, Software. Bookmark the permalink.