Imagine that you must predict what you will be doing exactly 10 months from now. You must plan what work you will do, how long it will take and whether it depends on someone else’s work.
It’s hard to do, right?
But that’s basically the experience of working in a waterfall methodology. You plan the whole thing in advance, in great detail, and you make a commitment to a customer to deliver on a particular day. When looking at a big job and deciding how to get it done, sometimes this approach is your best option. If you’re building something monolithic and very expensive and you have one very big customer. For example, building a drawbridge. You’d better know ahead of time exactly how you will make it work because that’s not something you want to have to figure out while you’re doing it.
Yep, that’s waterfall
One task leads to the next, leads to the next and they all line up on a timeline like a waterfall. And you’ll have many waterfall ‘tributaries’ since a lot of work goes on in parallel in the beginning and has to fit together right on schedule at the end.
It makes sense. Sort of. For some projects.
The Waterfall Method Doesn’t Work Well for Purely Digital Products
It doesn’t make sense for software and web development. For websites and software development, this extreme forecasting creates an unnecessary burden on workers. These are creative jobs, and what the workers create is something that has never been done before (if it had been, you’d just copy it, not create it). For these products, the people doing creative work have to jump in and start working to discover the best way to achieve a goal.
Agile is built around the way teams of software engineers and web designers naturally work, when they’re working well. Rather than plan every detail, it depends on employees having the talent and judgement to make the right decisions in the moment. And it works best when teams include both senior and junior members because the newbies learn best from directly observing the more experienced workers.
Agile methodology tells us that knowledge workers are motivated by autonomy, mastery, and purpose. So build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
When using Agile, employees typically only have to forecast two to four weeks ahead. Contrast that with the 10 month waterfall cycle. And for a website or a SAAS product, this is perfect. Your team will focus on continuous delivery of working software and all the improvements will get to the consumer much faster.
In conclusion, design an environment where creative workers can create in a way that comes naturally to human beings and you’ll end up with more productivity, higher quality and happier people.
I did the Agile MBA program with Larry Apke in San Francisco, and I volunteer with Silicon Valley Project Management, practicing Scrum and Agile. I cannot speak highly enough of these two programs. The Agile methodology for managing a team and managing a project has been like a breath of fresh air.
1 thought on “From Waterfall to Agile: Making the Process Match the Way People Really Work”
When talking about the differences between Waterfall and Agile, you wrote some background on how Waterfall is done and why it stresses information workers out. In contrast, I really appreciate you highlighting how Agile allows teams to work together effectively, which cuts down on the time and stress of the work environment. Thank you so much for sharing, Susannah Medley.