Agile Software Development: Avoiding a Loss-Making Methodology Choice

Both Waterfall and Agile Methodologies Seem Hit or Miss

It is well-known that waterfall approaches tend to fail when requirements cannot be defined upfront, but recent evidence has shown that agile methodologies also sometimes fail under certain conditions.

For example, a public sector project selected a highly agile approach and failed to sort out the conceptual architecture upfront. This ended up delaying the project significantly since the methodology did not allow for it. A large international pharma company used a waterfall methodology for implementing its international customer relationship management system but found that the requirements had changed drastically during the project and regretted not using a more agile approach.

At the same time, some software development teams are highly successful using either waterfall or agile approaches. While the right people, skills and tools clearly play a role, we believe that the wrong choice of methodology is often a key factor to blame when things go wrong. Selecting the right methodology at the outset of the project will increase your chance of delivering the right quality, with the least cost, in the shortest time.

 

The Methodology Dilemma Is Much More Complex Than Waterfall Versus Agile

- it is a choice between more than 11 different methodologies

Many tech executives believe that the projects they launch should follow either a waterfall or agile approach, and often select the agile because it receives a lot of attention these days, see exhibit 1.

Exhibit 1: The simplified methodology dilemma in software development

 

The waterfall model represents a sequential development approach, in which development is seen as flowing steadily downwards (like a waterfall) through the phases: Analysis & design, development, test, approval/acceptance, and deployment, with customer contact focused in the beginning and end. The agile methodology is conducted as a series of short iterative development cycles, called sprints, with frequent interactions with the customer, decreasing the risk of not building what the customer wants.

However, there are not two methodologies to choose from, in fact there are at least 11 overall methodologies, see exhibit 2.

Exhibit 2: The real methodology dilemma in software development. Source: Oleto Associates analysis

Oleto Associates has worked with many software development organisations and found that all 11 are in fact in use, somewhere.

Two key characteristics seem to differentiate the methodologies:

• The approach to analysis and design (x-axis): Methodologies on the left-hand side are characterised by having a one-time initial analysis phase as popularized by waterfall approached. Methods on the right-hand side have continuous analysis phases as you will find in the more agile development practices.
• The approach to approval and deployment (y-axis): Methods in the bottom tend to have more one-time rollouts while methods in the top favour continuous deployment.

The 11 methodologies are:

• Classic waterfall: The development process follows sequential steps going from analysis & design to deployment. This is most suitable when requirements are well-defined upfront but if changes happen along the way it can be challenging to adjust.
• Iterative with ongoing deployment: Sequential development process from analysis to deployment. It has shorter cycles than the “classic” waterfall and more frequent deployments which reduces the risk otherwise accompanied with one-off deployment.
• Iterative with focused initial analysis: Initial analysis & design phase for the whole project followed by shorter cycles of iterative analysis, development and testing. This is followed a collective approval/acceptance and deployment.
• Iterative with focused initial analysis and ongoing deployment: Initial analysis phase for the whole project followed by sequential development cycles.
• Iterative with ongoing approval, one deployment: Sequential cycles of analysis, development, test, approval/acceptance followed by a single deployment.
• Iterative with initial analysis & design: Initial analysis and design phase for the whole project followed by sequential development and testing with a one-time approval and deployment phase.
• Pure agile: The project is divided into short cycles with frequent analysis, approval and deployment. This allows for the requirements to be updated along the way which makes it adaptable to changes. However, it can be challenging to plan the whole project precisely up front.
• Agile with initial analysis: By having an extensive upfront analysis phase followed by agile sprints it tries to use the best from both the waterfall- and the agile world.
• Agile with initial analysis and single deploy: An extensive initial analysis phase followed by agile cycles and a single deployment in the end.
• Agile with single deploy: Agile cycles followed by a single deployment in the end. Can be useful for projects where a solution needs to be rolled out at once.
• Multi-team agile: Several agile teams working simultaneously with an initial analysis phase for the organisation and for each agile team. This methodology allows large corporations to work agile.

 

Software Development Executives Should Make Conscious Methodology Choices Based on the Business Context

Rather than setting up the software development factory to master only one methodology or just use the methodology that worked last time in a new project, a deliberate choice should be made for each new major software development project:

We recommend four key actions:

1. Avoid the "religious" methodology discussion: Experienced software developers and architects tend overtime to develop biases towards certain approaches they favour. When experienced developers from different backgrounds then join the same team a “religious” methodology discussion typically breaks out, often ending in no agreement on the exact methodology to be used. The key is to foster an open mindset about the true business drivers for the project and then drive the team towards a joint decision which all need to be loyal to.
2. Select a methodology based on the business context: For each project, the development methodology should be chosen based on the business drivers, e.g.:
   • To which degree are the basic requirements known?
     Projects with unknown up-front requirements tend to be positioned at the right-hand side in exhibit 2.
   • Is there a need for intermediate software releases?
     If it is necessary to emphasise an incremental product development approach and end-users need multiple touch validation points you should select a methodology in the upper section in exhibit 2.
   • How big is the project?
     The larger the IT-projects tends to be, the higher the need for upfront conceptual architecture and scope definitions. This is pushing the methodology choice towards the left-hand side in exhibit 2.
   • What is the nature of the project (new system or add-on)?
     For new system development, we recommend approaches with a more thorough initial analysis as shown on the left side in exhibit 2. For add-on projects, we recommend the methodologies in the opposite direction.
   • To which extent can UI/UX principles be clarified with the end-users upfront?
     For situations where the user experience and navigation scheme is known upfront, less ongoing validation with the users is needed, pushing the methodology choice towards the left.
   • What is the cost of the preferred methodology choice?
     Methodology choices also need to be seen in the context of implementing them. Costs for, e.g., training, artefacts and tools need to be considered. For example, if an automated testing infrastructure is available then the incremental cost of using more continuous deployment is less. Please also refer to the next point.
3. Tailor development processes and tools to the choice: Each choice of methodology has its own set of artefacts and processes, procedures and guidelines. These should be aligned and confirmed once the methodology choice has been made.
4. Evaluate your methodology choice: Both during the software development process and after the end of the project, the software development organisation should review the team’s performance with the chosen methodology and align accordingly.

Methodology selections in software development are business critical but difficult choices. Many software executives feel secure once they have chosen approximations to SAFe, Scrum and DevOps, but there is no guarantee that the methodology provides the right fit in the given situation. This increases the risk of delivering the wrong quality, at a higher cost and over a longer time. They should reconsider the methodology choice every single time. 

About the authors: This article was written by a team of consultants from Oleto Associates, a strategy consulting firm based in Denmark. For more information please visit www.oleto.com.

July 2019