Agile methods

Is your organisation ready for agile IT projects?

What defines the agile method and under which circumstances should an agile method be considered?

The wish for an alternative to the traditional development and implementation waterfall model has existed for many years under the common denominator agile methods.

Is your organisation ready for agile IT projects?

Traditionally, agile methods have been a subject matter for software development in the private sector. However, the tendency is becoming more and more widespread – also within e.g. public system procurement projects.

The content of this article was originally authored by Torben Schütze.

1. Introduction

The wish for an alternative to the traditional development and implementation waterfall model has existed for many years under the common denominator agile methods.

Traditionally, agile methods have been a subject matter for software development in the private sector. However, the tendency is becoming more and more widespread – also within e.g. public system procurement projects.

In this article, we will take a look at what defines the agile method, why and under which circumstances an agile method should be considered as well as the pros and cons of an agile method over a traditional waterfall approach.

Hereafter, the article will focus on what requirements the agile method has to the customer’s and the vendor’s competences, resources and organisation. Finally, the article contains a separate paragraph on the use of agile methods in connection with IT sourcing in public institutions.

2. What are agile methods?

Agile development is a collective term for different iterative software development methods. The most popular agile methods are Scrum, Extreme Programming (XP), Crystal Clear and Dynamic Systems Development Method (DSDM).

The agile manifesto

Agile methods are different in their approach and content, but share the same vision and values through a manifesto with four fundamental values and twelve additional principles. The manifesto’s fundamental values are:

• Individuals and interaction are more important than tools and processes
• Functioning software is more important than detailed documentation
• Active customer involvement over contract negotiations
• Flexibility and willingness to change over following a detailed plan

Agile iterations are a maximum of 1 month long

All agile methods consist of short iterations of two weeks to one month where every iteration concludes in a finished module or component of the finished system. Every iteration includes both customer and vendor in close cooperation in teams. Depending on which of the agile methods is being used, there are a number of different roles and processes to be followed. For all of them, however, focus is aimed at close, daily cooperation in the team.

Focus is on creating fast results and visible business value through the ongoing iterations characterised by continuous short-term planning, design and development, test and deployment.

Agile methods lead to completed iterations that are typically time-boxed, i.e. have a deadline of two weeks to one month. The customer chooses which activities should take highest priority on an ongoing basis.

The traditional waterfall model

Every iteration results in a finished product that is typically an independent module or component in the final solution. In principle, each iteration contains the same phases as a traditional model, i.e. planning, analysis, design, development/build, test and deployment.

The article continues below

Thomas Gottschalck
Thomas Gottschalck
+45 4138 0041

3. What is a traditional waterfall model?

As a ground rule, the traditional waterfall model requires that everything is specified, estimated and planned in advance. From there, the project follows the predefined scope.

Cons of the waterfall model

The model is made up of a sequential process from specification and planning of a project through analysis, design, development and testing in the development phase. When the system has been tested, the final product is ready.

When the test has been completed, the system is typically deployed in the test environment, and often it is not until this point the customer has a chance to assess the usefulness of the system.

The traditional waterfall model

If the scope is changed during the project, these changes will typically be dealt with through a formal change request procedure resulting in a changed scope and an adjusted contract.

The waterfall model’s faith in everything being foreseeable can, however, result in either solutions that are too large with superfluous functions or outdated solutions that have been overtaken by reality and the market once they have been completed.

This is because:
• There is a lack of consensus on direction and prioritisation of the solution
• Market conditions and needs change quicker than the development of the solution
• There is a gap between what the customer really wanted and what is being delivered – the written word is perceived differently
• As a consequence, the solutions are more extensive and expensive

The waterfall method’s focus on carrying out the plan – in opposition to the agile method’s focus on adapting each iteration – is thereby the main reason that the method does not always deliver the value that was intended to the business.

This is a translated excerpt of the article which was originally published in “Ledelseshåndbogen”