Why you should learn some Waterfall as well

Scrummerfall

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

Check yourself with the Agile Karlskrona Test and discover if you’re already working in company like ThoughtWorks. I am not.

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)

Cheers.

About these ads

12 thoughts on “Why you should learn some Waterfall as well

  1. Hi Arialdo,

    I like the point that you’re making across that Waterfall still exists and Scrummers need to recognize its existence and know more about it.

    I think your post is excellent and that’s why I would really like to republish it on PM Hut under the Scrum category. Please either email me or contact me through the “Contact Us” form on the PM Hut website in case you’re OK with this.

  2. Sorry but I can’t be bothered to list all the ways I think you are wrong.

    But two things stand out:

    Firstly; “Agile is too much young”.
    Evolutionary software development (that led to agile) began at the latest in 1976 with a guy called Tom Gilb. That’s THIRTY-SIX years ago! And on top of that the Agile Manifesto was written ELEVEN years ago (a huge span of time in our branch). Agile is far from young. It has been adopted by IBM and other major corporations with tens of thousands of employees. It is mature, well-tested, well-documented and well-researched.

    Secondly; “Even with waterfall I never missed a single deadline”.
    That’s easy, just add a large enough buffer! Using not missing deadlines as a good example of Waterfall shows your lack of understanding about agile and also about what makes companies successful and profitable. Predictability is not a key success factor for most software projects, quick delivery of business value is. We have to test our assumptions, either on the customer or, preferably, on end-users, as quickly as possible and learn from this. THAT creates business success! Facebook did not succeed because of predictability but because they learned faster than all the other social networks available at the time (Friendster, myspace, etc.)

    The basic principle is good teams will always deliver high value. Agile is a set of values and principles to help create good teams. I recommend you read some more books and learn some facts before your next blog post: The Lean Startup by Eric Ries, and Mindsets by Carol Dweck are two to get you started.

    • May be you’re right when you say that Agile is not young at all.

      Asking themselves “Where is Agile in the Hype Cycle” Steven Thomas and others came to this diagram

      Where is Agile

      If I only had read his post and what I further read, I would have probably used words different than young.

      About the second of your arguments: well, my posts wasn’t mean as a defense of Waterfall, nor it was a criticism to Agile. I didn’t say that Waterfall allows a company to quickly react to market changes, nor that quickly reacting is not important.
      And, no: I didn’t mean than Waterfall is a good alternative to Agile.

      All I was trying to describe was my humble experience with Waterfall, compared to what I often heard about it. Yes, deadlines are an important measure of success, in Waterfall. The same logic doesn’t apply with Agile. Yet, I heard tons of Agile coaches claiming that Waterfall was a disaster in satisfying deadlines.
      Since I often hear FUD about Waterfall, while Agile is sometimes presented as a panacea, I wished to tell my personal experience with Waterfall.

      And, yes: right now I’m a happy Agile developer, an agile fan and, (yes), sometimes an agile criticizer.

      Naturally, may be I still need to read a lot. I will. Thanks for your comment.

      Cheers

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s