≡ Menu
Pawel Brodzinski on Software Project Management

Waterfall? Sure! Why Not?

Waterfall? Sure! Why Not? post image

I heard this sentence today: “This is a classic example of a project where hardcore waterfall would be the best way to go. You know, detailed specs up front and not even a single line of code before the whole thing is formally approved.”

A gem. A real gem. I mean seriously. OK, just before you stone me to death let me introduce the context.

A project under discussion just went through a second demo for the client and it was the second time most of assumptions changed and the whole thing will have to be completely remodeled. What a nice case for applying agile methods you say. Well, sort of. The problem is the contract with the client isn’t really agile. Not even close. It is good old fixed-price deal. I would say say fixed-price, fixed-scope but it seems the scope is not as fixed as the vendor expected. And now that you ask, the client isn’t going to pay a penny more just because it seems both sides have hard time understanding each other.

The vendor could always try to harden their positions and reject to redo the damn thing. Sure, that’s always an option. Less likely to be executed when we discuss a key customer which feeds big part of the vendor. Unfortunately this was exactly the case. What more folks on the client side kind of used to work like that – changing their mind just before moving the project into user acceptance tests is almost expected.

The only hooks the vendor could use were any formal agreements which were in place. And because of flexible attitude and “we we specify details when we need them” attitude any specs were very general and highly interpretable.

So it seems that applying hardcore waterfall would probably be the best choice in this situation. It would be so no because it would yield the best application which is optimally adjusted to client’s needs, but because it would force the client to think through the whole thing at the beginning and it would also normalize cooperation between both sides.

Actually in the long run it could be win-win, even though odds are the quality of the application in the short term would suffer. However, in this case it isn’t software quality which is the issue. It is high, and unplanned, cost of redoing the app a couple of times and how the situation affects relation between the vendor and the client.

Whenever you think about methods of your choice, consider all aspects, not only how flexibly you can react to change. After all, change is not always that welcomed.

in: project management

