Problem-led Agile
This was first published as part of the Velocity Agile substack newsletter. To subscribe for more articles like this, click here: Velocity Agile newsletter.
Why do companies fail? They fail because their product or service fails to solve a customer problem. It can be the most beautiful product in the world, lovingly created, but the market forces will dictate that if no one needs it, no one will buy it — and the company will die. Take the publishing industry — half of the titles sell less than 12 (!!!) books, and 90% sell less than 2000 units. Despite the hundreds or thousands hours crafting them, if there is not a need, they are resigned to failure.
So the question is — what are the problems that agile is solving? And who is the customer? Our problem is delivering value to customers faster, and our customers are our developers and product owner (of course — caveat that our customers are in the end, our customers. But this framing is useful, as to be able to deliver valuable software, we need to solve for developers and product owners).
Often we lead with our tools and methodologies that we ‘know’ are needed. But how often do we start with the problems, let them appear, and then apply our knowledge to help solve them?
Not being problem-led is often the main cause of friction with developers in teams. A blanket implementation of agile methods often leads to the feeling of unnecessary process. Problem-led agile helps to solve this by everyone in the team understanding why each part of the agile methodology have been implemented, and the benefits it brings.
This process also creates better agile specialists. It forces us to think through each element of our methodologies and really consider whether its needed, and what problem it will help solve. It ensures a lean mentality where nothing is wasted, and no additional process is put in place.
The key event in problem-led agile is the retrospective. The retrospective makes it transparent to the team what the problems are, and is the most important event for the team to improve. Utilising the input as to what the developers and product owner find as current issues, the team can discuss changes to help improve their ways of working collectively. The Scrum Master / Agile Delivery Manager can use their toolbox of methods to help the team find solutions to these problems.
In implementing new solutions, there is a fear that methods will stick around in perpetuity, even if the solution did not fix the problem. Advocating for running experiments with teams to test out the solutions over a fixed time period again improves the working relationship with teams. It creates a dynamic of inspecting our solutions and determining if they were a success or not.
Often we want to jump in and solve all the problems when we join a team. But the most effective transformation I’ve had is when I’ve worked with the teams to instead find their problems and used the range of agile methods to try and solve them over a period of time through a series of experiments.
