The videos in the last two posts, How to use Positive Deviants to Solve the “Not Invented Here” Problem and Psychotherapy without Archaeology, introduced the concept of Bright Spots or Positive Deviants and described how to leverage them. In today’s post, we apply the concept in the real world. I’m going to describe how to find the Bright Spots in a software engineering practice called Test-Driven Development.
Test-Driven Development (TDD) is a powerful technique for improving the quality of software designs, but requires a significant amount of training and practice to perform proficiently. A great way to spread TDD skills (or refactoring skills, or pair-programming skills, etc.) is by looking at what is already working in your organization, that is, looking to your “Bright Spot” teams.
Identify Bright Spots
Assuming that your organization’s leaders are in favor of having the teams acquire TDD skills and attempts have been made to give teams opportunities to try it, then we can begin gathering data on what teams are already successfully practicing TDD. Questions to ask may be:
- Are there teams that can claim that TDD helps them deliver at a more regular velocity?
- Are there teams that can claim that TDD helps them deliver code with fewer bugs?
Understand “Normal”
Next, we make sure we understand the “normal way” things are done. Do people on all the teams at least write unit tests and, if so, are they true unit tests that isolate the unit under test from its dependencies or are they more like integration tests? If they are failing to do this much, you may need to go back a step and try this same “find the bright spots” technique to bring your organization up to par on basic unit testing skills.
Validate Bright Spots
Then we want to make sure that none of the teams we identified as bright spots are exceptional in a way that disqualifies them as a bright spot. For example, if the bright spots are writing code for a different domain than the other teams, say web applications versus embedded systems, that may be something to take into consideration as a potential disqualifier.
Bright Spots vs. Normal
Next, study what the bright spot teams are doing:
- How are they addressing challenges like lack of knowledge of good dependency isolation practices or refactoring practices?
- Are there differences between how bright spot teams are structured and how the rest of the organization is structured?
- Are bright spot teams rewarded in a different way?
- Do they practice other extreme programming skills that make TDD easier, such a pair programming?
Clone Bright Spots
Finally, find a way to reproduce the practices of the bright spots in the other teams. The bright spots, not you, should be the ones to teach the others. Some options for knowledge sharing could be:
- Having bright spot team members lead seminars
- Having bright spot team members participate in cross-team projects where skills can be transferred
- Creating a community of practice for sharing these skills among representatives that can then share with their teams
The main thing is that you’d be avoiding the “Not Invented Here” problem because the solutions would be known to work in the organization and would be coming from within the organization itself rather than coming from some ivory-tower academic or out-of-touch consultant.
I would love to hear what you thought of the article, so feel free to comment below, on The K Guy Twitter, or on The K Guy Facebook fan page.
Pingback: Find The Retro Feeling - The K Guy()