Don’t Get Screwed by Scrum: #1 – High Performing Teams

A method and its benefits are soon parted if fundamental drivers are not understood and accommodated.

Scrum has at its heart an engine some organizations struggle to establish and maintain: the high performing team. This is the first of 3 pieces on Scrum characteristics that are essential to embrace in order to successfully use the method.

For many years and in various ways it has been said that a mediocre team with an outstanding concept will produce a mediocre outcome, whereas an outstanding team with a mediocre concept will create an outstanding outcome. This is especially true for Scrum.

Companies adopting Scrum methods who short-change the importance of assembling high performing teams seldom realize the expected benefits, regardless where the method is used.

I’ve seen this play out in a number of ways:

• Expecting immediate results from teams that have no history of working together.
• Diminishing the Product Owner’s (PO) role by inserting checkpoints or committee reviews where a PO’s unilateral decision is needed to maintain cadence and velocity.
• Failing to staff the team with the proper functional roles.
• Assuming distributing high-performing resources on multiple projects yields greater throughput.

Performance Maturity Curve
(source unknown)

Creating a high performing team is not easy and usually not quick.

In addition to understanding what the team will be producing and how they will individually contribute, they must also figure out how to work together; a process that depends on developing a shared work history.

Here are some ways to avoid disappointment (or worse) when considering Scrum from this particular angle:

1. Realize that high performing teams are rarely formed on the first try. Building in buffers for re-alignment and re-assignment is prudent and smart.
2. Build and test new teams with small, fast, low risk projects. Gauging performance based on delivery is the best and lowest risk way to identify a high performing team. Ideally this should be done before attempting a large, high risk initiative.
3. Resist the temptation to divide high performers effort among multiple projects or across teams. This dilutes their effectiveness. Once high-performing team members are found, keep them focused on one initiative at a time.
4. Keep high-performing teams together. All things considered, it is better to reassign a proven team to a new project than to break the team up. Again, teams need working history to get up to speed so naturally a fully-formed existing team is more efficient and productive from the very start.
5. Remember that the Product Owner (PO) is a critical element of the team. The accuracy and speed at which the PO can articulate requirements, answer questions and make decisions has a direct effect on the performance of the team at large. Be deliberate and cautious in your selection and when defining the scope of the PO’s authority.
6. Align policies and structures to incubate self-forming teams. Over time resources will attempt on their own to self-form into teams. This is in keeping with the Agile philosophy and should be considered a good thing. But unless organizational structures or policies permit this type of behavior, conflicts and frustration will arise. If this is not addressed, the potential for turning a high performing team into something appreciably less productive is a real risk.

All initiatives depend on team performance regardless of the management method. But successfully using Scrum demands a high performing team.

Another high performing team.