Guiding Teams in Multi-Skill Development

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 2 Massive 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 3 Example 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.6 Three 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