Improving Service Delivery by Factor 30
An agile team’s highest priority is to satisfy their customers by frequently delivering value. Close collaboration ensures that customers’ needs are met. However, when conditions change, it’s time to inspect and adapt in order to improve.
As part of Becton Dickinson (BD), BD Rowa™ is specialized in the development of automated systems for logistics, picking and packaging of medicine. Their customers include hospitals, pharmacies and distribution centers.
BD Rowa™ Digital consists of 20 people divided into small interdisciplinary teams. These teams develop and maintain seven applications that support business processes from merchandise management to device maintenance. Teams consist of software developers, administrators and data analysts who collaborate closely with so-called key users who represent other departments and contribute domain knowledge. Key users’ responsibilities include consolidating requirements and developing adequate solutions together with product owners and development teams.
First understand where you are
In March 2020, agile42 assessed the Digital department’s challenges and identified a number of opportunities for improvement. While talking to different representatives of the department, it became clear that the existing structure did not optimally meet the department’s needs anymore.
Collaboration between development teams and key users for each business application and each department was challenging. Not every key user had the necessary domain knowledge, experience and authority to make decisions. In addition, some development teams were working on so many small requests from various departments that meaningful collaboration within teams and focusing on meaningful, overarching goals was difficult. This raised the question of whether planning iteratively and delivering customer value incrementally made sense or was even possible.
Probe, sense, respond
Together with representatives of the Digital department, we defined two experiments to probe effective structural changes. In this case study, we focus on the first experiment, which aimed to replace the CRM team’s iteration planning-based development with a flow-based approach. The expected outcome of this approach was more flexibility in the response to business needs and higher satisfaction of both key users and developers. In our experiment we were guided by the principles and practices of the Kanban method.
“After initial skepticism, the team decided to give Kanban a try. A clearly defined duration for the experiment of three months helped greatly to convince the team and the stakeholders to switch to this new approach. Even the most critical voices swiftly became accepting and eventually converted to real Kanban fans. They took the idea of ‘Stop starting, start finishing’ seriously and thus managed to focus on fewer tasks and consequently reduce the cycle time significantly.” (Alessa Leuschen, Release Train Engineer BD Rowa™)
The Kanban method suggests to “Start with what you do now” and to “Agree to pursue improvement through evolutionary change”. This means avoiding a big bang change or transition and rather introducing change in many small steps. This eliminates the fear of change and helps gain support from the people involved. Our first step was therefore to visualize the CRM team’s work and the flow of their work.
Visualize work and how it flows
A good visualization is key to effective collaboration and to identify improvement opportunities as it greatly improves transparency. We quickly identified all key activities necessary for the CRM team’s value delivery and visualized different work types, queues and commitment points on their Kanban board.
In this process it became clear that a critical step in the team’s workflow was the analysis of incoming requests. These analyses either resulted in committing to the implementation or in explicitly discarding the request. In the past, this had not been visualized appropriately. Visualizing the team’s workflow also helped to identify bottlenecks. For example, items were being tested by key users or other department representatives for too long, which slowed completion down significantly.
Limit the work in progress
Work in progress means the number of work items in progress at a certain time. Effective systems focus more on flow of work and less on worker utilization. When resources are utilized to capacity, there is no slack in the system and the result is very poor flow, similar to congestion during rush hour on the freeway. In knowledge work, we also encounter context switching, which can drastically reduce workers’ effectiveness. In Kanban, we limit the work in progress to ensure a smooth flow of work.
During our experiment, the CRM team adjusted its work in progress limits more frequently than anything else and measured the impact on their flow of work. The team observed that key users who performed tests regularly caused delays because they didn’t make testing their priority. A low work in progress limit alarmed the team regularly and reminded them to get in touch with key users in order to find ways to unblock items and free up system capacity. When limiting work in progress, a Kanban team needs clear and explicit prioritization policies.
Make policies explicit and review them regularly
One of the CRM team’s most important improvements was the prioritization of requests from their customers, the different departments. Together with their customers, the CRM team established regular replenishment meetings and defined clear selection and completion criteria. These policies were regularly reviewed and adapted.
“After initial teething problems, the process became more and more accepted and refined, to the point that currently such meetings are only required every other day. Kanban allows us to respond to new challenges with flexibility. Prioritization receives input from almost the entire team, allowing for great transparency.” (Christian Schröder, Service Delivery Manager BD Rowa™)
Implement meaningful feedback loops
Feedback loops are required for a coordinated delivery and for improving service delivery. Feedback loops in a Kanban system are the Kanban board, metrics, and any regular meetings.
To ensure a smooth flow of work, it’s important to monitor the utilization of a Kanban system. In the spirit of “Stop starting, start finishing”, new items are pulled into the system only when the system has capacity. This is the purpose of the replenishment meeting.
The CRM team established their replenishment meeting involving all relevant parties to make sure their system was replenished with meaningful work. Using their Kanban board as a visual aid and going through each workflow step from right to left, they collaboratively answered questions such as: What needs to be done to complete an item according to our policies? Where will this free up capacity? What new items can be pulled? This was helpful to ensure a smooth flow of work.
Manage the flow of work
Something that prevents work from moving forward in the process represents a blocker. Analyzing and resolving the root causes of blockers improves delivery speed and predictability.
One major issue the CRM team identified was the quality of specifications captured before or during the analysis phase of their workflow. To solve this problem, the team agreed with their key users and other customers on a particular format to capture requests. This significantly improved the communication during the analysis phase and had a major impact on the team’s delivery speed.
In order to better manage the flow of work, the CRM team benefited from the selection of a Service Delivery Manager from within the team. The Service Delivery Manager (sometimes also called Flow Manager or Flow Master) is an emergent role in Kanban and responsible for improving work efficiency. A Service Delivery Manager typically facilitates continuous improvement activities, observes any forms of waste, and ensures that the team’s policies are followed.
Improve collaboratively, evolve experimentally
Kanban is a method for continuous, evolutionary change. Changes are made collaboratively, involving all relevant parties and using safe-to-fail experiments. When experiments give good results and underlying hypotheses are validated, the change is kept. When the results are not positive, one can easily roll back to the prior state.
The CRM team regularly held retrospectives with their key users and other relevant customers to reflect on their collaboration and communication and to plan ways to improve their effectiveness. These retrospectives resulted in many experimental improvements related to the team’s classes of service, their policies, their work in progress limits and their feedback loops. The introduction of the Service Delivery Manager was one of those experimental changes that proved useful. We also regularly analyzed the team’s lead time and their throughput rate to measure the effectiveness of changes. This approach of trying things out, assessing the effects and then deciding how to leverage the learning helped the team to navigate complexity.
“Introducing Kanban shifted our point of view from developer-centric planning and reasoning to interdisciplinary boards, allowing for easier collaboration and shared responsibilities. WIP limits applied to both developers and key users, which allowed the latter to focus on finalizing tasks and unblocking the flow of work. With shortened feedback loops between developers and key users, everyone could remain focused on active tasks and heavily reduce cycle times.” (Jörn Schmidts, System Architect BD Rowa™)
Measure your improvement
The CRM team’s improvement over the course of six months is reflected in the following metrics which clearly show that the experiment was a great success:
- The standard deviation (indicates delivery predictability) improved by factor 30
- The average lead time (customer request to delivery) improved by factor 26
- The average cycle time (start of development to delivery) improved by factor 33
Authors
Simon Sablowski has worked in software development since 2001 and has held various managerial roles in agile environments since 2008.
Simon has been part of agile42 since 2015 and supports organizations by developing leaders and enabling adaptation to the challenges of ever-increasing complexity.
Lothar Fischmann has supported agile transitions and digitalization initiatives since 2015, gaining experience mainly in the automotive and automation industries. As a member of agile42 since 2020, his focus areas are organizational and leadership development, which he is also studying for his PhD.
