Waterfall vs Agile

Get Started. It's Free
or sign up with your email address
Waterfall vs Agile by Mind Map: Waterfall vs Agile

1. waterfall / traditional

1.1. characterised by...

1.1.1. sequential stages

1.1.1.1. initiation

1.1.1.1.1. scope definition

1.1.1.2. requirements

1.1.1.3. design

1.1.1.4. implementation

1.1.1.5. delivery

1.1.1.6. maintenance

1.1.2. approval and sign-off between each stage

1.2. benefits

1.2.1. structured

1.2.2. change control

1.2.3. tracability

1.2.4. sign-off at each stage

1.2.5. good for

1.2.5.1. mission-critical projects

1.2.5.2. projects where failure would have BIG consequences

1.2.5.2.1. aerospace

1.2.5.2.2. medical / healthcare

1.2.5.3. fixed-cost projects (sometimes)

1.3. drawbacks

1.3.1. nothing delivered until the end of the project

1.3.1.1. if have to stop before the end, not much of value delivered

1.3.1.2. high probability that what is delivered is not what is wanted or needed

1.3.1.2.1. customers don't usually know what they really want until they see it

1.3.2. tries to identify all risks up front, but this is very hard to do

1.3.3. inflexible

1.3.3.1. makes change requests difficult / time-consuming

1.3.3.1.1. may affect everything upstream so far

1.3.3.2. hard to take account of external changes

1.3.3.2.1. market conditions

1.3.3.2.2. competitors

2. Agile

2.1. characterised by...

2.1.1. agile manifesto

2.1.2. small, quick iterations

2.1.3. start with the smallest, simplest working version

2.1.4. thinnest spike all the way through the process

2.1.5. incremental improvements

2.1.6. multi-disciplinary teams

2.1.6.1. BA

2.1.6.2. Dev

2.1.6.3. Test

2.1.6.4. UX

2.1.6.5. PO

2.1.7. new jargon

2.1.7.1. user stories

2.1.7.2. backlog

2.1.7.3. sprints / iterations

2.1.7.4. scrum

2.1.7.5. kanban

2.1.7.6. ceremonies

2.1.7.7. standup

2.2. benefits

2.2.1. working, usable software delivered early in the project

2.2.2. acceptance that risks are hard to identify up-front

2.2.2.1. agile approach tries to mitigate them in a different way

2.2.3. much more flexible approach

2.2.3.1. accepting of changes during development

2.2.3.2. can respond to changing market / competitors / customer requirements / clarifications

2.2.3.2.1. provided this is managed with the customer in terms of cost / scope

2.2.4. good for...

2.2.4.1. time-and-materials projects

2.2.4.2. in-house projects where there's a constant income stream

2.2.4.3. initial investigations

2.2.4.4. projects with a high degree of uncertainty

2.2.4.5. people who understand agile

2.3. drawbacks

2.3.1. usually places a heavy burden of understanding on the customer

2.3.2. if the customer doesn't understand agile, there may be a HUGE mismatch in expectations

2.3.2.1. time / scope / budget

2.3.2.2. what will be delivered

2.3.2.3. how are change requests handled

2.3.2.4. who pays for changes?

2.3.3. flexibility is sometimes "too much" for the customer