21 May 2009

Agile, Waterfall, Something else?

There are people arguing the agile case and there are people that deride it and say stick with the status quo of the waterfall method. There are people who say outsource everything you aren't an expert at.

I have yet to be convinced of any one way, but I have put together this matrix as a talking point. Right or wrong I would like feedback from people who know more than me.

Anyone want to start?


  1. If you've got that much domain knowledge to work with, and the project is really that complex, break it into smaller projects and treat them each accordingly. Your domain experts become senior task leads but also crank out useful work on the project. Don't delegate the time-consuming PM work to them --get deputy project managers to handle the integration issues and other artifacts of complexity.

    If you need a name for it you can use one of the overloaded Systems Engineering terms like "integrated" or "composite" but it's really just adjusting the scale to keep each project at a manageable complexity.

  2. I've become more convinced that there is room for both approaches, Agile, and Waterfall. From my experience, waterfall works well in long development cycles where the requirements, interactions and complexities are able to be described in such a way that there is no ambiguity for the development teams. Agile, in my opinion, works well when requirements are more vague, accompanied by unknown performance attributes, interactions that are not yet realized, and user interface design that needs to be iterated until it is right. Agile enables a quicker pace to get to an understanding of what it is you really desire in the product. Ideally, I believe a waterfall approach can be enhanced with Agile for key components that need to get to a working element to fully understand the design approach.

  3. One question: where do COTS packages fit? Are they a sub-set of outsourcing? Or is it on a different/third axis of some kind?

    OK, a second question: where do spiral methodologies fit? Been a while since anyone has discussed them, but are they the actual hybrid of Agile and Waterfall?

  4. I don't think "Outsource" belongs to the same representation as "Agile" and "Waterfall", which are software development methodologies.

    As a consultant who works for a company who does onshore/offshore outsourcing, I see the"Agile" vs. "Waterfall" vs. "Prototyping" discussion happening all the time in outsourced projects.

    "In-house" vs. "outsourced" is another aspect to be considered in addition to the development methodology being adopted.

  5. I agree. In-house vs. Outsource is a function of business plan and required project expertise.

    Regarding where the Spiral methodology fits in: I've always liked the absolute completeness of this approach to ensure solid requirements that work and are tested to some degree before getting to the next spiral. In some ways it's similar to Agile in that it enables requirements capture, design, development and testing all in the same spiral to ensure a more rapid and complete understanding of the design approach. The trouble with it in practicality has always been how to schedule the resource availability, at least in my experience. This is where Agile's approach of dedicated Sprints for specific functional chunks fixes the resource scheduling problem.

  6. Craig,

    I would like to bring up one other point and then suggest an approach that we use, though we've never named it.

    External consideration point:

    One point I would like to add that is outside the scope of your question, but is, I believe, critical to understanding why waterfall is so common and other approaches run into such strong headwinds: Budgeting.

    From and accounting/CFO perspective, waterfall projects are easy to budget and track. The biggest concern I see with agile or other real-time, redirecting methodologies, is the difficulty in budgeting beforehand what the project is going to cost and tracking progress.

    (In the interests of full disclosure, we are developing a low cost EVM solution, so I'm very heavily tilted towards budgetary tracking.)

    It may well be that I don't understanding the budgeting approach for agile well enough to sell it, but in companies where alternate development methodologies have been suggested, the ease of budgeting waterfall versus any other methodology has always brought companies back to that approach, even though the recognize the problems with it.

    An agile type approach I do use:

    Where I've used agile-type methodologies, companies have paid for functionality and really not been concerned how they got it. For example, a firm I'm working with now wants bi-directional distribution of documents. They want to be able to securely upload documents to a portal for their customers that their customers can download and also give their customers the ability to upload documents that they can download.

    That is an example of one of many projects we are doing for them. I wouldn't call our development methodology agile. Instead if I had to name it (and this is the first time I have), I'd call the approach "disposable". We show functionality to them and if they like, we keep it, if they don't like, we dispose of it.

    We work with a team from the customer that we call a "Requirements Team", but really they're an analysis/acceptance/training team. This team is responsible for articulating what the people in the firm want, accepting that what we've delivered meets those requirements and then they communicate/train the rest of the people how to use what we've delivered. All refinements/complaints come through the requirements team.

    Our reasons for taking this approach have more to do with corporate change management/communications and funding than they have to do with software development methodologies. One of the things which is unique in this instance is that development is not being paid for by the firm. (well not directly). The firm is owned by an external investor who has contracted with us to do several things: business process development, integration of other purchased businesses and automation/reengineering.

    The methodology (disposable development) such as it is, has emerged in response to the particular structures and funding situations for this firm.

    If I think about it, in most corporate situations, I would propose a waterfall approach due to the simplicity of budgeting. I might then be inclined to allow a more flexible methodology to emerge that fits that corporate structure and outlook, but it will be in response to the environmental considerations of that firm not any methodological approaches.

    My two cents worth, which is probably only worth less than what you paid for it...


  7. Outsourcing is just a decision as to who does the work. It is not a decision as to how the work gets done. We have a SDLC management solution and I have noticed some confusion from our users about Agile versus Waterfall. Both methodologies have the same or similar phases. Waterfall presumes that there will be very little discovery in process whereas Agile assumes that there will be lots of discovery. I favor Agile because, frankly, if there is little discovery, then you should be purchasing an off-the-shelf solution rather than developing something new.

  8. This post provoked a lot of great discussion, which is why I added it to my list of the best PM blog posts for the week. Visual aids are great for some purposes, but they can distort just as effectively as they inform.

  9. Anonymous5:14 am

    check out my blog post on waterfall and the challenges it presents from a BA perspective http://theitba.wordpress.com/

  10. I've just finished studying a company that has this dilemma. Their work fits the 'something else' space. To make this work, they borrowed elements from both. So some high-level up-front analysis happened, producing high-level requirements documents and schedules, with subsequent delivery done using agile. This approach kept the quite conservative project control boards on side, while allowing for efficient development with early ROI.

  11. Pato

    That sounds like a good common sense approach.

  12. All

    When I wrote this post I was never really sold on the model. Since then I have fully abandonned it and on't see it as useful.

    The comments here do a good job of highlighting some of the problems.

    After over a year using structured agile methods (scrum being a substantial part, but also xp and a touch of lean) I have to say that I belive it is altogether a better way for all types of projects, and ESPECIALLY ones that are large or complex.

    What can I say? I am sold.

    There are still many traditional pm tools and practies that are needed to properly run a project, but I find the important onces are all there in the scrum etc practices.