I once worked as a team leader in a startup. I was in love with XP, studying Scrum and looking forward to be able to put into practice what I was reading.
Unfortunately, my boss explicitly told me to use Waterfall. I never blamed him: before him, the company had no process at all, and was governed by anarchy; no documentation, no requirements, no clear roles. Actually, introducing a Waterfall process, he made a great revolution, and let the company succeed.
Yet, since I was eager to push some agility in my team, all I was able to do was to introduce some isolated techniques: stand-up meetings, brainstorming, some kind of collaborative story estimation, a bit of TDD and few more things.
We were all but agile: I was using a weird form of Scrummerfall. We were missing the very crucial point of agile: we used to start developing only after all requirements were available and approved by the customer. No evolutionary software, hence.
Know what? Even with waterfall I never missed a single deadline. We passed every single acceptance test and we never missed a single commitment.
Please, stop writing about Waterfall: it’s just wrong
Right now I’m working in a Kanban team. Hey, folks: it’s so much better, and much funnier, as well.
Nevertheless, I won’t forget what I learnt from my Waterfall experience, and I still think some processes from Waterfall can teach a lot to agile teams.
I know it may sound weird, hence I will try to expose it better.
Some reasons why you should (also) know Waterfall
Agile has not been adopted by your Company
Agile adoption is quickly spreading through teams and every developer wants to be a Scrum Master, but most corporate dynamics aren’t yet changed and they are still anchored to an old mentality.
I bet a lot of agile teams out there are still struggling with top managers who absolutely want to know how much the project will cost, the exact delivery date, and where the requirements document can be found. How could you blame them? They have to manage budgets, stock exchange and investors. They won’t understand your weekly story estimations, Speed Boat Game and retrospectives.
Few lucky teams are really doing Agile
Even if they want to correctly do Agile, strong deadlines, inefficiency and low budget force developers to be less rigorous in constantly using pair programming, TDD and so on.
Very commonly, for example, there’s no time and no budget for refactoring or retrospectives, mostly because the management doesn’t see a business value in these practices. Probably, ThoughtWorks’s and Google’s teams are really agile. Personally, I’ve never seen a single agile team who was completely free from Waterfall mentality.
Agile is too much young
Few Colleges teach it, and since agile is a hype word, a lot of young and not well prepared coaches introduce it badly in teams. The agile ecosystem is full of bad coaches who are using a lot of waterfall principles (mostly, without knowing it) when they are not even teaching clearly wrong principles.
Just few days ago, I heard a very famous Italian coach claiming that we must reject SOLID principles, since they are old, and “Just Be Agile!“. Yeah!
Talking about Eventual Consistency with another agile coach and DDD expert, I was recently told that in order to be agile we could completely ignore the problem of data consistency and live well with a broken database (that coach was neglecting the fact that Eventual Consistency, which is an amazing technique, requires us to manage Conflict resolution)
You are probably not working in an Agile team
Seek your non-agile practices and learn them well
I’m not saying Agile is wrong. Actually, it’s great.
What I think it’s that we often think we are agile, while we are still using some old and non-agile practices.
I have nothing against old practices. To be honest, I love some of them. I love some elements from Waterfall, as well.
The best remark I ever read about “old practices” is by John Russell in a comment to Christopher Goldsbury’s post Agile Hybridization on InfoQ
There is no explicit methodology called “waterfall” and there never has been.
It is nothing more than a straw-man used to criticise well established and proven analysis, design, and development practices.
No “rules” are being broken by going back and changing requirements models or artefacts when something is discovered during later phases for example. Neither is there any “rule” which says you must design everything in minute detail before starting to code, or that you can’t use OOAD, UI prototypes, feature backlogs (prioritised lists), or that developors can’t have direct end-user contact when using a “waterfall” process
I just think that one should acknowledge if she’s using non-agile principles, and try to get the best from them. Applying agile principle while using practices from some other methodology could be counter-productive.
De facto, Agile is often mixed up with other methodologies, and still the resulting mash-up may work. After all, IT world worked well much before Agile, din’t it?
Should you be discover you are using some practices a bit different from what’s in The Holy Books About Agile, embrace them (if they are working in your context) and learn how to apply well those practices.
Faking agility is never a good choice.
Waterfall is all about good estimation
The biggest lesson I learnt from my Scrummerfall experience is about what I rank as the biggest difference between Agile and Waterfall: Waterfall is about communicating to your manager “I will need this budget and I will deliver on this date“; Agile is about continuous, never-ending delivery of business value.
That’s why Christopher Goldsbury, in his excellent post Why Agile Adoption Fails in Some Organizations claims
The key lies in estimation.
The company is asking you how much it will cost to build the application because they are unwilling to fund it forever. They want it to end…….preferably sooner rather than later. Funds are limited and your project, although perhaps necessary, is not viewed as critical to the company’s future. Its ROI may even be negative. Returning to the leadership of this company with the answer; “I’m not sure how long it will take….just fund the team for a year and we’ll see how it goes every iteration” would be a mistake that would likely result in your dismissal.
And that’s why, I believe, a lot of teams are doing Agile mashed-up with Waterfall: commitment with the Company is too much important to be neglected.
And, finally, that’s why I think I still have so much to learn from my Waterfall experience.
Estimation is the leak part of Agile: Corporate Companies like Waterfall for it’s predictive nature; they are afraid of Agile for it’s unpredictable emergent nature.
Should you both want to be agile and satisfy your manager, you should learn to produce good estimates. That’s the topic of the second part of this post: 8 rules to be successful even when forced to use Waterfall (with a pretty good estimation)