Agile Release Trains (ARTs) are effective in solving issues and dependencies between teams. When following the Scaled Agile Framework (SAFe) the teams that are working on the same product or service are ideally put into the same Agile Release Train (ART), which is essentially a team-of-teams construct. ARTs are efficient in managing the dependencies inside ART, which eliminates the dependency-related delays from the development. This way it is an important organizational design decision in which teams are put on the same train. This paper provides a new technique called CITSO (Customers, Inputs, Teams, Systems, Outputs) to map the dependencies inside and within value streams based on the Lean thinking SIPOC model. This mapping technique is an alternative for Value Streams and ART identification. CITSO helps optimize the organization of the ARTs by understanding the major dependencies between teams, processes, inputs, and outputs.
1. INTRODUCTION
Scaled Agile Framework (SAFe) combines the power of agile teams and lean value stream thinking to boost time-to-market, quality, motivation, and productivity in organizations. In any Lean transformation, the first step is to identify the end-to-end value stream. A value stream is a construct that contains the processes, steps, people, and tools that are needed to deliver value to customers from order to delivery (customer value stream) or from concept to cash (in development value stream). In SAFe, value stream mapping is an essential tool for speeding up development. Agile Release Trains (ARTs) are teams-of-teams constructs used in SAFe to boost cooperation between people who work on the same development value stream.
The SAFe value stream mapping event starts by identifying the operational value stream which the customer uses to generate value and then the development value stream that supports this operational value stream. In real life, however, there may be several value streams that utilize the same teams, systems, and processes.
Software architecture defines how the different software modules are related. If you have feature teams they may touch the whole code base, but they may not be competent enough to do so – especially if there is a lot of legacy code. You may also have strong links to underlying hardware interfaces and the hardware drivers may have requirements for the upper-level software. Embedded systems may have response time-related strong requirements as well as security constraints.
In a traditional setting where component teams each touch just one module, the knowledge of each component is within that team. But how do you visualize the situation where teams gradually move to feature teams and start to work on different functional areas? The dependencies between the teams slow down the development. But how would we be able to visualize the dependencies between teams, the components that they develop, and the architecture?
Lean thinking provides another method for process visualization called SIPOC that can be used on a higher level than value stream mapping for a more holistic process picture. SIPOC stands for Suppliers, Inputs, Processes, Outputs, and Customers. I have developed a variant of SIPOC, CITSO, that can be used in software development organizations to map the complex relations between teams, processes, and inputs. I have used CITSO to get buy-in from the organization to change the structures when consulting with SAFe-transformations. The typical outputs of CITSO workshops are also suggestions for software architecture improvements and additional understanding of how the development could be speeded up.
2. Background
During the years 2006-2009, I worked at the Nokia smartphone organization S60 SW as the main agile transformation leader. I was in a lucky position of being able to invite Dean Leffingwell and Mary and Tom Poppendieck to help us amongst many other agile gurus at the time. Dean Leffingwell helped us start our first Agile Release Train, that we called “the Leffingwell model.” Nokia S60 SW and Nokia Mobile Phones were amongst the five first pilot organizations and the biggest at the time. A lot of the SAFe framework is based on how Nokia S60 SW and Nokia Mobile Phones were working at the time.
Mary Poppendieck held a workshop on Lean software development, where we learned about value stream mapping and analysis. The first value stream map that we drew was of the error correction process. By showing the value of faster processes we were able to get permission to invest in a Continuous Integration system. Soon we started to map also other processes but found it hard to visualize different interactions and delays in a single value stream map. Thus, we had the idea of trying to use Lean SIPOC mapping for that. SIPOC is used to describe the process on a high level – i.e., what happens. Value streams describe the process steps on a detailed level, i.e., how it happens. We found it too laborious to describe all value streams in detail, so we started to look for alternative ways.
3. LEAN SIPOC Model
SIPOC is a widely used method in Lean and Six Sigma to understand and describe processes. It was first developed by Peter Scholtes as an elaboration on Dr. Deming’s systems diagram [1]. SIPOC stands for Suppliers, Inputs, Processes, Outputs, and Customers. An example of a SIPOC process description from a Dental care service can be found in Figure 1.
Figure 1. SIPOC of a dental care service
It is possible, but not necessary, to draw lines between related lines at the SIPOC table. There is also a variant of SIPOC where the customers are put far left as an originator rather than the receiver of the outputs, namely CIPOS (Customers, Inputs, Processes, Outputs, Suppliers).
Value streams can be categorized into operational value streams and development value streams. Users use the operational value stream to get the service by using the system. In Figure 1, SIPOC is used for mapping the operational value stream of a dental care service. The service itself is supported by an IT system, where the appointments are made, the customer gets invoiced, and new supplies are ordered. All these IT systems, people developing those systems and services, and the tools needed for the development value streams of this organization providing dental care solutions.
This Dental care service development stream could also be mapped out using SIPOC, but with some modifications, we could get a better understanding of how the systems are being built. When developing software solutions, it is important to understand what modules or systems these solutions consist of, as with a good modular architecture, we can reduce the overall complexity of the development. It is also vital to understand which teams are working on which modules.
4. Understanding how Teams and Systems are Related
When we wanted to understand more deeply the value streams of Nokia S60 smartphones, we soon encountered the problem that a single value stream map could not describe how the different components were related to software teams and the architecture. We had learned from Bas Vodde that Feature teams were good and component teams were bad, but the huge size of the organization and a large amount of legacy code prevented us from simply jumping into that structure.
4.1 Feature teams work with multiple systems
We wanted to follow the principle that all teams are allowed to touch all systems or modules. What we learned was that shared code ownership is practical and favorable when the solution is small and there are only a few teams that can share the knowledge of the entire solution architecture. As the solutions grow, it is not just non-practical but also dangerous to allow teams that do not know what the system or module was designed for to make modifications uncontrollably.
Shared code ownership should be encouraged, but the quality should be controlled. There are multiple ways to ensure good quality with shared ownership: pair coding with an expert on the area, dividing responsibility areas of teams, architect team support, knowledge test of the module before you can make modifications, or comprehensive testing of the system are some of those. Because of this knowledge-intensive nature of software development in the past, the typical organization structure has favored component teams, i.e., a team is specific to a component or system that it develops. Yet this structure is not providing an optimal speed for development and will often lead to teams working as isolated silos. That is why in Agile, we often favor feature teams, although building competence to work on multiple areas will take time.
4.2 CITSO
Developing different systems may require specific knowledge of those systems. In real life, the mapping between teams and systems may be complicated. If each team would develop only one system, putting the product together would require a coordinated effort from all the teams. Teams could not finish a single functionality to the new product without interacting with all other teams whose work they would be dependable on. To understand these relations, we need to add TEAMS and SYSTEMS to SIPOC mapping. On the other hand, suppliers might not be important at all, since the software does not require specific components to be delivered (like hardware development), but the work is done with commercial tools, easily available to everyone. Figure 2 gives an example of Modified SIPOC, which can be used to map the work done in software development.
Figure 2. Modified SIPOC
Many agile methods emphasize that the work should be done per customer order or request. In these cases, it would make sense to start with the Customer. Many times Processes may not be needed, as the Process maybe just a generic software development process. Figure 3 shows another version of the Modified SIPOC, where the Customers are the starting point, and the Process step is omitted.
Figure 3. CITSO – Modified SIPOC for software work
We used CITSO to understand the relations between different functional areas, software architecture, and development teams.
We ended up in a solution with responsibility areas that we called Packages. Each area had a Package Owner, which was a group role responsible for the quality of that Package. The teams working on a specific area could directly do the modifications to their area like true Feature teams. They could also propose modifications to other areas, but they should then walk through these modifications with the Package Owner of that area before those were included in the build. This solution worked for us and helped us to scale the Feature team concept to a larger software base.
4.3 The risk of uncontrolled change to Feature teams without taking care of quality and architectural concerns
During my 20-year career in large-scale agile transformations, I have also seen numerous organizations that have just jumped into cross-functional Feature teams without cross-training teams or taking care of the architectural quality or interfaces first. In all those cases, there have been disasters as a result: the quality of the product or services has degenerated, and several valued developers have left the organization since it does not support their work. Taking care of a good work environment – which includes understanding how teams, architectural components or systems, releasing, and quality are interrelated – is a primary requirement for a long-lasting, successful large-scale agile transformation.
5. CITSO in Action
After I left Nokia in 2013, I co-founded Nitor Delta and started a career as a scaled agile consultant. Our mission was to help industries take scaled agile methods, especially Scaled Agile Framework (SAFe®), into use. As a consultant, one challenge that you face is how to tackle the change resistance within the organization toward this transformation.
The construct of a team of teams in SAFe is called Agile Release Train or ART. Even in larger groups, communication between this kind of larger group of people is better when the group size does not exceed Dunbar’s number. [2] This is why ARTs in SAFe are optimal between 5-12 teams, i.e. between 50-124 people. Larger organizations having more people should have more ARTs.
Lean thinking also suggests that these ARTs are optimal when supporting a single value stream. Often large development organizations can have multiple products or services thus having multiple value streams that are sometimes overlapping or intersecting each other.
I have used CITSO as a tool to make the organization see what we are doing and why we are doing that – i.e., to gain the buy-in for organizing as Agile Release Trains.
5.1 Case 1: Single development stream supporting multiple operational value streams
One of my customers wanted to start the SAFe transformation. They were a software (Information Technology) company working in Telecom-area and had multiple software products developed from the same code base. I was coaching just one of the Agile Release Trains (ARTs) in this organization. Here, I used CITSO to map the relations within the organization, see Figure 4.
Figure 4. CITSO showing relations within a single ART
This organization had in the past managed the different efforts just by setting deadlines for deliveries, not paying attention to how complex the development was or if the teams had different priorities. If teams do prioritize the work for different services differently, all new services would be delayed because all services would wait for some new functionality from other teams to be completed. Here, a generic prioritization would help sequence the development effort so that one service would be upgraded at a time.
Using CITSO with the Product Management of that organization helped them to see how their work was all interdependent and how they could benefit from working together, rather than separately. It also helped them to understand how they could do several architectural improvements to enable faster deliveries. They also grouped some of the service products.
An interdependent group also needs a Kanban board that supports their collaboration. Thus we built a Kanban to manage the flow across all different systems, see Figure 5.
This helped the organization agree on the higher-level priorities and see the impact of their decisions on dependencies and delivery cycle times. The team gathered around this Kanban to see the status and make decisions together at frequent intervals. Without the joint understanding, such collaboration would not be possible, but everybody would have been driven by their deadlines and goals.
Figure 5. Multiple value streams and dependencies managed by a single Kanban
Figure 6. CITSO was used to understand different teams and their relations
5.2 Case 2: Small development value stream
In this case, my client was a small medical area software service provider. They had just a small number of teams and systems to develop. In this case, SAFe® provides an easy answer simply to put everyone on the same train. However, I wanted to use CITSO to create an understanding of how the teams work together. An anonymized result is shown in Figure 6.
In this case, the customer got several insights on how to work on their architecture to get a more seamless flow in the future.
5.3 Case 3: Large software development organization supporting physical systems
In this case, my client was a large equipment provider in the mining industry. They had done SAFe® transformation earlier, but the client organization did not see the value of organizing as Agile Release Trains. I was using CITSO with their agile coaches, and transformation led to doing the mapping between the systems, teams, and architecture. Again, some architectural improvements were identified to gain speed of deliveries in the development organization. The agile coaches decided to run several CITSO sessions within the organization in the next coming weeks to create more understanding of what the best way is to organize into ARTs and to gain more buy-in for the transformation.
6. Transformation without CITSO
SAFe® guides organizations to identify first the operational value streams and then to identify the systems and people who develop those systems. You then identify the Agile Release Trains so that those Agile Release Trains support the development value streams. In many cases, the ARTs start first as virtual organizations. Later then, the organization is changed to support the ART structure.
In many cases, the ARTs also start from component teams – i.e., there has been a single team or multiple teams developing one system. A system may also be a bottleneck for multiple ARTs. Many times organizations start the transformation with the existing structure and then gradually work their way to create fewer dependencies between ARTs and between teams within the ARTs.
6.1 Case 4: Tackling change resistance in an already ongoing train
I was called in to re-train SAFe for a group of people who had a hard time adjusting to their SAFe organization. It turned out that the group had rightful concerns about the competencies of the teams, the quality of the product, and the set-up for the transformation. I ended up explaining during the class how I saw they could get the most out of the new set-up and explained CITSO on a flipchart. The class was a success, but I got a comment that “the other consultants do not explain this way.”
7. Facilitation
Like any value-mapping activity, it is important to have enough and the right people to do the mapping. It is very unlikely that any single person alone knows all that is happening in a single value stream. Typically, people know only the part that they are working day-to-day in.
You would like to have a group of a maximum of 20-25 people so that the activity is easy to facilitate. Make sure the group has at least one software architect since they usually know how the systems work together (others may not necessarily know this).
Prepare the room with a wall of large paper or a whiteboard, where you can draw and lay out sticky notes. I usually start putting the headings first (like People, Inputs) on large sticky notes and then start to ask questions and produce more sticky notes. I encourage people to participate by stating that there is no single correct answer and if things go wrong, we can always write another sticky note that is better. I have found out that the outputs are easiest to start with – usually, people know well what they are producing to their customers. The next items are the customers and inputs. It helps to ask in which format customers make their requests and to give practical examples of recent requests they have received.
Once you have most of the sticky notes on the wall it is time to draw the relations. I usually use erasable markers for this one, as it often needs correction. You may also want to use arrows to show the direction of the relationship. Sometimes also, circular relations or two-way relations may occur. These usually trigger a lot of discussions.
When facilitating, I try to stay out of the discussions when those start to arise. Only if heavy argumentation starts to happen, I try to stop that and facilitate the parties towards an agreement. A typical case is that people are not happy with the current status quo. That is why we usually end up doing the CITSO twice – first for the current state and the next one (after a short break) for the desired future state. Usually, drawing future state maps results in lots of agreed architecture improvements. Sometimes the result is also decided to change the value streams (i.e., restructure the value streams, like in our Case 1) or change the teams’ structures.
8. Feedback and Future Work
As an agile process coach, it is important to find techniques that engage people but also help them to see how to develop further their work environments. CITSO has turned out for me to be that kind of technique.
I have tried it out in tens of customer cases in many different types of organizations and taught it to many people, and it seems to work regardless of what type of development is done or how the systems, architectures, and team structures are defined. The only cases when I have failed with it have been such that the group has had no power to change the existing organizational structures, work division between teams, or work on the architecture and have felt powerless when exposed to the complexity of their situation. Luckily this has not happened to me too many times – and in these cases, the organization has promised to fix the exposed problems when they have the next opportunity to do so.
Often the relations may become too numerous, and the picture becomes too messy. In these cases, I have asked to draw only the major dependencies.
The main benefit of CITSO is that it is used for building an understanding that will result in organizational and architectural improvements. Drawing CITSO multiple times will help organizations to do a series of improvements, that often improve cycle times.
I recommend trying to map different situations and organizations with it and approaching it with curiosity.
9. Acknowledgments
I would like to express my gratitude towards the leaders who saw the benefits of investing in processes at Nokia, who allowed us to research scaled agile methods and do the transformation within the organization. I would especially like to thank Tomi Tarvainen, who came up with the idea of Package Owners, and my fellow agile coaches Vasco Duarte and others.
I would also like to thank Mary and Tom Poppendieck, Bas Vodde, Dean Leffingwell, and other agile champions who have helped develop these methods further.
Writing this paper has not been an easy task. I found that the CITSO story did not easily fit into the research paper format and decided to write an experience paper instead. I would like to thank my shepherd Steve Adolph for his time and advice.
References
[1] Scholtes, Peter. The leaders’ handbook. McGraw-Hill, 2018.
[2] Hayes, William, et al. Scaling agile methods for the Department of Defense programs. CARNEGIE-MELLON UNIV PITTSBURGH PA PITTSBURGH United States, 2016.
