Smarter ideas worth writing about.

Agile Teams in a Waterfall World - Part 3: Coordinating Development & Releases

Tags: Agile Enablement , Collaboration

This is the third post in a series of blog entries on how to begin establishing your agile teams in an environment that is predominately still waterfall. Posts in the series include:

Coordinating development and releases between agile and waterfall teams
As is the case whenever two or more teams need to work together on a single development package the key to coordinating development is to have the teams agree on how the dependency will be handled. The approach selected will be dependent on technical issues of the system being worked on, including how tightly integrated the various pieces are.

We also need to deal with the difference in release schedules between the two types of teams. Where agile teams complete a development cycle and have a potentially shippable increment after every sprint, waterfall team development cycles and releases are typically months long. 

There are several different approaches we can take to take these factors into account when agile and waterfall teams are working on an integrated package:

1) De-couple the dependency by developing backward compatible code

If possible you can develop your code to work with the new requirement while also working in the original way. For example, if you are responsible for adding a new feature to a service call that allows users to enter new fields on a call, develop the software so that it functions as usual if someone calls the service as before, and handles the new fields when the new version of the service call is issued. This allows you to deploy the update to the service call at any time, as long as the deployment happens before someone starts using the updated service call. This is an especially effective method if the code being released is called by many systems. You avoid having to do a lot of software releases in a ‘big bang’ mode. At some point you should re-release the code with the old logic removed to keep the code clean.

2) De-couple the dependency by developing code that can be turned off and on without a release

If you can’t make the code backward compatible you may still be able to de-couple a tight dependency by using a setting to disable / enable the new functionality. In our example of a change to a service call you could write your system to check the value of a system flag before determining what code to execute (old code vs. new code). Initially you would deploy your updated system with the system flag set to use the original service call. Then when the waterfall system is ready for their release you switch the flag to enable the new service call. Again, at some point after this release you’ll want to go back and clean out the original service call logic from your system for maintainability.

3) Align development and release schedules

If the dependency between teams can't be worked so that code can be shipped independently of the other team the agile team will likely need to adapt to the waterfall team's schedule for that release. Depending on the waterfall team's overall schedule, this could involve delivering a sprint to an Integration and/or UAT environment for several weeks of testing before it is actually released to Production. With this approach it is also important that the two teams keep in contact with each other throughout the process.

The agile team will also need to coordinate testing with the waterfall team. A good place to do this is in Integration Testing. The waterfall team will need to ensure their code works with the agile code doing Integration testing. This means the agile team will need to time the sprint to be in line with Integration testing on the waterfall team. Since Integration and User testing will likely run across multiple sprints for the agile team they will need to avoid deploying this new code into production until user testing is complete. The agile team will need to split this software into a separate code stream while they continue on with other development. Any defects found during Integration and User testing will come back to the agile team as new stories, which will need to be worked in sprints before the release against the appropriate code stream. The agile team will need to be careful to merge code streams back together once the combined release is in production.

If possible the waterfall team could also release packages of their code during development. This would allow for some early Integration testing with the agile team that could uncover system problems for either team earlier, reducing defects earlier.

If there are other processes you’d like to see addressed in these posts, please leave suggestions in the comments.