Plan

Focus on what matters

Planning is valuable in so much that it can provide clarity and alignment on:

  1. What is to be achieved

  2. Why achieve it

  3. How to achieve it

    1. What is going to be done, in what order

    2. by Who

  4. When

But incompetent manager-types tend to do two things:

  1. Confuse the plan with achieving goals e.g., obsessing about story points or tickets, instead of what’s been built.

  2. Overestimate the ability of humans the future, by obsessing about When.

Notice that when is at the bottom of the order of importance, and for good reason.

Breakdown work into manageable pieces

Projects (bodies of work) vary in size, complexity, uncertainty and dynamics, and in many cases, you’ll want to break it up into manageable pieces. Rather than choking on an apple trying to swallow it whole, take multiple bites.

Time-boxing is not necessarily helpful.

Scrum-worshippers dogmatically push the idea of monitoring progress using fixed time-boxes 'sprints'. This can be useful or destructive to productivity.

What you’re trying to monitor is progress. Progress can be broken up by time, architecture, functionality or other dimensions. If time-boxing doesn’t add value, don’t do it.

At least tune the time boxes to meaningful intervals. Basecamp uses 6 week intervals because they’ve found that interval generally encapsulates most discrete units of work they do in their circumstances.

A symptom of it being counterproductive is when contributors spend more time talking about how the work is organized/fit into the time boxes, than the work itself.

Slice up the cake vertically and horizontally as needed

Peak 'Agile' out of web development was dogmatically about splitting up software development progress by vertical (functional) slices across the entire web stack (frontend to the database). A downside of this approach is producing an incoherent, fragmented end product, as variation is introduced with each vertical slices.

Layered architectures think about horizontal (architectural) slices of abstraction through the software/system. The downsides of progressing layer by layer included the longer time frame to get to a functional product, and the potential of moving goalposts (end user requirements) in the meantime.

As The Studio Model points out, properties of systems, including software, can be emergent. When building a house from scratch, you have to lay the foundations, then build up the structure before any rooms can be finished to a usable state - at which point you can progress room by room. So, there’s a long period of no apparent creation of utility, then it all appears relatively suddenly towards the end.

By avoiding dogmatism and thinking upfront, you can break down development by combining both vertical and horizontal cuts, trading off the risks of fragmentation against delayed emergence of value.

Treat estimation with the distain it deserves

A rubbish movie delivered on time and to budget is still going to bomb at the box office and lose investors their money…​ so when is far less important that what. The amount of time misallocated to when over what in organizations - i.e., becoming better predictors of the schedule of their failure - is regrettable but reflective of incompetent leadership that no foundation in the disciplines over which they’re supposed to be leading.

Nonetheless, there are perfectly reasonable reasons for wanting to it, in terms of managing risk and financial investment.

Estimation and scheduling is about predicting the future and setting cost/time expectations accordingly i.e. reserving time/money to do the work.

The only problem is that humans suck at predicting the future. How many movie productions come in on time and under budget?!

  • Different disciplines have very different dynamics. 'The world of atoms' is very different from 'the world of bits', because the former is governed more by the laws of physics and the objective universe, whilst the latter is ultimately limited in the same way but more by thought. Thus, physical engineering disciplines have different timescales for development, different complexities for problem resolution, different ranges of possible solutions and more.

  • Creativity introduces lots of uncertainty. Manufacturing processes are mechanical, repeatable and predictable, because they don’t have human creativity at the heart of them. The time to imagine/innovate/envision is so much more uncertain. Work that is worth doing is often new and unfamiliar.

  • We don’t really know how long it takes to resolve a problem, unless it has enough similarity to a previous encountered problem and solution. TV shows like 'Law & Order' give the impression that all mysteries are always neatly solved in 45 minutes, no matter who’s dealing with it.

  • Other work disrupts the best laid plans. Rarely are people left to focus solely on one project, uninterrupted by other work streams.

  • Learning might need to happen on the way e.g. new skills, languages or tools. The time required to do work can depend strongly on the expertise of the people doing it.

  • Unexpected supporting work might need to occur, e.g. building infrastructure to support the development.

For all these reasons and more (but remember to focus on what matters):

Good estimation = Experience + Pessimism

Estimation: How can you find experience to fed into estimation?

  • Ideally by interrogating a time tracking system.

  • Alternatively, t-shirt sizing is a useful, lightweight tool.

Pessimism: A rule of thumb that I’ve seen work better than any other (and heard that other competent software engineering leaders had similarly concluded independently), is:

Whatever your initial estimation is, double it.

Part of the dynamic this rule of thumb fights against is the desire not to tell the truth, which is:

  • "It’s probably going to take a lot longer than you want it to"

  • "I don’t know"

The 'story point' concept was originally intended to avoid estimation altogether by estimating complexity, but was widely and rapidly perverted back to time estimation because truth telling is difficult.

Adopt continuous transparency

The better alternative to desperately clinging to the false hope of precise prediction of the future, is to provide at-a-glance continuous transparency.

Make it obvious and clear what’s being done in real time e.g., through access to status and progress dashboard.

  • It engenders trust, if you’re acting in good faith.

  • It enables issues, and discussions around them, to occur sooner, before the issues, or their effects, become much worse.