13 comments… add one

  • Laurent Parenteau August 17, 2011, 1:37 pm

    Yes, waterfall may be the right solution sometimes, even if you prefer to work in a more agile way (and think that this should be how everything is done).

    Everything is so dependent on the particular case that advocating a single way of doing things is bound to fail. Unless you are a dictator that can decide all aspects of the project (including the contract with the client and who will work for you), you have to works with aspects that you do not control. That means making compromises. That means that waterfall may be the best solution in some case.

    That said, one most not forget that the choices are not only full waterfall or full agile, but all the variations in between.

    And actually, if you are able to choose waterfall for a particular project, isn’t that being agile in itself?

  • Pawel Brodzinski August 17, 2011, 11:43 pm

    @Laurent – Sure, it’s always a variety of options in the middle. However, I brought this example because it was kind of rare case where clear waterfall produces just better results company-wise.

    I mean the goal here isn’t to deliver software which is fine-tuned to client’s needs but to make a relation win-win: the client gets decent software and the vendor gets their profit for building the app.

  • Torben August 18, 2011, 12:09 am

    Thanks for wording this, Pawel!
    In our work (ecommerce enablement), a lot of customers don’t understand Agile and have no time/interest to be “changed” in their ways. Their interest is in having a running, “done” online shop ready for the holiday business.
    Frequently, the only way to sell our service is by presenting the project/estimation as waterfall.
    What we make of it on the production end is a completely different matter. As Pawel suggests: usualy a variation in between.

  • Pawel Brodzinski August 18, 2011, 12:33 am

    @Torben – It is an old pet peeve of mine: can you enforce your approach on a client? Of course we may, and should, try to convince them it’s a useful approach. However, there are some companies out there which won’t adjust their ways no matter how good salesman you are.

    You can close your eyes and pretend the reality is different but it won’t be so. The only things you can do is either accept the rules or walk away (both worth considering by the way).

  • Michal August 18, 2011, 3:24 am

    It is known that all the agile stuff is not a silver bullet that works for every single project. The most important thing is to have different tools for dealing with given problem and to know their pros and cons. Having that knowledge it’s easier to choose better solution that suits the problem. In the case mentioned by Pawel it is waterfall-like approach which suits better and it can be agile approach in the others. And as Laurent says, if you can choose solution wisely, it is agile itself – you react and adapt to handle given problem the best way possible.

  • Dave Moran August 18, 2011, 5:42 am

    Pawel,

    Terrific post – and very “real world!”

    Agile works if the client is flexible and a certain amount of trust exists between you and the customer. It’s a question of whether you are viewed as a trusted partner or simply a “vendor.” I’ve seen projects where the customer actively participated and trusted the vendor to the point where a partnership developed. This is where Agile’s frequent and incremental delivery – along with the ability to re-prioritize the backlog – worked to the benefit of everyone concerned. I’ve also seen many cases where someone on the customer side is in negotiation mode, basically trying to get as much as possible as quickly as possible for the fewest dollars spent. If you don’t nail the specifics in terms of requirements with someone in this mode, you will lose money on the deal for the reasons that you point out.

  • craig August 18, 2011, 2:01 pm

    Good luck with that client. Looking forward to how things go in three or four months when the specs get handed over.

    I figure you are going for the Spec[agile delivery]UAT|release] model. Will you be demoing thoughout development?

  • Pawel Brodzinski August 19, 2011, 12:46 am

    @Dave – Yes, it all boils down to relationships in general and trust in detail. However, when we are at relationships people often forget specifics of work for big clients. Personally I worked in 3 different companies where relation between a vendor and a client was small versus big. And I can hardly recall any situation where big client didn’t play that card. It doesn’t even matter if it is the attitude of organization or of someone from client’s project team – the effect can be similar.

    By the way: when you discuss huge companies there is no such thing as organization’s approach to build projects. It is always about specific people – business folks or client’s project manager or IT guys, etc. One project for the client can be completely different than the other.

  • Pawel Brodzinski August 19, 2011, 12:51 am

    @Craig – Talking about development process: the vendor can demo the app bi-weekly although there’s no one on client’s side willing to look at it. They’re waiting for the whole thing to be completed.

    In the whole situation it is not development process which is flawed but the cooperation with the client. It is not a case of building the thing wrong but building the wrong thing. The problem is basically defining what the right thing is, and for that you need both sides feeling responsible for their parts.

  • Craig August 20, 2011, 12:42 am

    I know that. Have a few of those myself right now.

  • Markus Andrezak August 21, 2011, 3:15 am

    Well, it’s a bit like – what does Barca do if the opponent doesn’t let them roll? Easy: They keep rolling.

    n your case: What is the use of giving up your principles and playing big batch size games? Does this lower your cost? The clients cost? Does it lower your risk?

    In fact, even if not exposed to your client, all the agile practices help you, at least internally to manage risk. Why give up on that?

    Just the few cents I have ;)

    Markus – see you in Munich

  • Jaime Casero August 22, 2011, 10:20 am

    I have reached your blog from http://blogs.imeta.co.uk/TPeplow/archive/2008/11/28/when-should-i-use-agile-methods-on-my-software-project.aspx . I liked your opinion about there is no silver bullet, totally agree. This entry in your blog is very interesing to me, since that business case is very familiar in my job. I wouldn’t say waterfall is the best for this case, as you say you can accept or walk away. I’m opinion, speaking technically, the best option would be to walk away. There is no way to win in this case, if the customer is not committed to the project (and fixed-price, fixed-scope is the first sign), and the product you have to develop has an inherent innovative aspect (the customer doesn’t know what he wants, requirements are chaging constantly…) , then there is no way to win. The key in this case in my opinion, is the fact that the provider is let’s say customer-locked (as opposed to vendor-locked). If you let your company to heavily depend on one customer, then sooner or later you are going accept something unnacceptable, because the option is closing the business. But as I said before, this more a business issue than a technical one.

  • Pawel Brodzinski August 22, 2011, 12:30 pm

    @Jaime – In this specific case walking away isn’t an option. I wrote a follow-up post on the situation: http://blog.brodzinski.com/2011/08/more-on-waterfall.html. It is not even a case of the vendor being too dependent on a single client (or the other way around), but more of breaking relationship being unreasonable for any of parties.

Leave a Comment