Fail fast or run around in circles?
I met with my ex-boss last week and she gave me a book to read about Lean vs Agile vs Design thinking knowing that this has been an issue, challenge etc. for me for the past two years. The book starts with a nice recap of the problem: agile, lean and design thinking can’t always find common ground to achieve common goals especially if different disciplines have a limited (mis)understanding of the three viewpoints. In theory, the three are sharing views such as customer-centricity but in practice it seems that there are as many interpretations of each method as there are practitioners, which often leads to endless debates about what is true agile/lean/design thinking and what is just a mess.
The organisation I was working in for the past two years was very innovative in its ways of working. We tried our version of self-organised agile teams modelling ourselves after Facebook and Spotify and adjusted as things fell apart. Towards the end of last year, we added Google’s OKR (objectives and key results) method in the mix to make ourselves more focused and efficient in achieving our goals. In the beginning, I was relatively enthusiastic about these attempts as they put the end user in the center, and gave the design team a chance to run so-called experience missions where we were allowed to build our backlog based on user experience targets. We attempted to be data driven in our requirement definition looking at user research, usability testing and different types of end user channels as sources, and we tried to come up with different metrics for measuring the success of the outcome.
Despite good intentions, there were several areas where we struggled. For example:
- Our product management function was sacrificed for the self-organised teams, which meant that there was no higher level planning function, or roadmap.
- As a result of the above, our backlogs were very fragmented and composed of small topics, which made it difficult to achieve bigger goals or more overall product improvement.
- We could not come up with a way to efficiently study and frame topics. This meant that we were constantly in a push and pull between sprint zero and waterfall.
- We could not make product definition and design processes transparent enough, which made others perceive these as not data-driven but guessing.
- We had immense problems balancing between minimum understandable experience and measurable change. There was really only an imagined connection between a data point and the metric it impacted.
- We were constantly changing our way of working without facilitating the change. This meant that there was no clear accountability, sense of urgency or common achievements.
- We put a lot of emphasis on learning but did not really talk about it.
I am not sure I can offer improvement ideas, but from the design perspective, I believe a shared, internalized strategy and a roadmap beyond quarterly objectives and key results is a must regardless of what process you apply. This makes it possible to have a shared understanding of how to achieve longer term goals and frame the individual experiments. In addition, it enables creating and iterating on the framework design of which I am a great believer.
I also believe that if the solution space remains random (let’s just take the next idea that a person comes up with), there is no real learning, or the learning is very slow. Design practices can help clarify the solution space, especially if more participatory and transparent. However, I also think that some people are better equipped to make some decisions than others, so use dot voting sparingly.
I would also not question everything every sprint in the spirit of lean. It is difficult to build measurable experiences which communicate the necessary message so sometimes it is better just to execute on your strategy and measure later. If strategy is not working, it is a completely different conversation.
The intentions of all these methods are good, I believe. Of course we want to focus on things that are meaningful but when professions form around processes, it means that those processes often become enforced, not applied. As professions (agile coach, lean person, designer), we are justifying our existence by creating narratives around what is the added value we bring, but if we concentrate on battling religion, there will be no outcome, just endless talk.