Problem-solving not feature-building
SCRUM & LEAN UX | Episode 8
In one of the organisations I worked for I was drilled to ‘focus on solutions, not problems’. Now the authors of LEAN UX are teaching me to
“Fall in love with the problem, not the solution” — LEAN UX, by Jeff Gothelf and Josh Seiden.
I learned I often didn’t take the time and effort to understand and appreciate the true nature of a problem addressed to me. Now this is one of those little epiphanies for me personally. Our experience might or might not be alike, but here it goes: I learned that I generally failed to investigate:
- What conditions allowed the business problem to emerge?
- What causes the problem to persist?
- Why have others not solved it?
- Why it is possibly keeping people awake at night?
- What emotions does it raise?
- How does it impact peoples’ behaviour
- How does it impact their overall brand and/or product experience?
Sure, problems were solved, but what impact did it really make? Was I learning from it? Lean UX is guiding me to move from addressing the logical nature of a problem to the ecological nature.
So as I am journeying through understanding and applying Lean UX with Scrum Teams, in this episode I will guide you though my thought process. So feel free to jump in and think along. Although my context will vary greatly from yours, I hope we can fall in love with this problem together.
When applying Lean UX, Development Teams will experience that it shouldn’t develop features. They should develop awareness, transparency and solutions to complex adaptive problems.
Scrum (n): A framework within which people can address complex adaptive problems
But what exactly is a ‘complex adaptive problem’?
“A complex adaptive problem is one which is not well understood, and must be brought into focus through transparency, inspection, and adaptation. Hence in Scrum the problem and its solution can be expected to co-evolve sprint by sprint.” -Ian Mitchel
Now applying this mindset is hard. For this shift to occur within the organisation is even harder. So, trying to be true to this new mindset, I started by developing awareness and creating transparency. I’m aware this will be a slow process (this series is part of that process).
First of all, I introduced and rehearsed the Lean UX Canvas with the Scrum Teams and key stakeholders, which starts by defining a business problem and answering a set of questions as a team.
Now this is really powerful tool that allows the whole team to chew through a business problem and it really creates a lot of transparency from the get go. I learned however, that it doesn’t quite cut it.
Now the nature of the problem I am addressing is what I believe to be three-fold (and as it is adaptive, it could turn into a proper origami-fold).
- Development Teams might not really be grasping the world beyond the product (the ecosystem).
- They might be narrowing down possible solutions to those which include the application of their key skills (like writing software for example).
- They might be mostly engaged in a ‘Deliver, Forget’ cycle instead of a ‘Learn, Build, Measure’ cycle.
Deliver and Forget happens when the thinking goes somewhere along the line of: “If they (Product Owner and stakeholders) accept to release it after review, why put in the extra effort to revisit them? No news is good news… and after all, it is ‘Done’, right?!”. It pretty much boils down to: “If the Product Owner and stakeholders don’t see the value in us spending time and effort on it, why should we? wouldn’t additional effort be wasteful?”.
What a conundrum. The teams are in ‘the cave’.
I began monitoring (inspecting) how often the Development Teams ship fixes and features as ‘solutions’ without ever revisiting them or exploring how they impacted actual end user experience (and behaviour).
I’m learning how the Development Teams are actually shipping new problems alongside its solutions (complex environments, sigh).
Shipping features vs addressing problems.
So in my (early stages) of the journey of practising Lean UX with Scrum Teams, I’ve run into the following challenges.
- How can I promote spending time and effort exploring the ecosystem of the product continuously? (which involves getting real user data on their behaviour and experience).
- How can I prove that it pays to spend time and effort on work that is already “done”?
- How can I explain that, by exploring the context of a problem (the world beyond features), we can get to a wholly different problem than the one originally posed, leading us to develop the right solutions, in wholly different ways, from what we previously would have been able to imagine.
- How can I explain that some problems can be addressed, not through developing features and fixes, but through developing awareness and transparency?
- How can I learn how we can get actual customer insights and feedback and learn from those?
- How can I get closer to the user and learn to involve the user?
In short, how can I unleash this Tsunami of Sense unto these poor Scrum Teams?
Now, perhaps the answer can be as simple as changing the “How can I” to a “How can we” and invite the Scrum Teams to fall in love with the problem with me.
I hoped you’ve been able to follow this train of thought and hope you would like to share yours.
Thanks to Max Heiliger for reviewing this episode.