Archive

Archive for May 1, 2011

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