Has your organisation changed its ways of working to Agile but still not improved significantly?
Many organisations struggle with Agile. They adopt an Agile framework such as Scrum, but do not see any benefits. For some this is because they are just paying lip service – for example holding Scrum events, such as the Daily Scrum, without really changing their mindset.
But even if you are living the Agile mindset (as described in the 2001 Manifesto for Agile Software Development), your goal might seem elusive.
What is your goal?
Implementing an Agile approach such as Scrum should not be your goal: Scrum, Extreme Programming, Kanban, etc. are all just approaches to help you achieve your real goal. So what is your real goal?
When I ask this question, a common goal I hear is: ‘We want our teams to deliver faster.’ This makes sense because the Agile Manifesto talks about satisfying customers through ‘early and continuous delivery’ and encourages people to ‘Deliver working software frequently’. It even states that ‘Working software is the primary measure of progress.’ (It was written by a bunch of software people, but you can change ‘software’ to whatever your product or service is and it still works).
Therefore, it is understandable that faster delivery is a common battlecry of management, especially in those organisations who consider themselves ‘agile’.
The problem with faster delivery
I find that many organisations overlook two significant issues when focusing on this kind of goal:
What problem is being addressed and who wants it?
What quality is desirable?
The example I use is serving diners in a restaurant. We identify that we have a large number of hungry diners and the boss pushes us to serve these customers as quickly as possible. If we focus on speed without considering quality, we push out an omelette every 30 seconds and serve up disgusting omelettes to our customers who never return.
If we focus on speed without considering our users’ needs, we only find out that we are serving omelettes to vegans once plates are hitting the tables. Our solution of faster delivery has not satisfied our hungry diners and we have lost those customers forever.
The quality issue is relatively easy to resolve by refusing to relent on it; a less complete product or service doesn’t have to mean poor quality, it might just mean a more limited functionality is available in the early days. Reduced scope, not reduced quality.
Unfortunately many agile-minded organisations are falling down with the other issue, often rushing into delivery before they know what it is they should be supplying.
“Before beginning a Hunt, it is wise to ask someone what you are looking for before you begin looking for it.” — Winnie the Pooh
Building something, then telling people that they need it, is a really hard way to sell a product or service; we should be trying to fulfil a real, existing user need.
However, we, the organisation, do not know what the most important customer need is. We might think we do, but that is usually just an untested assumption. And whose assumption is it? The team’s? The CEO’s? That of some other expert within your organisation?
Your customers are best placed to tell you this. I am not suggesting we should simply give customers what they ask for. Although Ford never actually said ‘If I had asked people what they wanted, they would have said faster horses’ it still gets the point across that blindly giving customers what they ask for is not necessarily a good idea. Organisations need to consider their customers’ needs, wants and desires alongside their business needs.
The sweet spot is the intersection between the organisation’s vision/purpose and the customers’ needs/wants/desires. Only then should you start to move towards a delivery phase, via solutionising and prototyping phases.
Is the Agile Manifesto wrong to focus on delivery?
Written in 2001, the Agile Manifesto set out some principles that covered a collection of approaches to making software, including Scrum, Extreme Programming, and Crystal Clear. It addressed a variety of bad practices that were common at the turn of the millenium: 12-month projects with a big bang release at the end, teams working in silos, ridiculously long and detailed requirement documents, risk pushed to the end of the project, and so on.
It did not prescribe how to approach every project. It deliberately left lots out, for example it does not mention setting a vision or purpose, but I am certain the creators meant for you to have them. So, it is not that the Manifesto is wrong; it is about how people are interpreting it.
It’s all about interpretation
It is beneficial that many organisations have absorbed the words in the Manifesto. This has enabled them to break free from their old, unhelpful ways of working. They are now able to release products and services sooner, thus reducing risk and delivering value to their users earlier.
The smart organisations are aware that the Agile Manifesto does not give them a step-by-step guide. They recognise that they are expected to do their own thinking too.
Unfortunately, there are some organisations who take a literal reading of the Manifesto, as if it were gospel. These organisations adopt a we-only-do-what-it-says-in-the-Manifesto kind of attitude, and are at risk of missing the crucial early step of product/service development: understanding what the goal is.
They fail to understand what it is that their customers need. They fail to understand what the ‘value’ is that the Manifesto demands be delivered early and continuously. These organisations are like the restaurant that optimises to push out two omelettes per minute … but fails to recognise that its diners are vegans!
A sensible option is to follow the double-diamond approach, created by Design Council. This starts by understanding your organisation’s purpose and problems. It then looks to understand your customers’ problems, gather insights about those problems, and find potential solutions… At this point you can start your prototyping and iterative delivery.
It is not that the Agile Manifesto got it wrong; it is that some people are following it blindly and missing the initial, fundamental step of discovering and defining the problem that they are trying to solve. Doing a bit more thinking really is important before you rush into trying to speed up your delivery.