Are you transforming a process or a culture?
This is the first chapter of our story about changing from a classical IT organization to something totally different. Paul was an employee of BESTSELLER and Product Owner of the Agile Transformation. I was hired as an external consultant to help with the transformation. This is our story.
5
min read
October 28, 2020
Læs dette blogindlæg på dansk
We have chosen the theme for the first chapter. By voting at the bottom, you can influence what the next chapter will be about. Before you vote — take time to read and give your thoughts on our experience.
Background
Back in 2018 BESTSELLER IT (called IT in the following) was in a situation where they were very busy but delivered limited value. Our owner and CEO stated in several gatherings that IT was not delivering enough value to the brands, he expected growth in the business which also would require a significant change in the deliveries from IT.
The culture was characterized by very dedicated colleagues who knew the business they were in and enjoyed being a part of “The BESTSELLER family”, as BESTSELLER is a family-owned business. This was a great foundation to build on.
Unfortunately, some less optimal patterns had arisen in IT over the years. The organization was divided into Plan-Build-Run with a series of built-in hand-overs:
- Typically a Business Relationship Manager talked to colleagues outside IT and gathered requirements.
- Then the architects (both enterprise and solution) took over and designed and estimated the solution.
- This was approved by a board and put in a prioritized queue, from where it would potentially be taken into development within months or years depending on priority.
- The development team developed it, then it was handed over to release and it was now the responsibility of the 2nd level support to support the solution and handle whatever happened in production.
The delivered solutions often did not match the need of the colleagues in the brand, either because requirements had changed due to long delivery time or because the interpretation happening during all the hand-overs had changed the needs into something else. The result was that no one really owned the solution and if something went wrong it took a long time to figure out why and how it failed and how to fix it.
Starting the change
When we started experimenting we were very aware that much more than a process had to change, we wanted everyone to take ownership and end-2-end responsibility. The culture in itself had to change and we had to create the conditions needed to make this happen.
We experimented with a lot of things, having a larger span of control, changing the role of the team from being a specialized team to consisting of the roles needed to deliver the product from requirement to production and beyond. The first experiment was with teams across the organization, who tried out different structures — all with a focus on moving the responsibility of the product to the team who develops it. It turned out to be a huge success from the very start. Within four months the statement from colleagues in the brands was that the teams clearly understood the requirements better as well as delivering much faster and better solutions.
This lead to changing the entire organization (approx. 25 teams) into Scrum Teams with clear product ownership (+ a few component teams). The change in the organization can broadly be seen as below:
