Agile vs Waterfall

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 evidently understands) either, hence this ignorant critique about structure, which doesn't actually mean anything. "Structure"? Be specific.

What he's really doing is something more along the lines of haphazard micromanagement: i.e., whatever comes to mind now is the current fire to put it out, and don't trust your teams to make design decisions, but only to do rote work. It seems he thrives off of a constant state of crisis and working (just a little) on too many projects at once. This results in high turnover and burns people out, slow progress, poor designs, and chaos. Both the wiki and the physical FeF site represent this state of chaos and disorganization.

The reason Marcin objects to Agile is because, if he is just a stakeholder on a project, he would have no say in how something is accomplished. He could only set high level user stories (the what). If he sees how determining success criteria will guarantee that his values are represented in the project, he doesn't trust the team to do it. And if he were a team member on the project rather than a stakeholder, he'd have no authority over other team members, and would have to convince team members to adopt a design on its own merit. And we can see from the results here that designs have not been adopted on their merit (more below).

The reason Marcin objects to Waterfall is because he intuitively sees that something is learned in the development process, and he wants to be able to change designs as they occur to him. He doesn't want to spend weeks writing a spec, then weeks more writing a design document, and then sticking to it for months or years as these steps are followed, which is what waterfall would dictate.

While work does eventually get done, this haphazard method doesn't bring about good results. While Wikispeed, which uses Agile methods (which he ironically calls the "hero" method, which is closer to what he uses), designed a production ready car in 6 months, Marcin, who uses no professional method, is on the 4th or 5th iteration of the LifeTrac which is unable to perform the basic functions of a tractor, and certainly does not exceed industry standards. He designed a Hablab that few want to live in, and with R50 hay bail walls, yet so fails in its passive cooling design that he's now resorting to attaching a window a/c unit so we'll have at least one cool room (and thereby defeating the entire purpose of a passive design). The point with these examples is to illustrate that the current method of crisis management does not work well. Had either Waterfall or Agile been followed on these (and other) projects, experts would have been hired or consulted, and either results measured against specs (Waterfall) or against success criteria at each iteration (Agile), and we'd be in a better state than we are today. Instead, things are just done haphazardly.

In short, this discussion isn't about Agile vs waterfall, but a mask for the real issue: Marcin loosening up control, and learning to trust his teams to use any professional management method.

Agile Advantages

• It recognizes that stakeholder's business requirements often change (once they see a working product, as they learn more about their needs, etc).
• It recognizes that team capacities change as new members come on and leave, that as time goes on designs change or improve and thus time and budget estimates change, as informed by reality, and thus planning very far ahead simply doesn't work. To estimate how long a project will take, team velocity is measured against user story estimates to give a burn down chart, which can be projected to give a time estimate. If the goal is to achieve something sooner, either take away user stories, add more team members (but splitting teams as they grow past 9 or so), or improve each member's productivity via training. (The worst thing to do is to have team members split by so many late projects that they burn out, which is what we do now)
• It separates concerns: stakeholders have business requirements aka user stories, and team members self assign tasks they can complete during an iteration. This prevents worker burnout and simultaneously satisfies stakeholders.
• It has been measured to perform 40% faster than waterfall (wikispeed), not counting cumulative effects.
• Workers self assign to tasks and are therefore more satisfied and motivated to work.
• It is significantly more scalable than waterfall; there's minimal overhead in interteam communication in place of unnecessary documentation,
• 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, ironic, as well as damning with faint praise ("creativity"?).

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

\_ The claim it delivers projects on time is definitely false, see above. But it is true that waterfall doesn't protect team members from change orders and the like, or managers who see a deadline and blindly thrash their employees to meet it, ignorant of why the project is slipping, but this is a disadvantage, not an advantage. I suggest someone who's touting waterfall read a little bit about it first rather than just guess. But Marcin isn't doing waterfall anyway so I wonder at the relevance. --Vann

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.