The seventh blog, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

Individual and Team Performance

A Scrum Team is multidisciplinary and contains a whole arsenal of skills and competencies to deliver value to users. The workload on a single specialty is mostly uneven in a complex environment and therefore such teams are very susceptible to bottlenecks. Peak loads on a specific specialty may vary from iteration to iteration. For example, in Iteration N, the team may have a peak workload in the business analysis skill, in Sprint N + 1, it might be testing.

The theory of constraints implies that the system’s performance is going to be limited by the bottleneck. If there is no change to the bottleneck, the system will not improve. When the bottleneck is influenced, the system changes (McKey, Zoe. Think in Systems: The Art of Strategic Planning, Effective Problem Solving)

Note that a bottleneck determines a system’s throughput, and that spending time optimizing non-bottlenecks will not provide significant benefits. Figure 1 shows what a typical team board could look like at the end of the iteration if everyone is equipped with an individual performance strategy.

Figure 1 Visualizing bottleneck in a flow

As you can see, the bottleneck at that moment is in testing because the largest queue is right before it. If such a picture is repeated consistently in a team, then testing is considered a system bottleneck. When the rest of the team continues doing more Analysis and Coding tasks, this will overload the bottleneck even more. This is pointless (a suboptimization) if we want to optimize the system performance.

In other words, team members can be productive on their isolated expertise at the expense of the team performance.Therefore, using the strategy of maximizing individual skill utilization in teams is not optimal in a team context. Instead, create a team where its members can work on multiple kinds of tasks; A team of multi-skilled individuals.

What can you do to help the teams?

Below are some guidelines that worked for us:

1. Visualize Flow of Work

Visualization is critical for any Agile organizations as it unfolds the queues and helps to optimize the flow of work. In service organizations in contrast to assembly lines, inventory is invisible. It is stored on hardware disks and walking along the office doesn’t give you an overview of how much waste is really being created.

Figure 2Massive Work-In-Progress (WIP)

If we could do just one single thing when coaching a team, we would visualize the flow of the work. As an example, see Figure 2. By visualizing the flow of work one can see the bottlenecks and create awareness.

2. Introduce a StarMap

A starmap is a simple competency matrix that visualizes the cross-functionality of the specific team. It reveals gaps in knowledge, uncovers potential bottlenecks. The rows of the table are just a list of team members, the columns contain the competencies and skills needed to deliver value (see Figure 3).

Figure 3Example StarMap

Ideally, we would like to see two or more stars in each column. Because then the team becomes truly flexible and can fight the peak loads. The combination of the start and the dot is a good one too. If we find columns with no stars, this is a wake-up call. The team needs coaching and assistance; otherwise, they might have quality problems for work in this competence. But the most problematic columns, in which there are no designations (except for books), indicate dependence on external expertise. Dependencies rob the team of autonomy and prevent the delivery of value. Dependencies block work and significantly increase Lead Time and, as a result, reduce organizational flexibility. In our book we introduce a workshop to initialize the StarMap as well as other tips on how to work with this tool.

3. Use Three Modes of Development

We are convinced that there is no better way to strengthen cross-functionality and simultaneously reduce work-in-progress (WIP) in an Agile team, than by continually working in one of three modes as illustrated in Figure 4 and described in the list that follows.

Figure 1.6Three modes of development.

• Pair programming: Working on one or more features in parallel in pairs.
• Swarming: Working on one feature at a time (WIP = 1), not structured, teams self-organize their work. They could work in several pairs or triads or any other way.
• Mob programming: Working serially on one feature, a technique that has been gaining momentum in recent years. The team is working on one feature at a time using one computer and a large screen / projector.

Mobbing is a single-piece flow activity, and from a flow efficiency perspective the most efficient way to develop, if a team can reduce transaction costs to the point where it becomes economically feasible to work on one feature from start to Done state.

Working in three modes has many advantages. We list just some of them:

• It is one of the best ways to enable multi-functional learning in a team.
• No or little extra code review needed.
• Trust increases, the team is forced to learn to negotiate and listen to different points of view, to come to a consensus.
• No transfers or losses of information.
• Collective code ownership.
• High quality decisions, everyone knows what is going on.
• Perfect flow, the team works in one feature at a time —one-piece flow (WIP = 1).

The three modes are so counterintuitive that it takes a lot of patience and training to start. To ensure that your approach to the three modes is successful, we have several guidelines in the book.

4. Introduce Slack Time

Full utilization does not lead to better system performance. Under full utilization, there is no room to absorb variation in work. Let’s say an urgent bug comes into a Sprint; If a team is operating at full capacity they have no capacity left to handle that bug. Under pressure, the team might neglect writing tests, avoid refactoring or create any other form of technical debt in order to complete work on time.

Therefore, we recommend using Slack Time practice described in eXtreme Programming. It is a time buffer that a team explicitly associates in an iteration for unexpected work and multi-functional learning.

A slack task is:

• a valuable task that helps the team work more effectively
• and a task that can be instantly postponed for an iteration without doing lasting damage.

Slack Time has many forms and could be used for:

• Book clubs
• Self-directed discovery and exploration time
• Adding tests to legacy code
• Paying off technical debt
• Architectural redesign
• Participating in Communities of Practice (CoP)

Summary

The work of solving a complex problem (for example, a feature) with interdependent tasks rarely distributes evenly among the people in a cross-functional team. The solution is a team of multi-skilled specialists. A team of multi-talented people experience fewer bottlenecks as they can help overloaded team members, and therefore reduce the time to solve a complex problem end-to-end. The team develops multi-skilled members by working in three preferred modes: pairing, mob-programming, and swarming continuously. Some other techniques are: StarMap, visualizing the flow of work, and Slack Time. 

