A co-creation of Carolin Salz & Thomas van der Burg
What are possibilities to slice down your product requirements and structure your backlog in order to increase impact for your customer? This is the question that Carolin Salz and I tried to answer. In a previous post we already shared her personal journey from Project Management to value-oriented business agility. With this post we want to share some of our results with you.
When we started with our Agile journey, we were pretty much focussed on introducing Scrum as a framework into project teams that were used to develop products in a classical waterfall process. This change had fundamental impact on how we created the requirements backlog for our products: Instead of randomly chosen processes for mapping the requirements for product development, we started to discuss our customer requests with the whole team. We agreed on the actions we need to take during the next sprint in order to build, calculate, design or evaluate whatever is needed. This was very helpful as jointly we were able to identify if everyone has the same understanding of what is required to be done to fulfil the customers’ requests – even the customer himself. However, it took not too much time until we understood, that not each request needs to undergo this highly creative and exchange intensive approach as Scrum offered it. For a great portion of requests, we were able to simply follow certain known processes. Especially when it came to routine and maintenance work there was a never ending discussion on the approach as many team members considered it to be a waste of time and energy to deeply discuss and refine this “well-known” work as they wanted to invest this time to the highly innovative questions that needed this divers approach.
As Forest Gump said: “Stupid is who stupid does”. Thus, some of the teams decided to divide their requests into two types: Innovative Work and Known Tasks. For the new fancy things, we still continued with Scrum. For the known things we experimented with some Lean Tools, Checklists and others but lately mainly used Kanban Systems to manage those.
This discussion came back again, when we changed our approach from “managing projects” to “continuously developing products”. In order to ensure an effective planning, which at the same time allows maximum transparency about the corresponding activities, we developed a Kanban system that ensures, that work is refined in the granulation of the upcoming work “Just-In-Time” to the necessary level.
Since the specifications and contents of the work packages change continuously during development due to progress and setbacks, too detailed planning generates waste for revision and rescheduling in the event of changes. Latest with this intention we needed to jointly structure the upstream and find ways and rules for valuable break down of work. Our approach was to define for each and every activity a Minimal Viable Product and develop in increments using small but insightful experiments. However, after a short period of time we basically found us discussing every request in thorough detail, instead of keeping focus on the things we really needed to innovate on. As with the problems we found with the individual customer requests in the teams, also on Portfolio Level it was obvious that not each customer request made sense to be broken down using exhaustive workshops with the whole team. It was clear that they simply needed to be sliced down in executable pieces.
The question was, are we able to systematically approach this and find kind of best practices when to apply what. In the following video we try to give some insights in our work related to this question.
Where is my product located?
While we used to concentrate more on the technical aspects of a request, we found that it makes totally sense to not just focus on the product requirements, but also on the environment where this product is located. Two important models help us here to gain clarity:
- Define the Development Environment using the Stacey Matrix
- Analyze the Product / Platform Maturity using the Wardley Mapping
Define the Development Environment using the Stacy Matrix
The British Professor of Management Ralph Douglas Stacey is and organizational theorist in the field of complexity theory.
He developed a diagram which helps to locate a certain idea, initiative or project regarding the situation of change it will face and is therfore a help for decision-making. With the help of the Stacey matrix we are able to gain awareness about how certain we are about What we need to do and How we want to do it.
The higher the uncertainty about the What, the more important it was to start with early prototyping, fast customer feedback and to leverage innovation tools to find creative solutions. The priority is clearly on the customer view and trying to find the first viable problem that we can solve in order to fulfil customer needs. This is pretty much linked to the purpose for our initiative to find a valuable solution to the most urgent problem the customer has.
On the opposite, if an initiative is pretty clear on the What but has quite some uncertainty on the How we want to do it, the strategy should be different. If the development environment for your initiative is located very low on the What-axis there is a great spot for breaking work down simply in the solution space. Since the requirements are clear, it is simply a question on how to best develop your product and evolve technology around it.
Maturity of my product: Wardley Maps
But purpose alone won’t help us finding the next best thing to do. We just thought about our own limited point of view. What we had to take into consideration was the specific context about the maturity of our platforms and it´s underlying technologies. Is it already a well-known and used technology? Is it something completely new? Are there companies out there who offer similar solutions as we need and are they available of the shelf?
A good tool which helps us making this clear is Simon Wardley’s mapping method. We mainly used it to map the different components, technologies and processes we require for our initiatives with regard to their specific evolution.
For our focus in this article we just concentrate on the x-axis. Wardley divides the evolution of a product in four steps:
The position of a product isn’t fixed – it just shows the stage of evolution at a specific point in time. Customer’s demand, development efforts and competition will move the technology further to the right.
With this analysis we are now able to draw conclusions on our best actions by finding best practices within a certain maturity category. Some general rules that you might want to experiment with:
On a genesis level there is a high uncertainty about the technology, it´s realization, customer requirements and so on. There might not even be a customer demand yet. We’re facing problems where we have to figure out what possible solutions there might be. It is a space of try and error and has a high risk of failure and needs a lot of effort. Here we need to reduce the costs of change, be flexible and adaptive. We need to learn more about the environment and possible risks. We are slicing work in the „problem domain“. A first step in this area might be making an experiment to find out more about our customer’s problems and to understand which risks might be ahead on our journey. It’s an area for research, experimentation and a very high level of learning. You are new to Agile? – here you might want to make your first steps using the principles.
On the custom build level products are individually built, need lots of effort and have high risk of failure. Customer’s requirements need to be figured out. They are super special, that’s why we are still pretty much in the “problem space”, but start slicing some work also in the „solution domain“ while still asking our customers for their input.
In the product stage we need to figure out what would be the most efficient way to turn our initiative in value for the customer. Slicing work in valuable increments which can be given to the customer step by step. We are mainly slicing work in the “solution space”. Apply Lean principles to the things that you do and aim for continuous standardization.
Within the commodity stage the focus is on how to do things better. We are in a stable environment, have a high level of certainty and need high operational efficiency. You dream about making your Lean Six Sigma Blackbelt? This is your chance! Standardize work, minimize effort and automate as much as possible. As a Development Organization you might be thinking about outsourcing, as the innovative potential in that area is not at all disruptive.
Knowing where to locate our initiative gives us a high situational awareness of our specific context and helps us to anticipate how the technology will evolve over time: From Genesis to custom built, from Custom built to product and so on. The map helps us also to discuss about what we expect to happen in the future, where to find “easy solutions” by external vendors that we can incorporate into our own technology environment and finally decide on how we want to act on that now.
To sum it up
The information gained with the help of Stacey matrix and Wardley maps helps us defining our strategy on what and how to do next:
- What is the next big thing to do?
- Why do we want to do this initiative?
- Where is our technology located in the specific development environment?
- What is the maturity of the different components of the required technology?
- Are there solutions in the market we can use?
- Do we need to consider outsourcing?
- …
Based on that we can create the respective Product Roadmap and agree on:
- What is the next best step to take?
- Do we slice in the problem space or the solution space?
- Which methodology do we want to apply for managing the work?
- Who is going to do it?
- What are the investments we need to take?
At the end it’s all about appropriate approaches regarding position of your product in context to its specific development environment and the opportunities you can leverage from the maturity of the required technologies.
Further resources and references:
Ralph D. Stacey: Strategic Management And Organisational Dynamic: The Challenge of Complexity to way of thinking about organizations
Agile Short Stories
Heads-up to all who want to read more about the early days of her personal journey: As myself, Carolin is part of a group of agile practitioners who contributed to a book on Agile Short Stories that will be available hopefully by the end of the year. Thus, please leave some space on your Christmas wish list! More to come…
