Dynamic Feature Teams: Creating Small Mobs Within a Large Group (Case Study)

This article describes a case when the team’s demand for expertise bumps up against the needs of the feature team to handle the complex “Big Rocks” in the portfolio. It is a case when cross-functional teams are simply not possible or feasible. Guided by Lean-Agile thinking, one solution is to use a dynamic feature team.

Introduction

Dynamic feature teams help in the situation where there is a tension between expertise required to develop a component and the backlog of work that involves multiple components. The dynamic feature team says that you can envision the whole set of developers as the large team and that individual teams are dynamically assigned to handle the Big Rocks where multiple components of having to interact in complex ways. Then smaller, one-component chunks of work can fit in around the Big Rocks.

There is certainly a cost when the smaller chunk is delayed but this is compensated by the benefit of completing the Big Rock. This is in line with the Value Stream Impedance Scorecard (VSI factor 4 and 7)

Listen to Al Shalloway reflect on this case study.

Background

In this case study, a software shop was responsible for maintaining the code for a military aircraft. The shop was composed of 50 developers and 25 testers, support, and PM resources.

They worked with embedded software for seven components including gun controls for several different types of guns, radar, and communications. In practice, teams were organized by component with 3-9 people per team.

It goes without saying that errors were not acceptable. A bug that caused an airplane to fall from the sky would be very bad indeed.

Challenge: Testing

Developers did their own testing. Being embedded, developers could write code on their local computers but could not effectively run the code on those computers. Integration testing could only be done on specialized testing platforms. Because of the expense, the number of testing platforms was very limited. The developers had to share four dedicated test platforms. Airplanes were generally not available during the day. Airplane simulators had to be shared with the pilots who were learning to fly the craft.

As a result, many times testing had to be done at night. This worked okay when there was only one component being tested at a time; however, when multiple components needed to be tested, they all needed to be tested together to reveal cascading effects on other components. Testing could stretch several weeks.

Clearly, integration testing was a major issue for the organization.

Challenge: Cannot employ cross-functional teams

The lack of testing platforms was only one problem. There was also a lack of component-based skills across the teams. It was not possible to create cross-functional teams because each team required very specialized skills.

Sending a highly specialized person to another team would mean the person would likely be idle until something requiring their expertise was required. In a large project covering multiple components, this could be upwards of 80% idle time in the project. They could not afford to send someone to another team.

Cross-functional teams were not going to work… at least not static cross-functional teams.

The approach

What we really want is to eliminate delays in hand-off and feedback and integration thrashing. So how could Lean Thinking make this better?

Management was reluctant to use Lean Thinking. They understood the value of flow but feared that they would have to slow down and the pressure to produce work that supported mission-critical aircraft was overwhelming. After long conversations with the coach, the director finally agreed even though it meant redefining teams.

They identified two classes of work in testing: those requiring only one component to be tested and those requiring multiple components to be tested; they called them the “Small Rocks” and the “Big Rocks.” Eventually, they developed the idea to schedule and prioritize the Big Rocks and swarm on them and then swarm on increasingly smaller rocks. Each swarm would be made up of the expertise required to finish that work. This is illustrated in Figure 1.

dynamic

Figure 1. Swarming makes Dynamic Feature Teams work

The big shift was that now they wrote code and tested it together.

We called such a swarm a ”Dynamic Feature Team.” A feature team that dynamically forms based on the needs of the work at hand. With today’s popularity of mob-programming, a better term might be “dynamic mobbing.”

They also defined a rule that if the team needed someone who was working alone on a little thing, they could pull that person into the Big Rock work and they would lay aside the Small Rock for the moment.

Results

This redesign effort required four days of coaching and four days of training and then leadership and the whole team knew the principles and figured out what to do.

They documented a significant return from this effort.

63% increase in throughput
42% decrease in defects
More than 22% savings in costs, over $1.73M

Coaching notes

Here are some notes for the coach.

As a coach, your job is not to tell people what to do but to prepare them and have them think for themselves about the primary and secondary order of consequences in taking action. Your job is to ask questions to guide their thinking using Lean Thinking principles (even if they don’t know they are using them).
As a coach, you have to think outside the usual box. In this case, it means thinking differently about what is a “team.” Together, the group of 50 understood the overall system of the aircraft and how components fit into that system. Even if individuals did not understand the details of a particular component, they understood the interfaces. Thus, you could envision this Group of 50 as a whole team that was dynamically allocated to the most important problem (increment) at the moment.
See Managing Large and Small MBIs for how a story by Steven Covey inspired Al to create this practice.