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.
![jungle]()
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]