Recognize Excellence Traps

The technical excellence traps are about thinking you can get speed by not doing the necessary cleanup as you proceed.

• Thinking the team can proceed faster without refactoring code and tests
• Waiting for other teams to test the team’s work
• Feeling like no matter what you do, the defects multiply—or they never seem to decrease

You have options for managing these traps.

Trap: We Can Go Faster Without Clean Code and Tests

I have met people who want to postpone refactoring of code and tests because they think the team will proceed faster. Or they don’t want code review or some other way to get multiple eyes on the code, such as pairing or mobbing.

You can’t go faster when you avoid technical excellence.

Sure, your team might be able to finish a demo or make a trade show. That product is not going to work in production environments without problems.

Don’t trade speed of delivery for excellence in production code. Your team will create technical debt and cruft. (See ​Beware of Technical Debt and Cruft​.) Technical excellence creates speed.

Trap: Waiting for Other People or Teams to Test

Some teams don’t have all the skills and capabilities they need. Often, they don’t have enough tester capability. When a team doesn’t have enough capability to test at all levels, it ends up waiting for another team to test its work. That increases the cycle time and creates WIP. Too often, the team receives feedback about earlier work. That feedback is an interruption, a cause of multitasking.

Consider how you can make this problem and its results visible:

• Add an insufficient number or type of testers to your impediment board, as discussed in ​Visualize Problems with a Board​.

• Measure the cycle time, as discussed in ​Visualize Your Project’s Delays​.

• Consider creating a table, as in Table 12, ​Number of Multitasking Requests for Individuals or the Team​.

The more a team has to wait for other teams, the longer the project will take. The cost of delay will rise rapidly. Or if a HiPPO says, “release it anyway,” the customers might not like the quality. Do what you can to create an environment of technical excellence.

Trap: Defects Prevent the Team’s Progress

Teams discover many causes for their defects. If they don’t practice keeping the code and tests clean, the code and tests can become so complex that it’s impossible to make progress. (Joe Rainsberger has an excellent talk called “7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development” about this problem.^[18])

If your team’s cycle time increases, or if the fault feedback ratio becomes too high, consider the following possibilities:

• Identify the root cause(s) of the last six to ten defects. With any luck, they will share root causes. Here are some possibilities I’ve seen: fixing one defect uncovered more; cascading defects, where one defect causes several more; and the code is so complex that finishing anything is akin to climbing Mt. Everest.

• If the team understands the root cause(s), see if there is a handful of defects—which, when the team fixes them, will help it proceed faster. Sometimes the team needs to fix only a few things before it can make progress.

• Ask the team if it’s collaborating and refactoring as it proceeds. Maybe it needs a practice radar chart to see if its practices lead to clean code.

For example, one team started to chart several practices when it started its agile adoption, as illustrated in the radar chart that follows. The team experimented with these practices, under the assumption that if it practiced these ideas, it would have better throughput with fewer defects and a lower fault feedback ratio.

The team worked on its technical practices to see if the practices helped the team’s throughput and defects. After three months, the team’s chart looked like this one:

The team wasn’t perfect in its adoption of its chosen practices. However, it had many fewer defects, its throughput was up, its stories were smaller, and it was seeing the end of overtime. The team had started with code review and moved to pairing. The team was thinking about TDD or BDD as a way to help its unit test and system test automation. It used its practice chart as a way to help the team think about its improvement.

You, as a leader, might need to work with the product owner to make sure the team has the opportunity to fix problems—even problems not related to the features the team is working on now—to move toward a clean code base. Those problems might be code. More often, I see insufficient testing. Your team might have both problems.