Agile as used in software delivery encompasses a range of development methods. The following paragraphs explain what typically happens in DSDM/scrum version of agile:

Generic agile development process

An agile part of a project is delivered in stages called ‘sprints’. They are several short development cycles of fixed periods. They typically last between two weeks and two months. The work of each sprint is to:

• Take list of requirements for a desired outcome
• Prioritize each requirement according to customer desire.
• The top requirement is the most important, the lowest requirement is the least important and may never be delivered.
• Develop the requirements in order of prioritisation
• Test the code and customer acceptance

Whatever is complete at the end of a sprint is called a ‘release’. Requirements not delivered within the sprint are re-prioritised for the sprint. Software developed in this manner can go through a number of swift releases. This allows rapid realisation of what an app/product could look like compared to its vision.

Small scale teams all working together

Sprints are undertaken by a small team of twelve or less people, wholly responsible for development and delivery. It is self-contained with no other responsibilities. The team will usually include:

• product owners,
• business-people, responsible to get the requirements properly developed
• software developers to create the appropriate code
• software testers who test the code.
• Usually a ‘scrum master’ who co-ordinates the team during the sprint.

No silos, no blame

Participants in sprints cannot be involved in other work because they need to be available to support their co-workers. Most importantly, the overall approach is one where everyone works in parallel. This contrasts with traditional methods, sometimes collectively called ‘waterfall’, where the project travels through set stages (such as business case, initiation, design, development, testing etc).

The biggest criticism of waterfall is it conveniently creates silos of certainty – where people know what their responsibility. We have all seen the result of silos,  where different teams blame other teams for lack of progress. This cannot happen in an ‘agile’ environment.

People talk, junk the email

Teams communicate verbally because they are all sat together in the same room. Time is not wasted writing emails or filling in databases.

Each day of the sprint starts with a daily scrum where the scrum master asks each team member what went well yesterday and what challenges they face today. None of the issues are discussed in the daily scrum, however because all the team members are aware of them, the issues can be dealt with through the course of the day.

Tear down the barriers, put up the walls

Success of the sprint is not guaranteed. It is entirely dependent on the hard work, skill and enthusiasm of its participants to succeed. Egos have to be let go because success depends on a collective approach to development. There is no single leader because everybody has a leadership role.

Sprints are culturally alien to many businesses that face pressures of traditional approaches. The different behaviour mean sprints are best hosted in their own workspaces and must have free access to meeting rooms.

Large office spaces in traditional organizations tend to make sprints difficult because staff not involved dislike the intense verbal and close communication that takes place.

Teams who undertake agile development are challenged continuously to learn from their successes and failures and therefore continuously change the way they do things. Agile development suits people who can embrace change; it does not suit people who want certainty.

Unpredictable outcome

The outcome is uncertain; instead, the completion date and cost are fixed. This means that if you need a product ready for 1^st January, you can guarantee it; however, it may be ‘ready’ without key features because some requirements may prove to be too difficult to deliver.

It is difficult for business change projects or for projects that have a physical output (like implementing a new service, constructing a building, or designing a car) to be undertaken in this manner. However agile can be used for conceptual phases within these projects.