Team Planning with the On- and Off-Boarding Simulation

CodeScene’s existing knowledge loss analysis provides after the fact information. While that information is useful as input to planning and risk management, it is usually more important to get data we can act upon pro-actively.

For this purpose, CodeScene comes with a simulation module that lets you explore the effects of a planned off-boarding while the developers are still aboard. This gives you the opportunity to identify off-boarding risks and areas of the code in need of a new main developer. Let’s see how we use the simulation.

Access the Off-Boarding Simulation

The off-boarding simulation is accessible under Simulations -> Off-Boarding, as shown in Fig. 103.

Access the off-boarding simulator under Simulations -> Off-Boarding

Fig. 103 Access the off-boarding simulator under Simulations -> Off-Boarding.

The former contributors in your codebase, the ones configured as ex-developers in your project, are visualized using the black color. The simulation also lists all known developers. To simulate the impact of an off-boarding, select one or more developers from that list as shown in Fig. 104. The areas of the code affected by the off-boarding are then highlighted in red. Note that you can search and filter in the developer list, a feature that’s useful in projects with many contributors.

Simulate off-boarding effects

Fig. 104 Select one or more developers to simulate the off-boarding effect.

Detect Off-Boarding risks

CodeScene auto-detects high risk areas in the off-boarding simulation. That is, if a major hotspot is in the head of a developer who might leave, we consider that an increased off-boarding risk. The off-boarding risks are highlighted as illustrated in Fig. 105.

Detect off-boarding risks

Fig. 105 CodeScene auto-detects off-boarding risks.

Act on the Off-Boarding Information

The off-boarding simulation lets you identify the areas of the system where most code has been written by developers who might become former contributors in the future. This might happen for several reasons: a developer or contractor could leave the organization, or maybe a team of developers are re-assigned to a different project.

In both situations you typically have a period of time when the soon to be former contributors are still around to support the on-boarding of new people. Using the simulation, you can:

  • Guide on-boarding: If you identify a high-risk area where you will lose system mastery, then use this information to on-board a new developer in that part of the code.

  • Support planning and priorities: If the simulation shows that the organization will lose active knowledge of entire components or sub-systems, then you might have to re-prioritize or re-plan features that require extensions of those components. Typically, this means scheduling additional time for learning.

  • Look for upcoming technical gaps: Some codebases have a high degree of technical sprawl. This means that an off-boarding could lead to a situation where you have code implemented in a programming language that none of the teams master. As such, you want to compare the off-boarding data with CodeScene’s analysis of Technical Sprawl. The outcome of this analysis should influence training, hiring, and rewrite decisions.

In particular, look for components that are entirely in the heads of former contributors. That’s where the largest risk is.