We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
BPM
user-pic

Is waterfall making a comeback? Should it?

Vote 0 Votes
As with this Chris Taylor blog, there have been murmurings of waterfall making a comeback.  Do you think it is?  Do you think it should?

11 Replies

| Add a Reply
  • People will adopt what they feel more comfortable with and what they know best, they don’t like to change this. I think waterfall has been making some more noise but specifically for process I don’t think you can be as successful long term with as you can with Agile. So with that in mind I don’t think waterfall should make a comeback. But with that in mind I am open to hear why this is wrong.

  • His post was an April Fool's day joke. If it wasn't, it should have been. :)

    Waterfall is the process of a dying organization.

  • It was my April Fools blog, but it brings up GREAT questions about why Agile matters so much and why an Agile approach that IT has adopted so well needs to become a business approach. Agile is all about delivering value in pieces rather than Big Bang.

    Lots of angst and frustration has come from the historical IT waterfall approach that was long, arduous, and often led to failure. Agile was the answer to lower risk and make things happen in a world where everything shifts while you're busy doing what you planned for.

  • Just to make clear, I had also been asked the following by one of the more recent forum contributors, Jonas Ekstrom, which I thought was interesting:

    Time for a Waterfall revival: Are we ready to back down from agile development methodologies, and return to the waterfall? Will BPM be the enabler for returning to a predetermined, structured and sequential development process?

  • It's almost never the method who is to blame but rather the ones who practicing it. I've seen lots of IT projects been organised as agile with a bunch (some times over a 100) of developers and testers in the early phases with no initial requirements or goals. This setup always leads to a situation where the business crosses their fingers and hope for luck. If this is the definition of working agile hopefully BPM could help the business reclaim the control and set the balance between business and IT. We're making big efforts in making the most out of all our models owned and managed by the business.

  • Waterfall with delivery at the end of a long process is indeed too risky. On the other hand waterfall methods with agile iterations is what we need, the best of both worlds with agile delivering often exhibiting problems early.

  • This is the next step in agile?
    Just this week Naomi Bloom a renowned consultant, analyst and thought leader with a strong HRM focus posted a must read article on Agile, Models-Driven Definitional Development – see http://infullbloom.us/?p=3222
    Some quotes that should encourage this move.
    “Writing less code to achieve great business applications was my focus in that 1984 article, and it remains so today. Being able to do this is critical if we’re going to realize the full potential of information technology”
    “….how those models can become applications without any code being written or even generated.
    “…object models become the functionality of the applications with a minimum of human intervention, whose business functionality is therefore built and modified only at the models level. Such an approach can be very flexible initially and over time, easy and fast to implement, and inexpensive for both the vendor/provider and customer to acquire and maintain”
    “If I’m right, you’ll want to be on the agile, models-driven, definitional development side of the moat thus created, whether you’re an HR leader, working in the HRM software vendor community, or an investor in that community.”

    Later in a tweet Naomi said “It really matters how your vendors build their software, not just what they build” and Michael Krigsman a leading analyst tweeted referring to the article “Pointing to the technical foundation of future”.

    This is now happening and the speed of development with in built agility all developed in business language will surely kill off waterfall for business solutions and promote "agile".

  • I hate to admit it, but I see a place for Waterfall. As more development gets outsourced to teams that are extremely remote (geographically, culturally, etc) from the business owners, agile methodologies tend to break down.

    Agile can only work with strong trust and constant, honest and effective communication. Short term projects, sent out to new teams on the far side of the world can't execute agile methodologies effectively, because the feedback that is required just isn't there. In my experience, even sending projects across country can be hard, since people rarely see the value in the constant web-conferences required to make Agile happen remotely.

    In any remote development, BPM or otherwise, Waterfall or some other traditional "spec, design, develop, test, fix, deploy, iterate" methodology fills the gaps in constant communication. You can grow back into Agile as the trust and confidence in the teams grows.

  • PS With Agile, Models-Driven Definitional Development no more offshoring all build in business language with users involved with quick results.

  • To say that waterfall is obsolete would be to wrongly imply that it had value at some point in the past. Waterfall's main purpose, as far as I can tell, was to act as a CYA mechanism for IT managers, enabling them to respond to any challenge with the magical retort, "But it wasn't in the spec!"

    And yet, I will not judge, for it is not as though I have never taken refuge in those words in the course of my long career.

    OK, I hear you say, but can BPM help businesses move beyond waterfall? Why, I'm glad you asked. BPM software provides a platform for easy and rapid prototyping of solutions. Rapid prototyping, in turn, is the key to creating a positive feedback loop between designers and developers, resulting in a healthier and more complete deployed solution. Combined with lower overall development costs, this quality of BPM renders irrelevant any imagined benefit of waterfall.

  • No, waterfall will never make a comeback (if, as Scott doubts, it ever was). The reason is that the Agile approach is a way of dealing with complexity. Waterfall works only when the problem being worked on is not complex. Physical manufacturing might be complicated, but never complex. Information system, on the other hand, are almost always complex, and can not be handled with a waterfall model (except the most trivial examples). Even the original paper warns that the method should work only in the simplest software scenarios.

    http://social-biz.org/2008/09/02/agile-development-road-trip-analogy/

    Phil points out that Agile requires a good deal of direct interaction, and he is correct. Direct interaction is a way of handling the complexity. But, inability to interact directly does not mean that waterfall will work in distributed teams. If the problem is complex, waterfall will fail, whether the team is distributed or not.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT