Worried about gas or electricity cuts? Despite a complicated energy context, SIG is redoubling its efforts to accelerate the energy and environmental transition in Geneva.
Guillaume Estoup, head of SIG’s Digital Factory unit, and Vincent Loiseau, SoKube’s Agile coach, give you an insight into the bottom-up approach used to initiate the transition from a project-oriented to a product-oriented organisation.
Why did SIG embark on such an adventure?#
- Numerous parallel and uncoordinated initiatives are launched around the same value chain or business process, generating additional costs and increasing the complexity of the information system.
- Project management is tied to the demands made by business departments, for whom it is important to get started as soon as possible. Here we recognise the false belief that the earlier you start something, the quicker you finish it.
- Deliveries are chaotic and users have little impact on value creation, creating a tunnel effect
- Employees are assigned to numerous activities at the same time (frequent changes of context, reduced efficiency, overload, fatigue).
- Arbitration based on the availability of resources (rather than on content) is far too frequent
- The average time taken to process requests is considered too long by requesters.
Based on this observation, SIG decided to introduce Agility into its organisation in order to optimise value generation, and to define the following objective:
“Depending on the specific context of the teams, put in place the most appropriate organisation to optimise value generation”.
– Guillaume Estoup (SIG)
What are the expected ambitions and the obstacles identified?#
This main objective has been broken down into three major ambitions:
- Reduce the Time To Market: on average, the delivery time for small requests of less than 3 days’ workload was more than 4 months.
- Improve the efficiency of value delivery, by focusing not on optimising working time but on optimising the time taken to deliver requests
- Improving the quality of deliverables to limit the need to maintain information system solutions in operational condition.
Having high ambitions is all well and good, but being prepared for a challenging road to achieving them is even better. This is why SIG has clearly identified its weak points in order to integrate them into the transformation process:
- SIG has an industrial corporate culture whose historical project management is based on a very high level of certainty
- SIG’s budgeting process is based on project allocation. Once these projects have been selected, resources are allocated to them.
- Each business unit manages its own project portfolio, resulting in identical or very similar but uncoordinated initiatives.
Reduce Time To Market#
SIG has set itself an initial intermediate objective, namely to deliver value earlier by reducing the Time To Market from 4 months to 2 months over the next two years. To achieve this, we worked on the following three aspects:
- building solutions in increments using a value-oriented approach, defining Minimum Viable Products (or MVPs), and identifying and simplifying the value-creation flows;
- facilitate good decision making via an empirical approach, by learning to manage uncertainty, by experimenting and by having the right level of skills in the teams;
- accelerate decision-making via a [team topologies] approach (/content/references/team-topologies/index.md), by delegating decisions as far as possible to the teams for the subjects they master, and by working to limit dependencies between the different teams and expertise outside the teams.
Improving efficiency#
What cannot be measured cannot be improved.
– Peter Drucker
Our first actions were to acquire the means to measure activities in order to better understand where we were not efficient, to limit manual operations, which were major sources of error, and to rationalise interactions with external teams. We adopted a value stream approach.
To improve efficiency, we had to imperatively limit work in progress, by making people understand and apply the principle of ‘Stop starting, start finishing’. To do this, we set up Product Teams in which we delegated priority management to the Product Owners. We instructed managers to limit the number of employees to a maximum of two teams in order to automatically reduce the cost of coordination. Within the teams, we encouraged them to limit work in progress by proposing to define work-in-progress limits according to their context.
And finally, efficiency is only possible if skills are present and shared. We have therefore set up communities of practice based on Product Owners and Scrum Masters training courses. We have also formalised the creation of a FinOps team to help our employees develop their skills in the financial impact of developing cloud-native applications.
Improving quality#
Who would be prepared to cross this monkey bridge? Especially without checking its quality? Not many! And yet in the IT world, people are prepared to work without a safety net. Odd, isn’t it? As with improving efficiency, the first step is to measure to raise awareness of the technical debt of current solutions. We then gradually improved the teams’ definition of done (DoD) by putting in place an increasingly large and solid safety net using a shift left testing approach. The quality of deliveries began to improve, making it easier to generate valuable feedback. To further reinforce this awareness of developing products in the right way, while ensuring that the cost of maintaining them in operational condition was as low as possible, we empowered the teams by giving them responsibility for operating what they were building, and for deploying it themselves in production by structuring and automating the deployment processes.
What has been done to achieve these ambitions?#
An Agile organisational transformation is first and foremost the learning of a new working culture, which is acquired and built step by step. So we didn’t take a big bang approach to this change and had to listen to three different triggering events.
The first is the operational opportunity. When a project is a candidate for doing things differently and accelerating the delivery of value, we jump at the opportunity and share the lessons learned with the other teams. For example, we built a product team with a strong focus on time to market and the ability to build and operate a new solution.
The second trigger was the desire to experiment in order to improve team efficiency. For each experiment, we looked to see which team could be a candidate.
The final trigger was the desire of the business departments to work differently. This trigger came about after we had had several resounding successes in the company. So we started by raising the awareness of the business units before helping them to identify opportunities for experimentation.
We learned the Agile culture empirically, by bringing on board people who were motivated by the change. This way, we didn’t get bogged down in useless and humanly complicated coaching.
Finally, we set up a governance team whose objectives were to :
- prioritise the cross-functional projects to be experimented (training course, quality of deliverables, community of practice, etc.)
- monitor the progress of these projects using a kanban board
- encourage the sharing of knowledge by carrying out retrospectives of these projects.
Where are we and what do we want to address next?#
