Bridging the gap between waterfall and agile development

bridge-and-waterfall

What if you could bridge the cultural and stylistic divide between waterfall and agile development teams so you could speed your adoption of cloud technologies? One possible solution we’ve adopted in DXC’s AWS integrated practice is using an architectural sprint, or a sprint before the first real sprint – sprint zero, if you will.

This approach provides a stepping stone for waterfall development teams on the road to agile. At the same time, it doesn’t disrupt or slow down the agile development process.

The differences in style and culture between the two development models are apparent. In the traditional waterfall model, extensive planning is done upfront, projects are broken up into specific phases, and work proceeds sequentially until the goal is reached. A waterfall development project could take a year or more to complete and after all that time and effort, the business unit might not even be happy with the result.

In agile development, upfront planning is minimal, coders start their design work on Day 1. Work is divided into short sprints that can last less than month, and there’s constant feedback from the product owner, triggering new iterations. For some traditional waterfall developers, this can feel like “flying blind.”

With an architectural sprint, the product owner provides enough information so a senior developer can write up preliminary specifications or designs that get put into the agile development backlog.

So, instead of over planning (waterfall) or not planning enough (agile,) you’re planning just enough to provide developers with the best of both models. Everybody is on the same page, developers from both worlds are comfortable and we all move forward.

This architectural sprint could be as short as a week or two, but it provides tremendous value, helping establish guardrails that can help waterfall developers make the leap.

Using the architectural sprint or sprint-zero technique, the product owner takes requirements from the customer and delivers them to the software engineers through a project specification template that might include details like what pieces of software will be needed, what language will this be written in, how many developers will be needed at what levels of expertise, etc. The template is then put into the backlog for customer validation and feedback.

The benefit of this approach is that it allows companies to make a smooth transition of their existing workforce to the agile methodologies that deliver the velocity customers require.


Ken Edwards is a senior manager in the Global AWS Integrated Practice at DXC Technology, responsible for product development. Previously, he was director of engineering for Hewlett Packard Enterprise. Ken is a software engineering leader with an excellent track record of building amazing teams and fostering a engineering culture that focuses on solving complex problems and work-life balance. He holds a BSS in Computer Science from California State University, Chico.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: