Fail fast, aka life in product development
When you think agile development, you probably think of Silicon Valley coders post-it-ing their way to the next killer app, poring over user analytics seriously through their geek-chic hipster-something spectacles.
However in recent years there has been a push in other industries to apply the principles of ‘agile’ to get results faster and more efficiently than their competitors.
This often means cherrypicking some of the things that ‘seem doable’ from agile. The problem is, the success of agile as a methodology generally relies on applying it 100%, but it was developed specifically for use in software development. So, is it actually feasible to use agile outside of software?
Giving agile for business a shot
I’ve been part of teams applying ‘agile’ in two industries (education and finance) in very different settings.
The first was consulting for Spire Education, where we started with the challenge of designing and executing a training programme for aspiring managers in a month (does that sound agile enough?) and then pivoted to designing a disruptive proposition for a new high school within 2 months.
As a start-up, we had a small but close-knit team of people from very diverse educational and cultural backgrounds. We had the liberty of changing organisational structure ad-hoc and we had relative freedom with how we used our resources, even if those resources were limited.
Every day, we were asking ourselves ‘How do we fail as fast as we can?’ ‘How do we get a customer voice on this?’ ‘What do we need to change to make it better?’
That meant speaking to at least 100 people over a 3 month period about jobs, careers and their aspirations in life, coming up with new methods to generate feedback at scale, and going through a rollercoaster journey of testing hypotheses.
Most recently in finance, I’ve been driving digital products and services within Barclays Kenya, looking at both new digital products and how to transform our customer experience and communications.
We have the challenge of running a ‘traditional’ business model within a fast-moving market and constantly pushing to create more value for both existing and new customers.
As a large corporate which bears the responsibility of managing many peoples’ money, we have budgets, stakeholders and controls at every level and division. You might think that this means we’re set in our ways, but there are many people who want to create change and do more for our customers. The only question is: how?
Lessons in applying ‘agile’
Here’s a few observations I’ve made while trying to use ‘agile’ outside of its original context:
- Customer research is non-negotiable. This might sound obvious, given the focus on testing within agile, but one of the first things some teams sacrifice on a limited budget is speaking to customers. Instead, they formulate hypotheses based on free desk research, or test with existing staff/customers who don’t necessarily reflect the target market.
There’s a frequently-misinterpreted quote (supposedly) from Henry Ford that is often used to justify skipping research: “If I had asked people what they wanted, they would have said faster horses.” The lesson here is not that you shouldn’t speak customers or ask them what they want. The lesson is that you need to understand their needs, not their solutions. The core truth is that people needed a faster way to get around.
- Success needs to be immediately measurable. If you’re launching an app, your success criteria might be the number of downloads, followed by tracking the actions taken within the app and later its MAUs. You can easily design small tests to be evaluated against this criteria. If you’re testing an education programme which is meant to change the trajectory of someone’s life over 20 years, it’s much more difficult to run small tests. What you’ll end up testing is not the need-product fit but the customer’s understanding of how to solve a need. Not to say that this is not helpful, but it’s a consideration for impact-based organisations.
- Autonomy needs to be discussed and understood. Autonomy is easy to say, difficult to high-score with in Scrabble and much more challenging in practice, especially where you are an existing company moving into a new structure. (Note that I say company, not corporate.) You need to have a very clear understanding within the team about what this means.
For example, what is the expectation around decision-making criteria? How will decisions made by a squad be communicated? How can they be challenged? How will learnings be shared? How will responsibilities shift?
- ‘Failure’ has to be factored into KPI-setting. Another way of putting this is that targets need to focus on high-level outcomes and not specific activities. Going with the idea of autonomy, the means takes second place to reaching the benefit.
- Budgets need to match agile working methods. The key input for a software product is time, namely man-hours for developers, project managers, designers etc. This makes it easier to determine budgets: even if your deliverables might change, you will have a similar budget as long as you have the same sprint length and number of sprints. If your product isn’t software, this can be more challenging. Costs might vary for the same benefit, which can change ROI (a finance nightmare).
All in all, there are some definite benefits to applying agile principles outside of software, but we’re likely to see an entirely new methodology grow as organisation explore different ways to get the same benefits (that is the agile way, after all). This is an ongoing journey and I’ll continue to share observations as they come up – would appreciate your comments, ideas and tips if you have been through anything similar.