Developing a Cross Functional Team

Agile methodologies often talk about developing a cross functional team but not much is said about how to do it.  In training classes, it is often said that on an agile team, “your role defines how you best contribute to the team, not how you will contribute.”  The project and the challenges the team is facing will determine what work actually needs to be performed to keep the project on track and make sure that the team builds trust by making and meeting commitments.

I am a proponent of looking at other industries to see what they do to enable a flexible workforce to deal with variable demand and see how it can be applied in development.

At stores like Wal-Mart or Target, they cross train a large portion of the work floor staff to be able to run the cash registers if they need to open additional registers based on queue lengths.  They use season trend models to determine how many of each worker type to schedule, but the cross-training allows them to account for the uneven flow of customers that can occur without degrading the overall customer experience.  It does mean that something that is less time critical like restocking shelves is subverted in the process for the more time critical process of completing the checkout and payment process.  It doesn’t mean that restocking shelves is not important, but more that a bottleneck is currently occurring at the check-out lines and therefore the store team chooses to reduce the effort temporarily in other areas to help resolve the bottleneck.  Once the flow issue is resolved (too long of lines in this case) the workers return to their original and primary job function.

In manufacturing, the cost of a bottleneck is even more pronounced.  Since most manufacturing follows a Lean model where inventories are reduced or eliminated, a bottleneck in the process can end up shutting down the entire production line after a relatively short delay within the system.  For this reason, they develop what are called “T resources” in terms of skill sets.  A “T resource” has one area of specific, deep expertise but is cross trained in the job functions for the stations immediately prior and immediately after them in the production line.  While they are not as skilled in those functions, they are capable to complete them at the required levels of quality.  The deficiency is more in speed to perform the task.  This enables a bottleneck in the system to get temporary assistance from other areas in the production line to ensure that the whole line doesn’t grind to a halt.

t resource

Stores and manufacturing are one thing where much of the work is manual in nature, but is it possible to create “T resources” on a team of knowledge workers where highly specialized skill sets are often needed?

The answer is the standard, “it depends…”

At Cerner the product owner roles tend to be trained clinicians or have deep business knowledge in a specialized area like Finance or Hospital Operations.  In some cases the testing experts are also clinical professionals which enables them to effectively understand and test the various workflows.  While developers and architects can learn their clinical domains, it would not be at the depth of the trained clinicians.  The reverse is also true.  Clinicians or testers can learn to code.  In all of these cases however, just because we can doesn’t mean we should.

I would like to propose a couple of options for teams to develop “T resources” when faced with the challenges like those that Cerner’s model presents.

The first is to model the process flow or value stream and identify how work flows through the system similar to a manufacturing line.  Once the value stream is defined, the team can identify where each member is an expert and the areas where they can develop some cross training to help if bottlenecks arise.  It may end up not being the process area immediately preceding or succeeding like is done in manufacturing.  Once the areas are identified, developing that cross functional expertise then becomes a priority to ensure consistent flow in the system.

Parameters should be set as to what portions of the specialist role cross trained members can perform.  For example, can a testing expert or architect help create functional requirements that are typically the domain of the requirements specialist?  Are there limits to what requirements they can help with?

Utilizing techniques like pairing the associate to be cross trained with an expert will enable the quality expectations (aka definition of done for the Kanban column) to be consistently met while training the associate new to the task.  This also creates an individual learning environment that web based training (WBTs) can never match when it comes to individual competence.

One word of caution here is that if an upstream specialist is unable to help with the area where the bottleneck is occurring, they should never exceed their work in process (WIP) limits to start on something else as that will merely increase the pressure on the bottleneck and detrimentally impact the overall speed of the flow through the system.  They need to find something else to do that contributes value to the team without increasing the work in the system.

The second is to look at the development stack for the team and understand where the team has created specialists within the same role.  A team or set of teams may have UI experts fluent in a specific language while the services stack or database tier will likely leverage different technologies.  The team can then to identify where development specialists can cross over the layers in the stack. Much of the variability in software is that each project will require a different architectural solution.  In some cases, the project may have heavy UI and limited services while other projects may exclusively require services work.  If we are to keep the team together that will enable the greatest team productivity, cross training will be needed across the layers in the architectural stack.  There will be limits to the depth each developer has in each area and we want the deep experts to typically work in their area of expertise, but due to the variability in the project work, that will not always be possible.

Understand that while cross training will help individuals contribute in areas outside of their own expertise they will not be as productive (speed wise) as the deep expert. A good rule of thumb is to plan for a 50% difference between the expert and the cross-trained associate.

Because of this difference in productivity, the temptation is to form teams around the different layers in the stack.  When this occurs, it prevents the development in thin vertical slices.  This leads to disconnected prioritization and multiple stories to accomplish the true user story.

release timeframe legend release timeframe

The outcome is increased waiting time in the overall process resulting in delayed or incomplete deliveries.

The other temptation is to form teams for each project based on the needs of the project.  This will actually cause even slower development cycles than the layered model as the team will have to go through the storming, forming, norming, performing sequence and actually have lower productivity than a standard waterfall model for several iterations.  This is sometime referred to as the “J-Curve” when introducing change.

j curve

It will usually take 6-12 weeks for an Agile team to become equal to a waterfall team in productivity.  They will quickly outperform the waterfall team after that point, but if they are broken up again, they have to start all over again.  To achieve hyper productivity, a team has to stay together for a sustained period of time so they learn how to work together and understand each individual’s specific talents.  Only then can the team consistently and effectively self-organize to address the projects the business requires.

To understand how to potentially tackle this situation, Spotify can be used as a case study that you can read about here. The creation of guilds in particular allows for architectural excellence at each layer in the stack without sacrificing a team that can work in thin, vertical slices.

spotify teams

So, why this push for “T resources” in software development?  If an associate is really good at what they do in a specific area, why would I ever want them to stop doing it so they can work on something where they are not as skilled?

From a Lean perspective, all work that is being done but has not been delivered is waste. The client cannot use it until it is fully delivered, so we want to reduce the time that the development is in a wasteful state.  Think of this as you can’t buy half a car at the dealership, so until the car is fully built, it is waste.  Manufacturing companies count these unfinished goods or WIP as a liability on the balance sheet, thus negatively impacting their profitability.  This means that a Lean organization focuses on how quickly things flow through the system and seek to resolve areas where flow gets interrupted as quickly as possible.

This is a challenging concept for any specialist as they want to spend their time focused exclusively in their area of expertise.  What they are really good at will eventually be needed, so shouldn’t they just keep doing it?

The answer is a resounding “No!”  This would be equivalent to trying to add another car on an already congested road.  It will just slow everyone down that much more.  Pretty soon the entire road will grind to a halt. We will start seeing road rage within our process and from the clients.

The other impact will be the potential depreciation factor that can set in on the WIP which can result in unnecessary rework prior to client delivery.  This is why push models fail to meet the same client satisfaction of a pull model system.

The reality of software development is that the client and the team are often better served that if the specialist stops doing what they do best and work elsewhere to help the team deliver when flow problems occur.  If you want to travel at freeway speeds in delivering, you have to abide by freeway principles.  To quote Scotty from Star Trek,  “you cannot change the laws of physics…”

Author: Matt Anderson

Matt Anderson is a Director at Cerner Corporation. A 20+ year IT veteran with a background in development, architecture and project management, Matt has led Cerner’s Enterprise Agile Transformation since its beginnings in late 2008.

Leave a Reply

Your email address will not be published. Required fields are marked *