Coaching Leadership

Dont Innovate to Hit the Date

When we’re building software, we’re creating something new. It’s exploratory, it’s uncertain and it might not work.

Often in the world beyond the tech teams, we think we’re just following a plan to build to a schedule.

The mismatch between the two causes approximately all of the conflict in a software focused organisation.

We use a lot of techniques to bridge the gap, all loosely badged under the Agile heading. Basically, we always endeavour to have working, shippable software that we can show to people, and we always complete the most important things first. That means we can launch the software on any given day, and it’ll have the most vital pieces.

Engineering have the power to solve problems, stakeholders have the power to decide if their problems are solved enough or not. So when we work in this way, everyone gets their key pain points addressed, and everyone is happy.

This works best when we’re working in an incremental problem space, building out a product that provides benefits with some features, and will provide more as those features are added to and refined.

Sometimes we’re not in that space. Instead we’ve got to hit a fixed date. We know what we need to and we know when we need to do it by. When the date is truly fixed, it’s usually due to some sort of regulation, so there’s the added spice of needing to be compliant with some law or face a penalty.

In this scenario, we need to strip back some of our exploratory instincts and move more towards the schedule model. Nevertheless, we must also keep in focus those agile principles of solving the most important problems with always shippable software.

Rather than innovating, we make sure we hit the date:

  • Pick known technologies
  • Extend solutions that work today rather than starting from scratch.
  • Choose the approach that has least work
  • Sequence your plan to get to done sooner
  • Allocate additional resources

When we know what we need to do, we are following a map along a known route rather than exploring the territory.

Measure your progress, correct your course when needed, and don’t innovate to hit the date.


Building to Schedule

There’s a common mistake in the thinking of people outside the immediate world of software, and that’s in thinking that it’s a predictable and repeatable process that should be easy to plan.

The comparison that is made is usually towards building houses or something similar. We’ve spoken before about the creative endeavour of software, and about how house building might not be as easy as it seems from the outside. Today I’ll look a little bit more at that.

Across the road from me is a brand new theatre. It’s probably about 60-70% complete, and I’ve been able to watch it take shape over the last year or so. In it, I can see a lot of familiar activity from software development, writ large on the physical world.

It’s particularly relevant as it’s a unique construction. It’s following a plan, but it’s clear that there’s learning and refinement going on all the time. I’ve watched walls go up to be covered in insulation, that’s been inspected, taken down and redone. I’ve seen windows being put in whilst other trades are forced to stop their work to let the glazers past.

There have been days when the main activity is inspecting what’s been put-up, which has again led to rework and changes.

It’s not a simple linear progression of steps, it’s a cycle of work, review, pass / fail and rework or move on.

It’s clear that this distance from the linear progression is even more pronounced due to the unique nature of the building. It’s big and complex, and it’s not the same as anything that’s gone before.

That’s exactly what we get in a software product. Big and complex, a unique creation and something that needs to show learning as you go.

So if you are struggling with someone who thinks it should be an easy task of following a plan step by step, show them someone putting up a complex landmark building to open their eyes to reality.