Dev Team Performance: Team Composition

The last two articles focused on Scrum team performance as a whole and rudimentary skills for dev team performance, the first of three requirements of a development team to help it achieve high performance.

To review, those three things include…

• Rudimentary development skills
• Cross-functional team composition
• Excellent communication skills

Let’s look at the second of these three requirements.

Cross-Functional Team Composition Needed

What’s the big deal with cross-functional teams and why do agilists keep talking about it? The answer may not be obvious unless you’ve witnessed some of the things that tend to break or, rather, things which operate in a sub-standard way, in organizations that are primarily functionally based.

What’s a Functional Organization?

Henry Ford found great success in creating “functional experts” who did one thing well, over and over and over again. The guy who added the rear suspension to each car chassis always added the rear suspension to each car chassis. The guy who dropped in and bolted the engine always dropped in and bolted the engine. Ad nauseum.

Completely aside from the fact that humans are not especially happy when treated as automatons – we humans need appropriate challenges in order to be happy – what do you suppose happened when one of Ford’s functional experts wasn’t available or ran into problems?

The entire auto production line stopped and the “car queue” backed up.

Well, the same thing happens in software production, and in all other forms of production, when using functional teams.

The diagram above shows traditional functional teams on the left hand side and cross-functional teams on the right hand side. We’ll use this diagram to demonstrate a point about performance bottlenecks. Note: When you see this type of diagram it should remind you that cross-functional teams in an agile environment are capable of delivering…

• …more value to a customer
• …over a shorter period of time
• …for the same dollars invested.

Using Functional Teams

Still referring to the above diagram… In a traditional software development project one or more individuals from each of the columns on the left side are required to plan and execute the project; that is, some developers (DEV), one or more software testers (QA), one or more business analysts (BA) and possibly a user interface (UI) expert or two. Remember, this is a simple example. Here’s a set of steps that show what happens when problems arise in the project or when scope changes are introduced…

1. BA from the BA Team schedules a time to speak with DEV(s) from the DEV team about some changes
2. DEVs meet with BA and discover that QA and UI persons, from the QA and UI teams, respectively, will also need to be involved; and if the proposed changes have broader impact a subject matter expert may need to be pulled in as well
3. Another meeting is scheduled, this time with all necessary persons from each of the functional teams
4. The changes are discussed and individuals determine what each will have to do in order to accommodate each change. Those changes are communicated to the project manager who, in turn, seeks approvals from upper management and/or stakeholders for necessary changes. This may involve budget discussions, negotiations centered on what to remove, impacts to other portions of the project and/or to key stakeholders; change management conversations, etc.
5. Changes required of each of the teams are then coordinated; essential work is scheduled so that the person(s) from each of the (downstream) affected teams know when to expect work to come into their respective inboxes

Whew! That’s a lot of activity! Why is that? It’s because traditional development methodologies – almost all of which rely on a form of waterfall progression – rely upon the ideal of a mythical “perfect project,” which essentially insists that…

1. We know what to do (to create the needed project)
2. We find the funds to do the work
3. We hire an excellent project manager (PM) to run the project
4. We provide the PM with people from the various functional teams to do the work
5. Those people do the work
6. We test the resulting work
7. We deliver the work to a grateful customer

In reality, this describes a nearly “perfect accident” since we human beings typically…

• …cannot know what to do (what to produce)
• …in exact (enough) terms
• …to deliver the full scope of a project
• …wherein the result will still be germane; will still contain the wished-for impact
• …at the time of delivery

…be that 6 months or 6 years from the project’s outset.

This is because…

• Change is the norm in life, not the exception; and
• We humans cannot tell one another what is a “best option” in any situation until we’re able to SEE AND UNDERSTAND what the options are

Just one change to a system can lead to alternative future changes. For these reasons, our failures or “accidents” begin to occur in Step 1, above.

Using Cross-Functional Teams

In an agile “project” (we usually use the term “product”) the individuals from one single team on the right hand side (of the diagram) are required. This team is, in fact, the Scrum team’s development team. Here are a set of steps that show what happens when problems arise in the product or when scope changes are introduced…

1. Product owner alerts the Scrum team that new priorities will take precedence for the next sprint. Development Team and Product Owner work together to make ready the story(ies) included in the new work during product backlog refinement meetings.
2. Sprint planning occurs at the beginning of the new sprint, as usual
3. Development Team members collaborate on ways to get the necessary work done, meeting when and as needed
4. Daily standups reinforce progress on individual contributions plus alert all to potential impediments
5. Potentially releasable product is made available as decided at the end of the sprint

No muss, no fuss. In cross-functional teams we tend to work together every day to achieve our common goals. There are no conceptual walls that serve to separate the team members from one another. As a result, development teams are able to produce much more value for the customer over the same time span, given that the product owner chooses each sprint goal wisely.

What’s Next?

We’ve covered rudimentary skills and cross-functional team composition. Next we’ll discuss dev team communication and its value in helping dev teams perform to their greatest potential.