Code Scouting

Teams that I manage regularly perform code scouting to test the viability of potential solutions to particularly thorny issues before making any hard commitments to a single approach.

Code scouting consists of having one or more developers (scouts) spend a day focusing on writing and refactoring code with the sole focus of achieving the end goal. All the code changes will be thrown away at the end of the day and the purpose of this work is to scout ahead and gather information about the terrain the team will potentially be moving through. If we gather enough intel to determine there are blocking barriers to achieving our goal with the current plan, we will go back to brainstorming phase and figure out a different approach.

The purpose of the scouting is solely to gather information and since all changes will be thrown away the scouts do not have to be careful about maintaining the existing code base. One of the goals is to see what will potentially break and sometimes the only way to do this is to actually break it. If a scout gets stuck, they will document what when wrong and try a different approach. The more mistakes made during scouting the better off we will be when we execute the plan because we will know where the dangerous land mines are hidden and will have a plan to either deal with or avoid these traps. Hopefully, one scout will find a path through the code jungle that the whole team can travel down with little resistance.

The goal is for the scouts to push hard through the code and see what lies ahead if we decide to take this course of action. We will regroup after the scouts return with their information so we can put together a multi-sprint plan to achieve our goals.

Code scouting is an approach derived from the Domain Model Exploration Process (Eric Evans - Domain Driven Design) that I have found useful dealing when working with large and/or complex code bases.

DOMAIN LANGUAGE MODEL EXPLORATION PROCESS

[Original Article]