Hitting Software Deadlines: Essentials Only… then Upgrade

From “Deadline” can seem like a dirty word, in the software world. But without them, our work wouldn’t see the light of day, get an audience or have an impact. So despite their perceived unpleasantness, I’m all for them.

We tend to plan work towards a deadline in ways that ignore two inherent truths about software development, and therefore often miss them:

  • Complexity appears late: Despite our best efforts to surface it during planning and design activities. This is the reason plans go awry at the eleventh hour and deadlines that seemed achievable are inexplicably missed;
  • Completeness is hard to nail: Specifically, deadline-completeness. This means only the things that are strictly necessary for a viable release, launch or demo at the deadline. This is likely smaller than the list you feel you want to include, but adds crucial items that are usually not visible to a client, such as productionising, releasing, legal formalities, etc. Many of these are usually slotted in just-in-time before a deadline, or missed. Denial of the need to nail completeness, or discovery of further complexity here, can undermine a deadline.

Maybe we could try something along the following lines, to hit deadlines more often:

  • Find the Essentials for Deadline-Completeness: Begin by ruthlessly separating the work that must be completed for the deadline, but perhaps in a heavily-downgraded form.
    This might mean something releasable to a production environment (in a walled-off manner, minus a final trivial “reveal” on the deadline date), something that discharges legalities, and something that exercises the agreed use cases in a minimal but viable manner.
    Encourage people to write separate stories for bare bones deadline completeness, and then the rest.
    Also write meta stories for items required for completeness that would otherwise be forgotten due to not being visible to a client, such as deployments and productionising;
  • Hit deadline-completeness early: Complete the bare bones deadline-sensitive work as early as possible, and nothing else. In an Agile approach, this should be at least a sprint or two before the deadline itself. You will end up with a very minimal but released (though perhaps walled-off) system that would hit your deadline, but would perhaps disappoint you in a number of ways. Learn to accept this, because you won’t be revealing this version of your work and something much more crucial just happened that is worth celebrating: You already hit the deadline. You are already capable of delivering. So now, you can…
  • Upgrade, iteratively: Add in the work to upgrade that initial complete solution in tight iterations. Each of these should result in a system that is “better” in some way but still deadline-complete; remains releasable, still discharges legal obligations, still exercises the same use cases and perhaps some new and less crucial ones.
    Iterate on these upgrades, in a order of decreasing priority, until the deadline.

When the deadline comes, as it inevitably will, you are guaranteed to hit it in some viable and complete manner. There will always be upgrades you wish you could have included but they will be the least important ones and, much more crucially, you aren’t left with an incomplete solution that can’t released, demonstrated or used.

Approaching deadlines in this way means that complexity can be handled as it arises, without derailing the deadline. Hitting deadline-completeness in a minimal way, then upgrading, allows complexity to push out less-crucial upgrades if necessary. Yes, you don’t want it to… but the reality is it might need to. Post-completeness, there is room for the battle between complexity and upgrades to take place, however that plays out and without risking the deadline.

How do you persuade people to adopt this approach? By showing them that everything is still planned to be included, but that deadline completeness is prized first. Assure them that other upgrades, in decreasing priority order, will only be omitted if unforeseen complexities or problems arise. The maximum value possible is still going to be delivered. Nothing has changed but the approach to delivery and risk.

Isn’t this just Agile? If your approach to Agile (and there are many) includes a notion of deadline completeness, perhaps. But who really does Agile that way? After hitting the deadline early, the iterations are Agile-like. But this approach forces early inclusion of aspects that might be unseen to a customer in an Agile world — hence no stories — but which are crucial for the deadline, such as productionising.

Find the essentials and complete them early, then upgrade. By planning in a way that handles complexity like this, maybe we can let it do its worst — as it inevitably will — and still deliver to a deadline?

For a Coherent Software Product… Draw More Diagrams

Pencil, By Juliancolton (Own work) [Public domain], via Wikimedia Commons

Unless you’re building it entirely on your own — and even sometimes then — for a unified and coherent software product, you need prominently-shared diagrams of what you intend to build.

Most software products are built by more than one person; more than one mind. Most are built by more than one team and usually across more than one skill or discipline. That’s many backgrounds, many viewpoints… but still one intended product in which they all need to be unified.

No-one would imagine coding an API without a spec, yet we often build systems without a diagram of the architecture, components, boundaries or intended flows. Retrospective diagrams often never happen, or happen way beyond the point it became painfully obvious they were needed. We over-rely on the verbal signs that we are aligned, without backing it up with a diagram.

Without a shared vision of the intended outcome, we’re likely to translate any purely verbal descriptions into different mental models, and onwards into different technical solutions… which then need to be aligned. “Oh I didn’t realise”, becomes all too common. This is particularly true in places where multiple disciplines overlap: Product owner, UX, front end, back end, operations, marketing, etc.

Everyone sees their piece of the puzzle, but diagrams confirm how they will all fit together. Without them, we introduce opportunities for hidden agendas and unnecessary extras to creep in. Human nature dictates that, where ambiguity exists, we tend to work silently to our own preferences rather than seeking a unified team answer. A diagram can provide that answer, or at least highlight the blank space in which it needs to go.

What to draw?

