Home > Software Engineering > Agile vs Waterfall: how to end the debate

Agile vs Waterfall: how to end the debate

I have been a witness – and later a facilitator – of Agile vs every other AMF (Approach, Methodology, Framework) – for the lack of a better word.

As a facilitator, I also managed to end this debate in many organizations.

This debate should produce a clear roadmap for the team to solve a real business problem where technology plays an enabling role.   However, this very debate has been the reason why so many technology initiatives have failed.

If you are a CIO, CTO, or technology executive being placed in the position of facilitating this debate in your own organization, I hope this blog entry will help you end this debate – for a long time (or at least several budget cycles).

This may be a surprise.   The very reason why this debate exists is because – despite your every effort as a leader – you haven’t shared with your organization  what I call CTO Manifesto:

1.  “We are in the business of solving business problems, better and faster than competition”
2.  “We view technology as a competitive differentiator, and plan to be better at this than anyone else”
3.  “We care about the top and bottom line;  technology investments will have a direct & positive impact on both”
4.  “While solving business and technology problems, every technique or tool will be used or combined to achieve Goals 1, 2, and 3″

Goal 4 – unless clearly stated and explained – will lead to a counter productive debate between Agile and every other AMF (see above).

Every problem any technology organization faces on the daily basis requires a thoughtful assessment, without a predetermined bias for a specific answer which may involve application of a specific solution approach.

There is simply no substitute for a proper understanding of the problem first.

Unless the problem is properly defined – and all implications on complexity, architecture, delivery timeline, integration touch points, skills availability, organizational / training impact are at least discussed – the decision to use a certain approach as an overriding principle to solve the problem will almost always lead to a failure.    This will not be a technology failure.  This will be a failure of the technology organization to deliver  a solution which the business desperately needs to enter a new market and generate the next wave of revenue.

Many industries have ended this debate by doing what makes sense:  first – understand all  critical dimensions of the problem, then apply the right mix of tools and techniques to solve it.

Example 1:  Let’s try to build a helicopter using a pure Agile approach

– Without knowing the speed and payload requirements in advance, it’s very difficult to delay worrying about the engine and the main rotor
– Without  a proper understanding of physics (the torque generated by the main rotor), the tail rotor design will be forgotten
– The first flight without a tail rotor will be disastrous
– But:  once the need for a tail rotor is identified, several engineering team can work in parallel and quickly iterate through multiple designs
– Waterfall and Agile do exist and work well in this example

Example 2:   Let’s try to refactor a very complex software product using a pure Agile approach

– This is a perfect example, because without a proper understanding of specific goals (improve performance?  improve ease of installation?  improve error management between several components?) and how technology may have to change to achieve these goals, the effort will most certainly fail
– Improving performance is one of the most complicated software engineering goals.   It involves a deep understanding of where individual transaction are spending time in each architectural layer.
– Sometimes there is a need to write additional code just to understand where transactions are spending time
– Then, based on risks and benefits, several prototypes may be designed and engineered to learn which refactoring approach may lead to targeted objectives.  And it’s not always optimizing SQL to reduce the data access time.
– But:  once one of the prototypes becomes the blueprint for the solution, multiple iterations can be planned (some could be even be planned in parallel to save time).
– Again:   multiple techniques are required to solve this problem

There is no need for this debate.   The responsibility to end this debate starts with you.

Categories: Software Engineering
  1. May 2, 2011 at 1:36 pm

    Interesting post.
    How true are the words “The responsibility to end this debate starts with you”: whichever tool/process used, it is only toward a real purpose… that’s improve product.

  2. Nathan Cowan
    March 31, 2012 at 11:55 pm

    Leon, great post, I know I’m a bit late on commenting. Here is my thought on methodology frameworks – the framework you choose is there to assist in getting a successful outcome. Too many times, I’ve seen organizations use a methodology because they are required to (even if it doesn’t work well for the project) and in these cases, the process is not aiding in anything. I still remember at one place I worked required the waterfall methodology. The project was actually being developed with an agile approach. We had to generate various documents for the previous stage so we could be compliant with the methodology, such as generating functional requirements during a testing phase. Perfect example of a project existing to serve the methodology rather than the methodology serving the project

  1. No trackbacks yet.

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 )

Connecting to %s

%d bloggers like this: