The supermarket principle
What managers, in product development, can learn from supermarkets.
When it comes to product development, what do supermarkets have to contribute? Admittedly, very little. However, when it comes to the time required for product development, a supermarket is a very promising example of understanding what is important.
All of us have seen this before
You are standing at the end of a long supermarket queue with your fully loaded shopping cart and there is only one open checkout. Didn't you wish that someone would open a second checkout?
This situation is not so different from the one of a customer who, for example, requests a software function in a product. This is because the customer is now also in line, usually with other "supplicants" for product development, and waits until his request is implemented. In small organizations with a team, the situation for the customer is then similar to the shopping cart at the single checkout in a supermarket. The customer requests are processed one after the other. If a large number of customer requests are to be implemented, the queue can become very long, just like in a supermarket. The desire for true scaling and thus a faster throughput time (lead time) is evident.
Unfortunately, most companies fail with their approaches to scale. This is primarily because what happens in most cases is not what takes place in supermarkets. That is, opening a second full-fledged checkout and using parallelization to almost reduce the throughput time by half. The very approach that is often chosen in companies would probably lead to a revolt in the supermarket and look like this:
At the second checkout, now open, you can only pay for e.g. dairy products. At the same time, the remaining products can only be purchased at the first checkout. If we continue to apply this logic, additional cash registers for sausages, beverages, non-food, tobacco products, etc. will be necessary for better performance. So what's the result? Chaos! Customers are running all over the checkout counters, emptying and reloading, paying, and consequently getting out of the supermarket and through the checkout zone in a significantly slower way.
Now, this is what real scaling looks like ...
Curious how this can be implemented in your organization?
What is so obviously going wrong in the supermarket, is in fact a daily routine in product development. The scaling approach is not done by parallelization but by simply dividing the customers' request (shopping cart) into frontend and backend teams (dairy products and the rest). None of these component teams is now capable of implementing a customer request independently. In truly large organizations with dozens or hundreds of teams, we break up each customer request in such a small way that a vast number of teams are involved in customer value creation and this leads to growing interdependencies between teams. Which team is then responsible for the overall coordination? Difficult to say. In this case, such organizations usually introduce coordinating roles, such as project and subproject managers as well as epic and feature owners. However, this increases organizational complexity resulting in a large organizational overhead which contributes poorly to customer value creation.
Dear managers, have a look at the checkout area in supermarkets and create product organizations with structures and teams that can create customer value independently and in parallel. Understand the analysis, the design, the implementation and testing as well as delivering a customer value as a team effort. We call such teams: feature teams.
Feature Teams
Feature teams are the greatest asset for minimizing or eliminating processing times, dependencies, and handovers. They streamline the organization, which creates flexibility to ensure that the highest customer value can always be achieved. Essential attributes for companies striving for customer loyalty in the face of global competition.
Go for it!