Smarter ideas worth writing about.

Agile Teams in a Waterfall World – Part 2: Coordinating Requirements Between Teams

This is the second 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:

In this post we look at how you can coordinate documenting requirements that cross between agile and waterfall teams. The ideal situation is that a requirement for a team is self-contained and can be done completely by that team, whether it is agile or waterfall. In reality we will see times where a team will need to coordinate with other teams to get a project or story done.

There are 2 scenarios for how coordination between agile and waterfall teams will need to work:

1. A requirement for an Agile team is dependent on development done in a Waterfall team.

In this case it is important that the agile team identifies this dependency as early as possible. Ideally this would come up while the story is being refined in a Backlog Refinement meeting, long before the story is pulled in to a sprint. Normally an agile team will refine stories just before pulling them into a sprint. This helps to reduce waste that would be caused if time was spent on a story that was subsequently removed from the backlog as no longer being needed. This will need to be balanced against the need to identify requirements for a waterfall system far enough in advance to fit into their development cycle. A good practice here is to identify that a story has external dependencies when it is created (or soon after). Stories that don’t have an external dependency can wait for refinement. Those with an external dependency need to be refined farther in advance.

When the dependency is identified the Product Owner works with the Business sponsor for the waterfall team to get the dependency added as a requirement into the waterfall team’s requirement tracking system, and to negotiate when that work will be done by the waterfall team. The agile story is then updated with information on how that requirement is being tracked by the waterfall team (e.g., the requirement ID). As that story moves up the backlog the agile team verifies that the waterfall team is moving towards the agreed on time frame for the requirement. The Product Owner plans for that story to be worked in the appropriate sprint so that the story can be properly tested.

The waterfall requirement coming from the agile team may not contain as much detail up front as the waterfall team is used to getting. This is a remnant of an agile story typically having “just enough” detail to get started. The agile team will need to add additional detail to the story when the waterfall team is ready to begin work on it, even though the agile team itself may not be working on their piece of the requirement for many sprints. The agile team will also need to adapt to the waterfall team’s requirement documentation standard, for example screen layouts may need to be generated earlier than would usually be done for a pure agile story.

2. A requirement for a Waterfall team is dependent on development done in an agile team.

In this case the waterfall team will talk to the agile team’s Product Owner to request that a story be created in the agile team's backlog describing the work needed and when it is needed. The project sponsor negotiates which sprint to include the story in with the Product Owner. As the waterfall team goes through their analysis and design phases they may provide additional details to the agile team on what is needed in that story.

In both cases we want to use the existing requirements management system for the team impacted. For agile we add a story to the product backlog that team is working from and work with the Product Owner to prioritize the story appropriately. For waterfall we document a requirement (project, change request, etc.) and ensure the business sponsor prioritizes that requirement. In either case, consistency is the key. By fitting into the system already in use you minimize any disruption a special request could cause.

Once requirements have been documented and a development timeline established the teams will need to coordinate how development, testing, and releasing of code that is going to happen between the agile and waterfall teams. The next post in this series deals with those issues.

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