We hear it all too often..
“We’re doing agile but it’s just not working for us.”
Hang on. Didn’t the agile manifesto give us all a blueprint for how we ship software early and often, delivering value to customers as soon as possible and learning from the results? How could a silver bullet like that not work…?
Well, first things first, there’s a difference between being agile and simply doing agile.
Agile misconceptions
It’s relatively easy to ‘do’ the surface level activities involved in agile delivery. There are numerous books, courses and coaches out there that can teach you how to create a backlog, write user stories and acceptance criteria, and run sprint ceremonies – and this is where the fallacy of ‘doing agile’ results in disappointment.
Following an agile delivery process might make shipping features easier compared to a lengthy waterfall process, giving product teams a clearer team focus in a short timespan and easy to read user stories (versus pages and pages of requirements). However, if an organisation does not take steps to identify customer frictions, prioritise the right initiatives, and respond to learning, then the features being delivered will have little impact on the organisation or its customers.
Doing agile delivery alone, no matter how well executed, will not overcome these challenges.
Delivery is one piece of the puzzle
For those not involved in product development (senior stakeholders, most commonly), a critical misconception around agile delivery relates to its scope; it does not cover the full end-to-end process that’s required to identify and deliver high impact features.
Agile delivery starts at the point where the business has already identified a number of features and bugs and is looking to prioritise those into a backlog. What agile delivery does not facilitate is the up-front work of aligning the organisation around what problems to solve and what solutions should be built. In order to achieve that, we need to consider the activities that lie upstream from the agile delivery process.
What’s the vision?
First, we need a strong product vision that unites everyone behind the product’s reason for being.
Without a strong product vision, the product team and wider stakeholders will have little to align themselves with when it comes to prioritisation. As a result, the team may try to satisfy too many customers, solve too many problems, and end up building a product that doesn’t work particularly well for anyone.
Where are we heading right now?
Even with a clear vision in place, the team then needs to be aligned on which are the most important problems and opportunities to focus on right now.
This is where milestone setting and OKRs are vital; if the organisation needs to hit a particular goal and the product is key to achieving it, then the product team needs clear direction and accountability.
Without milestones or KPIs to focus on, the team could end up prioritising features that – while valuable to the user and the organisation – do not contribute to getting the organisation where it needs to go.
What’s the right thing to build?
Once the team is clear on the problems and opportunities to go after, there is a risk that they still fail to deliver functionality of value, even with a well-oiled agile delivery process.
This is because the team needs to discover the right problems to solve, and then discover the right solutions to those problems through a process of iteration and testing. This is what we refer to as product discovery.
When teams do not have a product discovery process, they typically skip straight through to delivery via a series of hand-offs. The product manager gets given a problem (or, more commonly, a prescribed solution), they write up a number of user stories, which are handed over to a designer to design the solution, and finally the solution is briefed to engineering so that it can be estimated on.
Teams who employ this process are generally preoccupied with churning out features as fast as possible. By isolating key tasks to their respective teams, there’s no distraction or debate between functions, meaning tickets get written quicker. The critical downfall of this approach is that it doesn’t allow product, design and engineering functions to work together to figure out the right thing to build.
In his iconic book Inspired, Marty Cagan raises the issue of hand-offs in the product development process. If product hand-off a feature to design, then there’s little consideration for the wider user experience, making the product difficult to use. If engineering aren’t involved early on, then the opportunities to investigate the right technology get missed – there could be a new technology that product are unaware of, or conversely, there is a risk that product may prescribe a technology upfront that is simply not fit for purpose.
Handing-off features between functional teams for the sake of writing tickets quickly is certainly not ‘being agile’. Shipping a substandard product will simply mean the team will spend the months and years ahead re-working and replacing what they rushed to put out in the first place.
Putting it all together
Dual-track agile has become the modern standard when it comes to digital product development. It creates alignment between the top of an organisation and where it wants to go strategically, down to the product teams who are empowered to experiment around problems in order to discover the right things to build in delivery.
“Dual-track agile allows both tracks, discovery and delivery, to happen concurrently and with a great deal of team collaboration. It does not require that the discovery team fully define all product backlog items before the delivery team can begin its development work. The entire process is collaborative and nonlinear, involving the team’s key members (product manager, designer, developer) working together throughout the process.”
To be truly agile is to successfully master the art of agreeing a strategic direction, identifying customer needs, iterating quickly and cheaply to find the right solution, and delivering that solution with minimal rework.
This is why agile delivery alone fails, and explains how dual-track agile can unite organisations and create a safe space for product teams to experiment and collaborate.
Crucially, the dual-track approach requires a strong product culture from top to bottom. If your organisation is currently ‘doing agile’ without understanding where they’re heading or trusting their product teams to get them there, then it’s definitely time to step back and reflect – and avoid falling into the same trap and simply ‘doing dual-track agile’…!
