WaterScrum: Co-dependent Waterfall and Scrum projects
Wednesday, 1:30 session
Host: Kevin Neher (kneher@microsoft.com)
The purpose of this session was to discuss how people are dealing with using Scrum for projects in organizations where not every project is Scrum and you have to develop in some sort of synchronization with other Waterfall projects. We call this "WaterScrum" and equate it to trying to play two sports on the same field at the same time, e.g., baseball and football. Clearly there needs to be some rules of engagement and good coordination to avoid mishaps.
This session had several diagrams, and I'll try to get some form of them up here at a future time.
We started by defining two basic models of dependency:
A. a Waterfall project that is dependent upon a Scrum project for delivering some subsystem that it calls
B. a Scrum project that is dependent upon a Waterfall project for delivering some subsystem that it calls
Beyond these two models, we acknowledged the possibility that both systems may call each other. Also, there is the possibility that instead of being distinct systems which call each other that the one project is making a portion of a system that is directly included into the other project's code.
One additional factor is timing. The two co-dependent projects may or may not start at the same time. For starters, we'll talk about the issues as if they did start at the same time, and then look at time shifts (both from the perspective of using that as a solution to problems and what new problems it introduces)
Model A: Waterfall consuming Scrum
Issues:
-> Requirements from Waterfall project to Scrum project come in after the start of the Scrum project. While this can be considered normal for a Scrum project, there can be impacts on the original commitment of the Scrum project if, for instance, many more sprints are necessary to achieve the total package.
-> The Waterfall project is used to locking down it's design at the end of the Design phase, but the Scrum project's design continues to evolve/emerge over the course of the sprint, in priority order. Thus some aspects of the Scrum project design may not be locked down or complete at the time the Waterfall project needs to lock. Solutions discussed: define the integration interfaces in early sprints, even if some of those features may be lower priority (and thus could in theory be cut later). This is a compromise.
-> An advantage over two Waterfall projects (depending on size and timing) is that the Scrum project would deliver fully functional parts of the system much sooner, making it easier to code and test the consuming Waterfall application.
Model B: Scrum consuming Waterfall
Issues:
-> Requirements: here, the Scrum application requirements of the Waterfall subsystem may emerge as the sprints progress and as the Scrum product backlog changes. This can throw havoc into the Waterfall process used by the subsystem, making it much harder to start the Waterfall project early.
-> At the same time, the Scrum application would prefer to have working (test complete) pieces ready as needed by each sprint, but the Waterfall project treats the deliverable as a single end-game deliverable. This suggests that the Scrum project may need to delay starting (which runs counter to the requirements process above where the Waterfall project wants all requirements locked down up front).
-> In general, this seems like a much more troublesome model.
What Works:
-> Model A: really focus on all exteranl interfaces in first sprints
-> Model A: identify different levels of impact (e.g., the impact of a code change by the consuming application could be larger than the impact of only a regression test)
-> Model A: invovle the consuming application representatives on requirements as early as possible; consuming application representatives should be part of the sprint planning and sprint reviews
-> you need heavier cross-project planning with a mixture of Waterfall and Scrum projects
-> Model A: start earlier
-> intermediate drops (mid-sprint) (this is closer to doing daily integration as would be done in two co-dependent Scrum projects)
-> Model B: implement a phased version of the Waterfall project (increments of functionality in waves). Break down the waterfall project into smaller work packages and phases.
-> add contingency planning into the sprint planning
-> have a separate burndown of the Waterfall-related work
-> have the Waterfall project use hi-level requirements (rather than detailed requirements) to start
What Doesn't Work / What May Be Problematic:
-> Artificially moving lower-priority items up in the product backlog if they are interface items that the Waterfall project wants locked down at Design stage could cause lost effort if later those features are deleted.
-> Users/customers still want/expect Waterfall-like artifacts and commitments from the Scrum project. There can be a mismatch in expectations.
(Terminology: WaterScrum vs. Scrummerfall
WaterScrum: co-dependent Waterfall and Scrum projects
Scrummerfall: a Scrum project that really does mini-waterfalls inside each sprint)