Most products are developed like a waterfall. Waterfall development is the classic sequential linear process where you finish one stage before moving on to the next one. You aim never to revisit a stage once you’ve finished it, so you’d better get that brief right the first time.
When I worked in web development in the late 90’s, we adopted the waterfall process by default. We even hired a 30-year career military project manager who was an expert in waterfall development with construction projects like bridges. We could have wallpapered our offices with his Gantt charts.
We discovered that this command-and-control process was a horrible fit for web development. We couldn’t predict all of the potential issues when we first wrote a brief. So, requirements would inevitably change and we’d uncover issues too late to do anything about them. We would then either stubbornly hold to our original plan or scrap a lot of hard work to start parts of the process over.
Waterfall development also stifled great ideas that came mid-stream. It clamped down on “feature creep” to the expense of creating more remarkable innovation.
I recently discovered the Agile Manifesto, written in 2001 by a group of software engineers to invent a new process better matched to software development. It has a lot of variations (iterative, scrum, lean), but at the core, it’s a more innovative approach designed around short sprints and iterative prototyping, not a long linear slog.
I found their principles inspiring not only for software development, but any form of product development, even consumer products. The most recent method product launch included at least 44 rapid prototypes that all evolved the product beyond what we could have ever imagined in the original brief.
I think that any form of product development can benefit from the tenets of the Agile Manifesto:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
5 CommentsJoin the Discussion
Rob Cottingham says
Heh… it’s easy to think you’re looking at a waterfall when you’re actually circling the drain. Terrific cartoon.
Nancy Kosciolek says
I can’t believe someone else has discovered the Agile Manifesto! I agree that it is easy adoptable to any new product development.
Phillburt Bellows says
Great article. I had never heard of this Agile Manifesto, and I have to say i was impressed. It reminded me of two men in particular, my first employer, Seymour Chipsetter and Roger Anthony of Crocodiles International.
The line “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” hit me particularly hard.
Seymour always told me when I was younger to ‘do it all in motion and watch the flow happen’. He was always right. Projects were done on time, even when faced with amazing challenges.
Roger Anthony happens to run his Crocodiles International by sharing his dream with prospective employees, and they pick where they want to work the most. They show him the skills and the passion to excel in their area and he hires them. People move mountains for that man, which brought your article back into focus for me.
Thank you So much for sharing that brilliant line of thought.
Great cartoon. Actually by stripping out the software speak you can actually apply agile principals to any organization and not just physical products, but services – whatever the organization produces! In the end Agile is more of a philosophy – a mental operating model. We are actually the Scrum a management framework.