Reflecting on my experiences delivering past large-scale transformation projects, Agile has certainly become the preferred methodology to implement customer experience (CX) solutions but agility is not without it’s challenges.
Agreed, an agile approach allows an enterprise to focus on business value and embed learnings into incremental cycles for continuous improvement. However the desire for agility in IT implementations can prove problematic, especially when business outcomes and project vision is sacrificed for product flexibility. While an agile approach can reduce uncertainty and deliver innovative business outcomes, it risks failure without adequate planning and control.
Agility vs Certainty of Outcome
While an Agile project team relishes the freedom to innovate, business sponsors require assurance that their business outcomes match their business case and are delivered within the approved budget.
The commercial realities of ensuring a systems integrator delivers on-time and on-budget can clash with the development team’s desire for a gold-plated solution that often includes ‘nice to have’ features that won’t add much value to the agreed business outcomes. This can lead to an unwillingness to compromise when grooming the product backlog and the conundrum arises as to how to deliver certainty of scope and budget within an Agile project methodology.
Like many, I too understand this conundrum contradicts the principles of the ‘Iron Triangle’ metaphor which unlike Waterfall projects, define that when dealing with project constraints in an Agile project, budget and time should remain fixed and scope is the variable component. However, the challenge for professional services organisations is how to embrace agility and collaboration while achieving the business outcomes for the agreed budget, and ultimately meet customer expectations.
A blended approach
Adopting a ‘Hybrid Agile’ approach is the best way I have found to manage the ‘agility and certainty’. Hybrid Agile combines the essential aspects of standard Waterfall project management methodology to create a delineated framework within which agile development methods are undertaken.
The key to a Hybrid Agile success is developing a High Level Design (HLD) at the beginning of the project which clearly defines the business outcomes against the definition of scope.
Striking the right balance is critical and adopting lean principles still apply. The HLD defines the project approach and principles, integration architecture, security, data model and required features and functionality for the project without delving into the low-level detail that would typically be attached to a traditional Waterfall approach.
Defining the HLD at the right level takes experience, but done well this approach creates a solid framework that informs the user experience design and development conversations, by establishing a common vision and approach and agreed architectural principles upfront. This ensures everyone is on the same page from the outset and the implementation delivers the outcomes promised at the business case stage of the project.
Don’t fail to plan…
A good HLD has multiple levels. Not only it is about defining the solution deliverables; but it is also about building trust and rapport through the process. Its just as much about gaining alignment across the project team about exactly ‘what’ and ‘how’ we are going to tackle the project and gaining a mutual respect for different perspectives.
Everyone has a slightly different view on what Agile is, so time dedicated to gaining alignment on requirements, business benefits and agreeing on the project’s approach and principles, will pay dividends and encourage a clear commitment from all project stakeholders.
Six essentials to a successful Hybrid Agile approach
A Hybrid Agile approach ensures the alignment agile mindset is managed correctly with a step-by-step structure that governs quality, the project’s commercial realities and balances the input of all stakeholders.
- Ensure the HLD is at the right level: not too heavy, not too light. It has to resolve ambiguity and provide a clear framework that informs the project teams decision making during the subsequent phases from a technical and functional perspective.
- Establish solid waterfall project management principles: such as defined phase close-out activities quality gates, budget and change control processes, and issue and risk management. After all, not everything can be resolved in a daily stand up-up meeting.
- Apply greater rigour to Sprint Planning: allowing the sprint team time to plan, design, build and test, and complete retrospectives.
- Understand cycle times: plan work to the sprint capacity, allowing time to embed concepts of Test Driven Development into the delivery process.
- Understand the principles of product grooming: with timeboxed sprint iterations, if something extra goes into the sprint backlog, then something needs to come out of the sprint backlog to maintain alignment to team capacity.
- Focus on business outcomes over scope: respect the ‘iron triangle’, its ok to exclude a project feature over another if it does not add sufficient value to the agreed business outcomes… even if it’s a really cool idea…
The true cost of making changes — even small ones — is often not visible to a project team. For example, even adding something simple like a new field on a screen, is an easy task, but it throws up a raft of technical considerations that may incur additional costs. If the field is populated, where does the data come from? Is there additional integration work required? Does the field need validation, what is the business logic?
There are also organisational and useability aspects to consider. Will users intuitively know what the field is for? Who has responsibility for that change, how will documentation get updated and who will communicate the change to others — all these factors add time and cost to a project.
Hard-earned experience has taught me that when the HLD phase is underdone, the next conversations around prioritising requirements become very difficult. An Agile project team bristling with collective energy is indeed a powerful force, but its focus can often be on being flexible, innovative, and resolving uncertainty in an elegant solution. It may not be cognisant of the commercial terms underpinning the viability of the project if the business outcomes are not clearly defined.