One of the most commonly asked questions is “What defines an agile methodology?” Although there are many different agile methods in use globally, there is no single defined agile methodologies list that can be used to help.
One way to look at the agile methodology basics is to go back to the original Agile Manifesto, specifically its Four Values and 12 Principles. These don’t provide any agile techniques or prescribe the details of agile methods, such as the agile scrum basics or agile project management basics. But they do illustrate the thinking that should underpin any agile methodology. The manifesto states the following.
| We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. |
Any approach for developing software or projects that is not fully aligned with these agile methodology basics cannot truly claim to be an agile method.
Is Yours a Truly Agile Methodology?
The way to establish this is to review the approach and how it is being applied in real life and see if it encourages these values or not. As an example, let’s take a look at scrum. The scrum methodology basics should be OK, as scrum has been a very popular agile development methodology for a long time.
As defined, this agile methodology should encourage individuals and interactions over processes and tools through the use of daily scrum meetings with all the team. However, some implementations of scrum focus too heavily on the tools used to support the agile methodology process.
Sometimes the scrum master or the product owner deviates from how their role is defined in the scrum methodology basics and tries to direct the team as if they were the manager. Sometimes the need to align with the agile process methodology to value working software over documentation is used as an excuse to provide support teams with no documentation at all. This abuse of the agile techniques can give the scrum agile methodology a bad name.
Agile Methodology: 12 Principles
The same approach should be used to compare any agile methodology against the 12 Principles laid out in the Manifesto and shown below.
| We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity–the art of maximizing the amount of work not done–is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. |
These Principles have driven much of the thinking behind the software development approaches that are in use today by companies large and small. They have instilled a change in the attitude, behavior, and culture of many working in software development. The 12 Principles are essential reading for anyone working in this industry, no matter what their role is. It can be useful for the team as a whole to regularly reflect on them, as this will ensure that how they work in practice is still in full alignment with the expected outcomes.
While all of these Principles are important, the first is always the most important, especially the highlighted words within it. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Too often, these are ignored, and instead, priority is given to following the process. Regularly checking alignment with these Principles is the best way to ensure that the agile methodology you selected is being correctly applied and providing the maximum possible value.
Conclusion
Whether a methodology is agile or not is determined by its adherence to all of the Four Values and 12 Principles set out in the original Agile Manifesto, and not by its title. These all need to be followed; none of them can be missed out or glossed over. Rigid adherence to a methodology that doesn’t give the customer what they want is also not agile in reality. A methodology can and should be tailored to suit a particular organization by adopting and adapting the good practices. This has been proven time after time to be the best approach to getting the best results from any agile methodology.
