Scrum Integration with Waterfall Teams

Scrum works very well within its own construct, but when dependencies arise with teams that practice Waterfall, it can be tough to get the work you need on the docket in a timely fashion. Here are a few pieces of simple advice to make integration go more smoothly.

1. Always do look-ahead planning: Waterfall teams, especially large production support and enhancement teams, have very large demand queues and usually finite resources. By having a release plan/roadmap that is up to date, the Waterfall team can be notified early (ideally as early as possible – multiple iterations out) of work needed to be done and it can be added to the demand queue and resources can be allocated earlier. This isn’t to say that all iterations for the release should be completely planned out, but a release plan/roadmap will provide a rough idea of when certain functionality and features will be needed. It is advised to look a few iterations out at minimum and identify dependencies, but for integration with large systems I’d advise starting to think about it much sooner rather than later.
2. Have requirements ready: When you start talking to Waterfall teams to get estimates, they’ll likely ask for more details about the specific user stories or tasks than you have, especially if you’re looking ahead a few iterations. I’d suggest making time within the current iteration for look ahead planning. This way the some basic requirements can be gathered in the iteration, and as they’re being gathered, they can be passed on to the Waterfall team. If they need more, try to get them more without providing a full blown detailed plan – give them just enough to get started.
3. Constant Communication: Most likely the Waterfall team won’t be updating tasks in your project workspace. They have their own metrics and ways of tracking their work. Make sure to set clear expectations on how you want them to report progress and issues with the Scrum team/PM. Once plans are finalized and development is starting it can be difficult to keep track of where development is. Try to utilize whatever reporting tools or status processes they’re currently using. It’s not your job to turn this team Agile; by keeping things consistent you’re likely to get more meaningful status reports and updates.
4. Invite to sit at the table: I encourage teams to invite other teams to sit in on their release and iteration planning meetings, even stand-ups to observe and participate in. This will allow the other team to see how you’re working and where their work fits in. They may even find value to sit in the team rooms to get more requirements when doing development. Don’t force this but definitely make it an option. Maybe they will come up with the idea on their own.
5. Prepare for change: Things in Scrum projects are encouraged to change to respond to business value and priority. This expectation needs to be set upfront to the Waterfall team so it doesn’t come as a total shock if a piece of scope is added or removed. By anticipating things will change it’s less likely to be a showstopper when it happens. Does that mean it will be easily accepted? Probably not, but at the end of the day, it’s all about getting the work done that you need done for the Scrum project dependencies to deliver business value.

It is always challenging to integrate with other teams, but by preparing and planning up front (most likely more than Scrum advocates) will give you a better idea of when the work can be done and will preserve relationships between teams that need to lean on each other.