In our next two blog posts, we give an overview of:

• Transitioning to the Product Owner at scale
• Emergent Framework—coaching approach

Second blog, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

Many problems at the workplace are not the fault of the individual managers or teams. They are often the result of working in an organizational design(OD) that impedes rather than supports Agility. The OD determines, to a large extent, how people cooperate, the prevailing mental models, and how work gets done. To change all of this takes time and requires people to unlearn old lessons and relearn new ones that support Agility. 

An organization redesign includes re-thinking:

• Structure: Which organizational units such as departments, groups and teams are required? How are work and responsibility divided among those units? 
• Processes and Integration: How do the units and roles relate to each other and collaborate?
• People: What team and employee skills and capabilities are needed?  

Working in a new design helps the people learn what is needed to build the new capabilities.

Some examples of how design decisions can facilitate the development of capabilities are:

• For fast adaptation to customer insights, consider creating a short feedback delivery process that allows fast learning about the customer. Allow decision making by people who work closely with the customers.
• For teams to take ownership of delivering customer value, consider designing autonomous teams that include all the necessary skills to finish their work independently of other groups.
• For efficient product development flow, consider designing a reward system and career path that values people for developing multiple skills. Multi-skilled specialists reduce the bottlenecks in the delivery process.

Figure 1.1 shows that executing a business strategy requires specific capabilities, and these capabilities can be developed working in the appropriate OD.

Figure 1.1 From business strategy to organization design. ( Figure copied from Creating Agile Organizations – A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)

Contain Reciprocal Dependencies with the Product Group

James D. Thompson wrote that we should design the work by the intensity of interdependence and then introduce specific coordination techniques for each. 

There are three types of interdependence:

Pooled. Units are doing the same task in parallel or have a shared resource. Sales people often have pooled interdependence if they sell individually and combine their monthly sales numbers to get the overall result.

Sequential. Units rely on each other in predictable ways for the flow of information, work and decisions. In sequential interdependence, each unit completes its task before another in the sequence completes theirs. Classic example is an assembly line. A product must be fully assembled before it is wrapped, and wrapped before it is shipped. 

Reciprocal. Units are sequentially interdependent. In addition, they work back and forth and must adjust to each others’ actions as the situation changes unpredictably. 

The reciprocal interdependence resembles the dependencies between software development teams that work on a single product. These teams either have a mutual functional dependency—when a feature is divided into independent technical parts to be developed by different teams—or a mutual technical dependency when each team picks up a complete feature but works in the same software components and creates technical dependencies.

For reciprocal interdependence, it is recommended to manage the dependencies through constant information sharing and mutual adjustments. Figure 1.2 shows these three types of interdpendencies.

Figure 1.2 Three types of interdependencies. 

A study about the implications of these types of dependencies was published in the paper Quantifying coordination work as a function of the task uncertainty and interdependence by Ronald E. Giachetti et al. They concluded—as shown in the figure above— that

First, “…the experiments find no significant difference between pooled and sequential interdependence and the resulting coordination load…“. 

And second, “…coordination load increases significantly when interdependence changes from sequential to reciprocal…“. 

Working with reciprocal interdependencies takes twice as much time to coordinate compared to work with the other types of dependencies.

Figure 1.3 Coordination load as a function of interdependence and analysability (Adapted from Ronald E. Giachetti et al)

The key idea is to first design the organization to minimize reciprocal interdependencies between units that produce value. When you group the necessary functions and skills to produce value, coordination becomes easier, flow increases, and rework decreases. It also facilitates team accountability for a complete work item instead of just a part. The teams can now become autonomous and can manage their work. The organization can stop giving work packages to a team to execute and instead provide customer problems for a team to solve.

Redesign into a Product Group

In the book, The Toyota Way11, pp 304, Jeffrey Liker, Professor of Industrial and Operations Engineering at the University of Michigan, recommends organizing around product families. Each product family has a senior manager responsible for the product family and controls all the resources needed, including maintenance, engineering, and quality. Such can go fast because it contains all work dependencies, but it can also quickly relocate resources to areas of highest demand. An Agile organization benefits from the same capabilities and might use a product group that is defined by:

• Its purpose or function within the organization
• The organization elements required to achieve its purpose or function such as cross-functional teams, shared functions, systems, roles, accountabilities and responsibilities
• The senior manager that leads the product group. It is a person with a deep understanding of the product and process.
• A market-focus and/or profit & loss responsibility
• Product decision-making autonomy

Avoid Designing the Product Group from the Inside Out.

An inside-out design is based on an internal business process or the system architecture.

Let us provide two examples of design from the inside-out: 

• One of our customers develops a trading system, and the process of registration, trading, and billing consist of 23 process steps. How did they design their structure? They had 17 teams, and each team worked on one or two business process steps, even though a feature largely required multiple business process steps to deliver value to a customer.
• Another customer developed material analysis systems. The system architecture consisted of components like Motion Control, Data Extraction, Data Analysis, and many more. How did they structure themselves? They had one or more teams per architectural component, although 80% of customer features required changes in most components together. 

Such designs make it hard to adapt to customer value; instead, they concentrate locally, optimizing the individual teams’ performance. 

Prefer Designing the Product Group from the Outside In

To design the product group from the outside-in:

1. Start with the customer problems that need to be solved.
2. Study how solving those problems for your customer works in your organization.
3. Determine which organization elements such as units, processes, and people are needed to create customer value.
4. Combine them into a product group.

Our next blog discusses how you can define your product group. 

In this talk, Cesario shares some Agile Organization Design principles. You can use these principles to have a more informed discussion in your agile transformation.

See also the upcoming book Coaching Agile Organizations.