Why is Agile delivery not working for you?
‘Agile delivery’ has become a ‘must do’ in many IT departments over the past few years. As ambitious IT leaders and consultant sales teams are promising to deliver technology faster and cheaper through the magic of Agile, it has become almost unacceptable to follow any other delivery approach. ‘Waterfall’ has become a synonym for ‘old-fashioned’, ‘out-of-date’ and ‘inefficient’. Yet, many organisations are struggling in the transition to an agile delivery approach: missed business deadlines, poor throughput, budget overruns, and quality issues are not a thing of the past. In this article, I’d like to cover a number of potential root causes for why Agile may not be working in your organisation.
Insufficient Developer Quality: Agile delivery is based on a sequence of short delivery sprints where small development teams are incrementally extending the system’s functionality and continually delivering a working product. The requirements are no longer documented in lengthy design documents, but summarised in user stories and acceptance criteria. This approach requires stronger developers than Waterfall. Every developer needs to be familiar with the business functionality and the application architecture to be able to independently translate these summary requirements to a working application. The model does not lend itself very well to new, junior developers coming up to speed and learning about the application from more senior developers.
No Test Automation Capability: The test approach for agile delivery needs to support the short delivery sprints. Test rigour needs to be maintained over the short delivery cycles so that defects do not accumulate. For large, complex applications this implies a requirement for automated regression testing. Especially where the application architecture relies on code re-use, regression issues will be introduced during the coding sprint. Implementing and maintaining an automated test capability successfully and cost-effectively will be a challenge. Many agile delivery factories avoid this challenge by reducing the frequency of releasing the development sprints into production and reverting to a more traditional test phase every few development sprints.
Offshore Development: Agile development assumes a very collaborative working style between product owners, users and developers. Yet, many organisations do not want to give up on using cheaper offshore developers. In that case, setting up excellent remote ways-of-working will be key to the success of the delivery approach: video conference facilities and collaborative pods in the office. It will also benefit to rotate offshore staff to spend time onshore or to move the business teams to the offshore development locations for a period of time.
Lack of Trust: An agile delivery approach requires a greater level of trust and a more mature relationship between the business and IT compared to a Waterfall approach: Both parties agree to move forward without having defined a detailed specification for what needs to be delivered but the budget is likely to be fixed. A lack of trust will result in the business team continuously challenging IT’s competence and estimates, which will cause friction and unnecessary pressure. The only way for the IT team to earn the business’ trust is through consistent and constant delivery of commitments.
Lack of Planning: Using Agile does not eliminate the need to budget or plan. Before starting to code, it is important to confirm the budget is sufficient to deliver the overall scope. It is also important to ensure that cost and progress tracking are in place to ensure projects stay in budget. In many cases, agile projects start working on a product backlog without a plan to deliver the complete scope within the available budget. These projects may start off building ‘gold-plated’ solutions for the initial user stories and then run out of budget without having delivered the agreed scope. A recommended approach is a planning phase to list and estimate all the required user stories and allocate a budget to each story. A burn down chart can then be used to track progress against the plan.
No Minimum Viable Product: One of the key benefits of agile delivery: to fail fast and learn from incremental releases, will no longer be relevant when a system cannot be used by the business until many iterations have been delivered. For example, a telecom company may not be able to migrate customers onto a new operational support system (OSS) until a minimum number of products and features are available on that software stack. In case many iterations are required to achieve this capability, it is possible that issues such as poor software quality or usability issues go unnoticed until major re-work is required. In this example, careful up front analysis of the minimum viable product (MVP) to start migration onto the new stack will result in the system being used by real users and generating the desired feedback loop.
Poor Continuous Integration: An Agile delivery approach is based on short delivery sprints and frequent releases of a working product. Such an approach requires the development teams to be very efficient at building, testing and deploying new releases. Typically achieving this efficiency is the result of maturity and investment in continuous integration processes and tools.
A combination of the reasons above may be why your agile projects have yet to deliver the promised benefits. A review of the delivery approach will help you identify the root causes and the investment required to address them. In some cases, you may decide that a pure agile delivery approach is no longer the best way forward or even that the traditional Waterfall approach is the best way to deliver your application.
DMW Group has extensive experience supporting IT organisations tackle their application delivery challenges and optimise their software delivery models. If you’re still wondering why agile delivery is not working for you, please contact us to understand how we can help you meet your delivery commitments and regain the confidence of your business stakeholders.