Strategic software development.

Introduction

This article will talk about how using recon spikes as part of your development lifecycle can help you do well.

We’ll cover what a reconnaissance spike is, how to use them effectively, and why they’re essential for your development process.

We’ll also talk about when to schedule recon spikes in your process and how to help teams avoid getting tripped up, bogged down, or lost along the way.

Finally, we’ll discuss how to incorporate the intelligence gained from a reconnaissance spike into your team’s codebase so that everyone can learn from it, grow from it, and benefit from it long-term.

Why is explicit recon work necessary?

It’s time for a simple but essential question: why do you require reconnaissance?

Here’s why: Software differs from other types of manufacturing.

You’ll never have all the details, questions, and answers upfront. Instead, you enter ambiguity, guided by the faint flicker of a distant goal. You know the aim, but shadowy unknowns shroud the path forward.

And with time, you’ve learned that charging into the dark without looking is dangerous.

So, as a software professional with a lot of experience, you’ve probably done what you should to get ready for the inevitable problems that will come up before a project goes live.

And you know that success requires planning. At the very least, you have a general map of the area you’ll be traveling through, a team that works well together, and enough supplies to make it through the trip alive.

On the path forward, you know there’s only one thing you can count on: a continual barrage of surprises.

Treating software manufacturing like a construction activity not only creates fragility but also guarantees failure.

Planning for Surprises

While construction is part of the equation, there’s more to it because surprises always appear on the path forward.

Inevitable ambiguity and surprise are why the software industry pivoted from Waterfall to Agile processes over twenty years ago.

But here’s the thing: today, too many companies only pay lip service to Agility but don’t reap the rewards.

I’m sure you’ve seen teams blindly following cookie-cutter Agile processes with an underlying Waterfall mentality.

• They follow the process rules but miss the purpose.
• They do agile but have no agility.
• They are stuck in overdrive with no capacity to steer.

Let me ask a simple question: Can you see how if you can’t deviate from an original course set at the beginning of the project, you’re not agile?

Unfortunately, it’s prevalent, even today, with teams using Agile processes.

Most of this stems from a need for a deeper understanding of software development: software production is a journey into the unknown.

Don’t get me wrong: Agile is an excellent framework for managing software development projects. But the whole point is not about following an exact process or a set of cookie-cutter rules.

• Agile processes aim to achieve agility.
• Agility requires guiding teams through ambiguity and surprise.
• Managing surprises requires planning, learning, and adapting.

And so, when you hit roadblocks, your best bet is to stop, assess, discover your options, and pick the best one.

Are you agile?

Here are some common warning signs of a Waterfall organization disguised in Agile clothing:

• Lack of planning and preparation.
• Mistaking estimates for reality.
• Not accounting for project surprises and pivots.

To BE agile, your software development requires a balanced blend of construction, discovery, and invention.

Agile teams don’t just work hard. They also work smart.

Best wishes and warm regards—Matt

by the way

Are roadblocks slowing you down? Is your software development project at risk?

We have experience running agile processes, designing agile technology projects, and producing agile systems.

We’re happy to share our expertise to help you plan and prepare your team for project surprises and pivots.

Click here to contact us for a free consultation.

Use Truth Shield’s technical project design services to stay agile from planning to delivery.