Agile vs Waterfall: Difference between revisions
Line 28: | Line 28: | ||
*Old-school, top-down power dynamics. | *Old-school, top-down power dynamics. | ||
*Does not account for changes in the | *Does not account for changes in the stakeholder's requirements, team capabilities, what is learned during a process, nor is the customer shown anything until the dev cycle is done, thus the customer remains uninformed and unable to provide feedback during the dev process. Specs and design are written up front, and the whole project is one giant, long iteration. This is why Detroit takes a decade to build a new car, and Wikispeed takes 3 months. |
Revision as of 05:19, 2 August 2012
Introduction
This page is dedicated to constructive banter on the advantages and disadvantages of Agile Development compared to Waterfall Development techniques. It seems like people push too hard one way or the other usually, and suffer from over structure and under structure. -- Marcin (presumably)
\- Marcin isn't doing (or understands) either, hence this ignorant critique. He's actually just doing haphazard micromanagement. For example, if either Waterfall or Agile were used to develop the hablab, it would have been developed before 15 people arrived. --Vann
Agile Advantages
- It's good for iterative creativity
- It protects the project members from changing expectations of an owner
- It has been measured to perform 40% faster than waterfall (wikispeed)
- Workers choose their work and are therefore more satisfied with work.
- It is significantly more scalable than waterfall in that it prevents management from micromanaging.
- It contributes towards the democratization of the workplace which is an imperative step in the new (distributive) economy. (trustistheonlycurrency, sacred economics)
- It contributes towards a healthier working environment.
Agile Disadvantages
- It's good for iterative creativity, but not to get a big project done ON TIME.
\_ This is a fallacy and ironic. Waterfall projects often go way over budget and way over time, that's a big reason Agile was developed in response! There's nothing magic about waterfall that makes a project happen on time, in fact, if anything, it hides the reasons why projects go over time (not accounting for changes in team capacity, new or changing business requirements, new knowledge acquired since the spec was written, etc etc)
- Consider the place Agile is lacking.. and why you'd want a gantt chart... When there are external constraints.. like the delivery of supplies, that contribute to a critical path and require advance planning and an understanding of relationships between initiatives.. say in order to build a house before winter and there's a 3 month lead time on the roofing etc. This concerns could be easily carried in a scrum-type layout with an added feature showing dependencies.
\_ Agile, and Scrum in particular, think about dependencies in a different way. See [1]; the key is breaking down a user story that has dependencies within it, and prioritize the tasks in order. Keep in mind that in Waterfall, in contrast, there's a huge amount of unnecessary overhead in tracking dependencies that gains you little.
Waterfall Advantages
- It is driven by time and thus enables projects to be delivered on-time regardless of the lives these constraints may impact
Waterfall Disadvantages
- Old-school, top-down power dynamics.
- Does not account for changes in the stakeholder's requirements, team capabilities, what is learned during a process, nor is the customer shown anything until the dev cycle is done, thus the customer remains uninformed and unable to provide feedback during the dev process. Specs and design are written up front, and the whole project is one giant, long iteration. This is why Detroit takes a decade to build a new car, and Wikispeed takes 3 months.