Whatever you find yourself discussing… but especially user interfaces, architecture, components, flows, and absolutely all inter-team or component boundaries.

How many drawings?

Just enough… but at least the highest levels of the product, then break down where more clarity is required and particularly where team boundaries exist.

Not too many though… or no-one will look at them. Find a happy balance.

What to draw with?

Informality, and a shared medium… Keep diagrams informal, because speed is important in encouraging capturing of info. Use a tool for more formal diagrams, but a tool that everyone can access; the person drawing the diagram will not necessarily be the only one changing it or adding to it later.

Where to draw them?

Visibly! Stuck away in a repository or a wiki where people rarely (or begrudgingly) go, diagrams are next to useless. Get copies of them on up on the walls too.

Update them!

An obsolete diagram is worse than no diagram. Think living diagrams!

When a change arises, update the diagram now, even if only with a scribbled annotation on a printout to be added to the original later. This is why informality often wins; there is no pristine copy that needs painstakingly updating.

Assign someone the action of updating the diagram, and make sure that they do.

Encourage diagrams

Make sure whiteboards are available, with pens (if you have to hunt, the moment will pass). Also make sure wall space is available, on which to stick diagrams that will live for longer.

Whiteboards aren’t just for visual disciplines; encourage engineers to draw components, flows and architecture too. Even short-lived diagrams, such as those drawn in one meeting, can unify people at a point in time. Get everyone comfortable with the idea of standing up with a whiteboard pen… and drawing. It should be a daily occurrence.

There should be a blank whiteboard usable by anyone who feels the need, at any time, and preferably within reach. This is a cheap resource, so over-provide. The improvement in communication, and in a coherent product, will be worth it.

Why Time as a Solopreneur Might Make You a Better Team Player

forwardTeamwork: Good. Lone work: Bad.

Or at least that’s how the stereotype drummed into us through education and our careers seems to go. We learn to focus our CVs and resumés on our team contributions, and to downplay the things we achieved entirely alone.

But what if the things we achieved on our own somehow made us more effective the next time we joined a team? What if a balance of both experiences made for better team players?

It’s my experience that teamwork between people who have never known an occasional lone accomplishment can suffer from a few blind spots: Such team members may have an inaccurate view of their contribution and how to tune it, having only ever seen their work as part of a larger deliverable. There’s a danger of feeling like a full four-wheel contributor, whilst actually running on three wheels and being unaware how much your contribution leans on the work of others. People who have never known personal wins can see a team project as their only chance to demonstrate their abilities, and may be over-invested in personal outcomes rather than team outcomes, safe in the knowledge that they can shine elsewhere or next time.

So what do I mean by lone accomplishments? Lone accomplishments could be a product (software, hardware, anything), a piece of art, training materials, blog posts, or a book. Anything you actually launch, publish or deliver to an audience, for which the entire deliverable depends on you, and for which you have no backup or other input to assist. Anything for which there is no scapegoat once you deliver it; it is yours, good and bad.

I’ve done this twice, with software products of my own. They were far from a commercial success, but the lessons learned were worth more than the time I spent and the salary I forfeited in those months. Since then, I’ve gone back to teamwork in startups, and really appreciated the perspective that my lone achievements have given me.

So what do lone accomplishers bring to a team? How can lone work strengthen and define you?

  • People with lone projects under their belt tend to have a more accurate view of their own strengths and weaknesses, and an appreciation for the roles others perform in a company.. because they’ve probably filled them at some point, albeit probably rather clumsily. Most former solopreneurs will have noticed how they couldn’t possibly fill all those roles alone… and will appreciate that it is only possible to cover them well in a team where a variety of skillsets are present.
    For me, as a software engineer, I now have a great appreciation of the other roles involved in startup life: Marketing, PR, design, QA, Ops, etc. Prior to undertaking my own projects, I probably had a dismissive or inaccurate view of those roles.
  • People with lone projects under their belt already have personal “wins” in the bag, so they don’t feel the need to act as if the next team project is their own pet project or chance to shine. This makes conversations more about a team win, rather than a personal win, less religious, more exploratory, and more practical.
  • People with lone projects under their belt tend to appreciate the difficulties of building something entirely alone, and therefore the need for others. The mature lesson from this is a willingness to delegate… and truly delegate, giving people a long leash and adjusting it appropriately. Knowing I can’t do it alone, but might be able to achieve it with others, makes me value the contribution of others and the need to delegate effectively.

Why is lone work a rarity? Aside from the widespread celebration of teamwork, we probably shy away from lone work because we know it will truly define or break us; there is no middle ground, and so we fear it. Through it, we will either discover, once and for all, that we can lean into a challenge on our own, or that we don’t (yet) have what it takes. Unlike teamwork, there is no scapegoat, no fallback, no-one else to blame. This is a hard reality to face.

But I’m convinced that every day we put off an attempt at lone work, is a day we never really understand what we are capable of; both alone, and in terms of our contribution to a team.

I’m convinced that, particularly in industries that involve building something (software, hardware, arts), we should exercise our lone capabilities on a regular basis, and at least once a year. It’s an ongoing eye opener on who we are, what we’re capable of, and therefore what we each bring to a team.

Far from being a red flag when hiring, lone work — when properly learned from — could be the thing that truly makes a strong team player.