Agile’s Origins and Practices:
Today, it divides opinions but everyone is talking about Agile, so what is it and where did it come from? Agile is very different from traditional approaches; it is an iterative approach to product development and:
- brings users and developers very close together throughout the development process.
- encourages or allow face-to-face communication wherever possible.
- allows flexibility in the development process, driven by Business needs and priorities.
Despite the above, Agile is not a method in itself. It is a philosophy towards product development, such as software development. It is often combined with methods, such as DSDM or Scrum, which can work well together with an Agile approach, to produce an effective development environment. Agile projects have already delivered some highly positive results, compared to some traditional approaches (¹).
Where did Agile come from?
Agile was started by a group of software developers around the following simple but powerful statements of values and principles:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The above statements can be expanded into a series of related practices, that can result in projects which:
- produce end products that more often meet user needs most importantly with less re-work and risk;
enabling companies to make real improvement in the delivery of projects, allowing the benefits of those projects to be enjoyed quicker and with greater success.
So, what are the important practices in an Agile development environment?
Agile development environments vary a lot and there is much in the detail, but the following are the most important core principles and practices that you usually see in an Agile environment:
- Iterative and incremental development – this can take many forms and can be called a number of things: (Sprints, Rapid Prototyping etc). The important factor is giving users (and business managers) early sight of elements of the deliverable. This allows early review and feedback on those deliverables and most importantly ensures that the interpretation by developers of a business or user need is successful before the development team moves on.
- Establishment of an effective team: all real Agile projects have an effective team at their core – not the ‘them and us syndrome’ – this should facilitate daily interactions between developers, users and business managers. The benefits of this are obvious and should ensure that no project should ever stray too far off track.
- Effective communication: Agile always favours face-to-face communication over all other methods. While this may be challenging in some circumstances, this principle can be extended or achieved in many ways.
What types of projects is Agile most applicable to and what are the major benefits?
Agile started life on software projects, and is most suited to those projects, providing the right circumstances are in place to adopt Agile. You cannot simply pick any project you like and attempt to use Agile to deliver it. Agile is especially relevant where there is real uncertainty about the expectations (and especially requirements) relating to the end deliverable. History has demonstrated for decades that businesses and users are very poor at defining clear requirements at the start of many types of projects (or just frankly don’t even do it at all). This is possibly the biggest single issue that Agile produces a solution for. As with all things, however, this does not mean that requirements don’t have to be defined by a customer or user. They do, but in a more progressive and iterative nature, where users and developers work together. There are many claiming that they are using Agile where in truth they are more riding the wave rather than actively using the principles of Agile.
Key Attributes of Agile Projects
Common misconceptions about Agile Projects:
There are many misconceptions about Agile, and none of the following are true:
- we don’t need to plan with Agile – planning in Agile may use different techniques, models, etc, but every project needs to plan. In Agile the names of planning processes and products may be quite different to traditional terminology (e.g. “planning poker”) but we still have to do it.
- we don’t need to worry about budgets – businesses will always work to and within budgets. People who forget this could have very short careers in projects.
- we don’t need a project manager (or that horrible project management stuff! ). In Agile we may not use the term but the disciplines of project management will be still be needed. It’s a grave mistake to believe that anyone can do this role. We may not produce ‘traditional’ PM outputs, but we will produce others. If there are aspects other than the core development effort, you will still need one.
- Agile environments lack discipline – quite the reverse. They can allow a great deal more flexibility but at the same time they should provide a far more predictable outcome from development efforts, for many reasons.
- Governance is impossible with Agile projects: is totally untrue – or at least should be. Once again it may use very different data items and routines, but in most environments Governance must happen and be effective. Fortunately there are clear examples in business today where this is being achieved very successfully.
- Scrum automatically means Agile: Scrum is a development method that can fit very well with Agile but Scrum alone does not mean Agile – Agile is far greater than just Scrum.
So, are there some projects it is not suited to?
Yes there certainly are some. Agile is best suited to smaller project (teams) where interactions are frequent and relatively easy to manage – in other words this is very realistic. Much larger projects, or projects where teams and resources are in different countries for example, can still take on board some of the practices of Agile, with a resulting benefit, but will find the approach far more challenging. Projects where there is a very large design effort, for example Engineering Process Design, will always lean heavily on traditional methods, but could also take advantage of selected practices from an Agile environment.
Can you apply Agile to supplier produced projects (deliverables)?
Yes you can, but only if the supplier is able and willing to work in an Agile manner. As always, trying to introduce this approach after suppliers have already been chosen (and contracts are in place), is going to be challenging at best and at worst very unsuccessful.
Does Agile always work – what stops it from working?
Sadly no – it can and does work extremely well already for some projects and businesses. However, it requires and is often a major change to working practices and most import of all of course, people. To some people, this level of change may challenge long held beliefs, and if they cannot see beyond those challenges, it is not very likely they will succeed, or maybe even want to.
It also needs to be understood by senior management to the extent that they will support decisions (for example in the choice of key suppliers who will support an Agile environment).
Email today to find out more on how we can help develop or improve your Agile environment and skills.