Product experts, such as Marty Cagan, have talked about the benefits of having product teams. While I agree with all the benefits that a product team provides, the reality is that lots of highly scaled organizations have feature teams and delivery teams. Rather than looking down on them and dismissing their setup, I like to embrace reality and find ways to improve their ways of working, for their specific context.
As a delivery team – you may realize that your team’s role is to support other product teams achieve their objectives. You provide them with the features and components necessary to roll out a vertical slice of the product. These teams are found more prominently at scale. An example is an infrastructure team that owns a specific part of the infrastructure. They can maintain/create/edit new infrastructures to enable other teams such as finance, sales and customer support. Another simple and commonly found example is IT support. Your team’s role is to enable other individuals and teams to use “IT systems and services” (however the organization defines that) with as much ease as possible. While it’s good practice to allocate a percentage of your time on discovery to find user problems proactively, lots of teams typically spend a big chunk of their time on closing tickets as efficiently and effectively as possible; in lean terms, with minimal waste and high flow efficiency.
This brings me to agile’s ugly cousin Lean. In all seriousness, why is Lean software development not as talked about and used in the context of delivery teams? After a stimulating conversation with Mary and Tom Poppendieck about the nuances of Lean, I believe there’s so much of it that we can leverage for teams working in a delivery/feature team setup.
Lean’s origins lie in car manufacturing in the mid 1900s. Henry Ford’s assembly line inspired Eiji Toyoda and Taiichi Ohno to create the Toyota Production System (TPS). TPS gave birth to manufacturing methods that are still used today such as Just in Time, where the aim is to reduce times within the production system as well as response times from suppliers and to customers. The commonly used Agile framework, Kanban, is one form of just-in-time production.
In the example of the IT team, you want to get your customer’s tickets from one end of the workflow or value stream (principles #2 and 4) to the other as effectively as possible, with the help of practices like value-stream mapping. Measurements such as lead time, cycle time, and flow efficiency are helpful metrics to help you track your throughput. In order to achieve flow (principle #3), you can start by trying to eliminate different types of waste in your team.
A cumulative flow diagram (CFD) along with practices such as having WIP limits, do a good job of identifying bottlenecks in your workflow so that you can spot and eliminate such wastes, in order to have a Kaizen mentality and incrementally improve (principle #5).
The approach above is what most delivery teams focus on – being efficient. Efficiently closing lots of tickets or creating different systems or refactoring databases. However, you can efficiently do the wrong things. During our chat, Mary Poppendieck used a simple analogy of T-Mobile (telecom service provider) asking her questions to understand the root of the problem, rather than the symptoms that she was experiencing.
Let’s take an example of an IT team that received 100 tickets. 10 of the tickets reported a symptom similar to “invalid credentials for software X”. 25 other tickets had symptoms similar to “software X is currently down”. You do your tests on software X and find out that it’s running perfectly. During remote sessions with some users, you ask them to take you through step by step, ask probing qualitative and behavioral questions, and realize that users don’t have a UI to switch between work and personal email accounts and the personal account is always defaulted. Other root cause analysis (RCA) methods such as Ishikawa Fishbone diagrams can also be used. So the solution could be adjusting the UI to give you an option to switch between accounts. Using something like a thematic map here, is also useful in clustering the symptoms, along with their root causes, so that you can differentiate between the two. You can also use such a map/cluster to prioritize which problems or root causes to focus on first. Then solve all tickets with identified symptoms by taking care of this one root cause, rather than treating each ticket (symptom) as its own problem.
This is where adopting a more strategic product mindset can help you in being effective as a delivery team. Once you’ve identified the right problems, ensured that they align with your team’s mission, and have validated them, then you can move on to solving them efficiently with the aforementioned lean methods. This way of working is also another representation of the outcomes over outputs movement.
The role of an Agile coach, when working with supporting and enabling teams such as IT support, is not only about helping in various delivery aspects of teams, such as identifying and eliminating waste, helping create an explicit value stream, establishing pull-supported flow, and continuously improving, but also ensuring that teams are devoting time to first discover user issues and solve the root cause, so that they can also be effective at delivering outcomes efficiently.