Agile is hot – and has been so for a while. The multitude of benefits offered by Agile, particularly its ability to bridge the Business – IT divide, has clients naturally gravitating towards it. Sadly, we’re also hearing horror stories, where agile development ended up being ‘fragile’, causing expensive project failures. The perfect storm is usually a combination of one or more factors: an offshore-based outsourcing model, ‘fixed price’ contracts, large engagements and even over-zealous customers and/or vendors with no prior experience with offshore agile. The question is, how do you setup agile projects to succeed under these kinds of complex environments?
Based on our experience in using agile methodologies for implementing technology solutions for large, global, multi-geography clients, we have been able to crystallize a few best practices that can go a long way towards avoiding disaster:
- Importance of Size-based Estimation. Size-based estimation has been a tried and tested best practice in traditional software development environments. It allows the “amount of functionality” to be quantified separately from the effort. Agile on the other hand uses a more nimble and social form of effort estimation that is evolved over multiple sprints. Fixed price contracts require the predictability of size-based estimation techniques, whether (Quick) Function Points or other custom form, based on the user stories. Initial cost can be based on a high level definition of the expected functionality/scope and the contract predicated on the size of functionality to be delivered and the price per unit of size. In line with the spirit of agile, the actual functionality delivered however, may be different.
- Effective Specifications. The first principle in agile is that it is a futile exercise to try and lock down all the requirements upfront. This is often used as an excuse to have zero ineffective documentation. Although ALL the requirements cannot be documented upfront, effective Agile requires a lightweight but effective functional and design specification at a story level within each sprint for achieving scale.
- Requirements and Change Management. Agile requires diligent requirements and change management to succeed in a complex environment. I’ve seen the discipline of freezing the requirements for each sprint often getting compromised. As stories are frozen for each sprint, changing the functionality in a subsequent sprint is not considered a change – it is but a new user story. If a story is invalidated within a sprint for whatever reason, credit can be provided based on a pre-agreed percentage tied to the stage in which it got invalidated.
- The Agile Design Factory. Agile requires close collaboration and availability of the customer stakeholders for requirements discussions. Any delay in clarifying requirements causes a huge strain on the development team due to the short timeframe of sprints. In an offshore model, the issue is more severe as customer interaction may be limited by time zone and proximity challenges. A best practice that I’ve seen work very well is to have a dedicated design team that takes on user stories from the product backlog using some initial priority order and fleshes them out in a factory model, facilitating a more predictable implementation schedule.
- Right Architecture. One of the key challenges in agile development is architecture. A common mistake is to ignore architecture in order to satisfy the push for “customer visible” functionality. Lack of a viable architecture makes every subsequent sprint increasingly problematic and fragile, affecting project feasibility. The trick is to identify which user stories have an impact on the architecture and to introduce the “right amount” of architecture. Rather than define everything upfront, you should define what is needed and leave enough room for evolution. Every sprint requires the analysis of “architecturally significant” user stories so that the architecture can be evolved in a controlled manner. Architecture is very much an ongoing exercise in agile projects.
- Leveraging a Balanced Team. All developers in a large agile team may not be highly experienced. A combination of mechanisms, including focus on architecture, the agile design factory and the right development practices and tools can be used to leverage larger and more balanced teams in agile engagements. Development practices such as test driven development, static analysis and continuous integration can go a long way towards providing a stable foundation of code. Ignoring the maintainability of the code can be equally disastrous as ignoring the architecture.
- The Right QA Strategy. It is often difficult to build an effective QA strategy in agile projects given various challenges: lack of documentation, dynamic planning process and tight sprint timelines. Agile QA should take an end-to-end or user journey centric view during the sprint planning process, and prioritize and sequence related user stories in a logical order. Placing the test designers within the agile design factory and the test execution team close to the implementation team can facilitate an efficient and collaborative QA process.
I hope these seven best practices will help you overcome the array of challenges presented by a typical large scale, fixed price, offshore-based agile program. By leveraging these best practices, Agile can promote a strong foundation of effective partnership and collaboration between customers and their outsourcing vendors.