Patterns of Agile success – Part 2 of 6
This is the second in our series of blogs taken from our session Adapting Agile. It forms part of the learning pathway for Agile practitioners.
Following many years of practical experience, we have identified similar patterns in organisations successfully using Agile principles and practices. Here, we examine one of the most important for all Agile methodologies – delivering using increments.
Delivering using increments
The Agile Manifesto’s first and third principles are both about delivering in increments. Agile believes in getting pieces of working software in front of customers.
Increments have lots of benefits – they generate cashflow (or savings) earlier, they reduce the risk of major changes in the external environment derailing the project and they encourage simplicity of engineering. Most important, however, is the opportunity that incremental delivery provides to generate real and meaningful feedback from the most important people of all – customers.
What size increments? The Agile Manifesto suggests ‘a preference to the shorter timescale’, but this is open to interpretation. If you currently release software every year and you are reducing it to every 6 months, then you are on an Agile journey. As the company builds its capability, you’d expect to continue towards a shorter timescale. In general, the riskier or less certain your project, then the more you need feedback and thus the more frequent your increments should be.
Risks of ignoring the pattern
Smaller increments can feel scary. The temptation is to keep releases large – although this will increase long-term complexity and risk. Some companies feel terrified that launching early will give away their competitive edge. In fact, a company that is continually innovating can benefit from forcing competitors to play catch up.
Signs to watch out for
Are you really delivering increments?
An increment must be complete, offering genuine end-to-end value to the customer. It has to be finished – that means tested, integrated and ready to deploy. If you can’t press the button and deploy the product or service feature right now, then it’s not finished.
Are you able to go smaller?
One of the reasons that delivering in increments is hard is that dependencies are difficult to break down. These might be technical in nature because of the type of architecture you have. If so, is the organization willing to invest in changing or adapting the architecture to make it easier? Alternatively, it might be internal processes that are in the way. Are people prepared to put aside normal ‘requirements’ in order to permit an earlier incremental release? Does the business process encourage more frequent and less bureaucratic governance for new or changed features and financial approval? Finally, is the organization willing to invest in the kinds of tools that might help incremental delivery – automating integration builds, a dedicated server, etc.?
If you can’t answer yes to any of these questions then the organization’s commitment to incremental delivery is questionable and could be improved.
Additional Insights
The future of full stack engineering talent
The art of feedback
Don’t confuse tools with technologies
