Waterfall to Agile

Note: This article is updated at Waterfall to Agile.

As I help more people go Agile, I try to simplify the most important concepts.

For me, one of the most important changes in Agile is what it means to the product development cycle.

I think a picture is worth a 1,000 words.  I’ve put together a couple of simple visuals to show what it means to go from a Waterfall development approach to an Agile development approach.

Contrast the Waterfall Model with the Agile Model:

With these visuals, I attempted to show a couple of key ideas:

1. Waterfall uses serialized phases, where one activity doesn’t start until the previous activity completes.  Agile shifts to a focus on iterations, where each iteration performs activities in parallel (such as requirements, design, development, and test).
2. Each iteration produces a build.  Rather than wait until the end, throw something over the wall, and hope it meets expectations, the output of each iteration can be used to validate with users, as well as deliver incremental value.
3. By moving away from Big Design Up Front (BDUF) and way from Big Bang at the end, Agile helps to de-risk the project, respond to changing requirements, and flow value along the way.

If you need to keep up with the pace of change, deal with changing requirements, keep up with user demands, while shipping value faster, Agile might be what you’re looking for.

Comments

• Anonymous
  May 25, 2014
  I often use "mini-waterfall" which maps onto your agile process one micro iteration of waterfall (feature set) per value set. also the phases are overlapped and iterative, not serialised. both your agile technique and mini-waterfall fit in well with most project management techniques.

• Anonymous
  May 25, 2014
  @ Andy -- I think that's the key -- being able to work well with existing systems and approaches, especially project management methodologies. I've seen people get really confused between product cycles and project cycles.  Usually, I'll show people to just present a simple timeline of milestones to management as their "project cycle", and within that, they can have iterative "product cycles." This usually helps management buy in, since they see how it helps predictability, reduce risk, and flow value faster. Another important distinction I often need to make for people is that Scrum is an agile product management approach, while XP is an agile software development approach, and that together they are helpful. I find that Kanban is an easy sell to teams, but a tough sell to management.  It requires a significant shift from planning everything up front and pushing it out, to focusing on demand and pulling value through the system.  The "push" to "pull" is a significant shift for people that are used to heavy planning processes. For teams that have moves to "services," I think they quickly get the value of a Kanban approach to avoid overwhelm, and to focus on flowing continuous value, while eliminating bottlenecks in the system.

• Anonymous
  May 27, 2014
  "I think a picture is worth a 1,000 words" Not 1,024?

• Anonymous
  May 28, 2014
  The problem with Agile method is that it will become a mini-waterfall. That's the reason in our company we stopped agile methodology. Now we adopted the lean process which is really good. It keeps developers and testers always busy and work goes in parallel.

• Anonymous
  May 29, 2014
  @ B -- Sometimes ... even a billion. @ Vijay -- I think the power of Kanban is that it makes it easy to visualize and debottleneck your flow.

• Anonymous
  May 29, 2014
  The comment has been removed