Tracer Bullet

So are we going to talk violence on a software blog now and that too when we are approaching a new year ?

🙂 Well absolutely not, I’d say this bullet is a special type of bullet in software which is effective and harmless

What is this “Tracer Bullet” ?

Tracer bullets are loaded at intervals on the ammo belt alongside regular ammunition. When they’re fired, their phosphorus ignites and leaves a pyrotechnic trail from the gun to whatever they hit. If the tracers are hitting the target, then so are the regular bullets.
Not surprisingly, tracer bullets are preferred to the labor of calculation. The feedback is immediate, and because they operate in the same environment as the real ammunition, external effects are minimized

How does this term relate to software ?

Today’s blog post will shed more light on a practical usage of this tracer bullet terminology in software.

If you are up against a complex software requirement or a requirement which has a lot of unknowns or a brand new project or a type of project which has never been attempted in your team/organization then Tracer Bullet development approach will help you provide agility in your development style in the quickest possible time.

Lets take a quick look at a team who is looking to migrate from waterfall model to scrum and were up against a business requirement which was complex in nature with a given high level Functional Specifications (FS). Yes, you guessed it correct, that’s not an ideal scenario for agile(scrum) development. A typical organization is divided into pool of resources like Business Analysts, Developers and Testers. Upgrading the skills of your existing resources to bring a change within the team to help create an environment which can support and sustain agile practices efficiently requires a considerable amount of time & effort. Therefore such scenarios are common in teams who are migrating from waterfall to scrum where some set of resources are skilled enough to start developing in an agile way and some may take more time.

This team was facing a similar situation, therefore they divided the Functional specification into multiple relatively independent features and prioritized the most ambiguous, most complex feature & highest business value feature on top of other features.

Once the prioritization was done, the team chose a tracer bullet duration of not exceeding 4 weeks to do a narrow implementation of the prioritized feature. At the end of each tracer bullet duration the feature was demonstrated to the stakeholders by clearly stating the in-scope and out-scope items for the current tracer bullet.

This approach had the following benefits

• Enabled the customer to view the early results and provide its feedback which is then looped into the next tracer bullet development( if planned or required ) i.e. the team re-aims in the next bullet only to achieve more accuracy if they are far from their expected hit target.
• Enabled the customer/management/team to measure its progress in terms of product increments.
• Team mitigated the risk by delivering the most complex part of the project early in the project life cycle.
• The team delivered a production quality code in each tracer bullet cycle.

The team had to repeat the tracer bullet for few cycles and then had to abruptly stop as the other projects got prioritized over this due to market changes, but hey notice that in these few cycles they have delivered a production quality code in an agile manner even though they were not having user stories to start with and it’s usable, of production quality and future increments can build on top of it. The tracer bullet approach was acting as a win-win situation for all type of stakeholders in this case.

Now let’s look at team’s decision from two different view points

What if they followed the traditional waterfall approach ?

Ideally the development will start only after defining or scoping all the major requirements. If this process is taking long, then they may have to divide the project into multiple phases i.e. the most complex, most risky, highest business value part would be done last as it has a lot of unknowns to uncover which can take a considerable amount of time, in addition, we assume that the development done in earlier phase will be of help in next phase.

Now, let’s see what if they followed the Scrum process ?

In this case they would have to first convert their big-fat functional specification into user stories and acceptance criteria, I believe only then they can do scrum in true sense, this means a double effort on requirement gathering side was required which may result into longer time to market. The fact that the team was up against a functional specification also shows that they are not ready for scrum and is in need of training to upgrade the skill set.

This was one such team and scenario where tracer bullet did work without much overhead of processes. In my opinion, existence of tracer bullet is independent of it being in agile or non-agile processes, what triggers a tracer bullet development is a requirement  having high business value and is vague or contains more unknowns which can only be known after implementing the same e.g. complex and ambitious algorithms.

Lastly I am keen to hear from you on this approach as I observe that this is a less talked approach on the internet.

References

The Pragmatic Programmer: From Journeyman to Master – By Andy Hunt and Dave Thomas

DISCLAIMER : The views, opinions and information compiled in this blog are completely mine and has nothing to do with any of my previous, current or future employers