Which way to Lean?
/Agile vs waterfall? It's one of the most common questions I get from business leaders. Building software WITH the customer seems so obvious. It's a wonder it took the industry decades to figure that out. So Agile is sexy as the way to Lean.
Yet Waterfall still has its place. Why?
Where this came from
Waterfall dates back to the days when creating software was more like constructing a building. Coding was a much slower process, so it was cheaper to design the system on paper, then have the customer approve the design document before cutting any code. As coding tools became more productive, this gap closed.
The Agile movement gathered pace at the turn of this century. The founding group created a brand around a collection of great software development practices. I had been using some of these a decade earlier, so of course I was a fan. The richness of a working prototype trumps a 50-page document to convey the design to a buyer, and when the prototype is right, the job is done.
The Agile brand allowed the software industry to have a conversation about our fundamental practices. Lots of businesses that started up after that time have known no other way. But the argument still rages. It's become a religious matter. Agilers can't fathom why anyone would take more than two weeks to deliver a usable improvement. Waterfallers don't trust the uncertainty of no plan and no documentation.
And leadership is caught between the deliver–early–and–often promise of Agile and the relative comfort of a thorough plan.
Fact is, projects are seldom pure Agile or Waterfall. Agile should never be used as an excuse for no plan and no documentation, and any complex project needs some structure. Where's the right place in this spectrum for your next assignment? It depends ...
The Waterfall/ Agile Scale
If you're wondering which way to go, here's a scale of favourable factors for 1 ( Waterfall) or 7 ( Agile):
You know exactly what you need and can write down every detail at the kickoff meeting.
You have a culture that is atuned to Waterfall.
You favour predictability and will pay a premium to get it.
You're repeating work that you have done before and have confidence that your playbook will work again this time.
You have a very short list of critical goals and don't care how those goals are achieved.
You have a team that's really good at Agile.
You're solving a problem for customers and the best solution isn't known yet.
The higher up this scale you are, the more you should lean to Waterfall–the further down you go, the more likely you are to win with Agile. You may notice that the degree of uncertainty increases as you go down this list. That's no coincidence.
If you can plan, do. That's Waterfall.
If the team knows the problem but little about the solution, figure out what needs to be learned next and learn it quickly. Lean towards Agile.
Which Way to Lean?
Pick a handful of projects that your business will conduct this year. For each project, circle the numbers that apply on the Waterfall/ Agile Scale and add up the scores. If your project scores 10 or less, waterfall is the better way. Over 15, lean towards agile.
Trusting Technology is a book about forming ideas, exploring opportunities with customers and colleagues, and building your future together. Order you copy here . This article is also available in hardcopy as part of my 10-minute Reflections series of exercises—order volume 1 here and volume 2 here.