What does it mean?
The Agile Manifesto was first published in 2001 as a response to an industry-wide frustration in the 1990s: technology often failed to deliver software which met business and customer needs. Due to the time lag between business requirements gathering and technology delivery, systems failed to address changes in customer needs and business context. The Agile Manifesto is a set of principles which ensure the delivery of working value-adding software which meets the needs of demanding business users.
One common misconception about Agile is that, because it acknowledges ambiguity and encourages flexibility, it somehow lacks rigour and discipline. This could not be further from the truth: the rituals of a project run using Agile, once established, will have to be executed with precision, purpose and energy. It is no surprise that we have found ex-military personnel to be excellent in the role of Scrum Master.
Additionally, there are four values which have also been identified to guide behaviours :
- Individuals and Interactions Over Processes and Tools
- Working Software Over Comprehensive Documentation
- Customer Collaboration Over Contract Negotiation
- Responding to Change Over Following a Plan
These principles and values should be adhered to stringently unless there is a very good reason not to and that reason is understood, acknowledged, impacted and recorded.
Why do we believe it’s important?
Waterfall is a solid, proven methodology and appropriate for where a challenge can be categorised as “complicated”, that is, where there are many moving parts, but outcomes are predictable and problems have already been solved. For example, building a motorway bridge is complicated in that there is a lot to do, but the amount of concrete needed will be easy to calculate and its tensile strength is a universal known. It has also been done many, many times before. Digital solutions, however, increasingly embrace human factors and therefore move into the world of the “complex”, i.e. many moving parts and low predictability. Delivering these kinds of projects requires something else: a method like Agile which allows for changing tack, delivering quickly and feeding back emerging requirements.
The concept of Minimal Viable Solution (MVS), central to Agile, is well suited to our philosophy because it forces the question “what is the essence of the problem we are trying to solve?” early, and allows us to head to that milestone without the distraction of unnecessary functionality.
Using Agile, we have found we have delivered and gained invaluable user feedback early, which has saved time, allowed us to understand the real problem and led to a better overall outcome.
How do we put it into practice?
We delivered a new EPOS solution using Agile delivery for a global entertainment company. In order to embed this culture at this client’s, we first engendered buy-in for our delivery method by performing regular demos of our product as it evolved, sprint after sprint. Parallel to this, we trained and educated a number of employees in the organisation on how to use Agile (ensuring these principles were rigorously applied throughout the project with the benefits versus their traditional approach clearly communicated). This resulted in the successful delivery of a working solution which was quickly accepted by users and delivered an enhanced customer experience as a result.
We have found that we leave clients with a deep understanding of how to use Agile because they have seen it work for themselves. This is often a definite challenge, but is helped by the nature of Agile itself in that delivery of tangible benefits is rapid, and the majority of clients see the benefits of Agile and continue to use it after we have completed our work.