Boost project velocity and avoid the hockey stick problem

One of my favourite hobbies is video games. Both playing them and making my own little games for fun on the side. Recently I stumbled across this video from famed Dragon Age producer Mark Darrah.

In the video, Darrah describes how the development of a game often resembles the shape of a hockey stick. For most of the project, progress is very slow, and it feels like not much is getting done. You’re doing work, but not a lot of it is immediately visible to your stakeholders. Then at some point very late in the project, you reach a critical mass of some sort. Velocity shoots up and everything starts clicking together.

Reflections on the hockey stick problem

I’ve come to realize that I have experienced the hockey stick on almost every project I have ever worked on. The early and middle stages of a project timeline are often very relaxed with a general lack of urgency. Most project requirements are still very high-level and nobody has a true understanding yet of what the end product will look like. This is usually the phase focused on building the MVP (minimum viable product). As a result, development teams often focus on building out chunks of “ground work” that will be “integrated later” to form the first release.

This lack of completion urgency combined with ambiguous requirements is what results in the sudden jump of the hockey stick. A mass of work has been done but the stakeholders see no visible evidence of it. The increase in urgency then occurs when you hear something from a stakeholder like “where is all the work?” or “what am I paying you for?” Sometimes an ultimatum gets thrown in there. Next thing you know, things start coming together and visible progress is being made! Unfortunately, this usually comes at the cost of stress, extended working hours, and even a loss of some trust.

So, how do you avoid the problem behind the hockey stick problem?

To me, the hockey stick is not a skill issue. It’s a communication issue. It is a product of many behaviours that are part of human nature. Conflict avoidance, tardiness, confusion. All these contribute to the ticking time bomb of the hockey stick.

But it’s not hopeless! A successful project requires a strong bond of trust between developers and stakeholders.

Here are some of the lessons I’ve learned in fostering this trust:

1. Get something visible on-screen early

For example, if your project is to build a mobile app that controls a thermostat, get a basic UI started as part of your first iteration. Even if it’s not fully wired up right away, its presence early on in the development process will enable a feedback loop with your stakeholders throughout the entire project rather than beginning that process later on.

2. Get your project in front of real users as early as possible.

You want to start a feedback loop with your audience as early as possible. Their feedback will help you get things right the first time rather than developing based on what you think the end-user will want. If your project is for internal use only, a second deployment can allow your users to interact with your work in progress without removing their ability to use the existing production deployment. For example: myapp.com and staging.myapp.com. For publicly-accessible projects, consider a targeted beta test to a subset of users. This will allow you to gather information on usage patterns an perceived value.

3. Set a regular cadence for deliverables

I’ve been on projects before where the only method of tracking progress was a single kanban board where work went from “To Do” to “Doing” to “Done”. For me, nothing kills completion urgency more than not having targets and goals. I’m not saying you should put undue pressure on your team by setting deadlines, but employing some kind of iterative process with a target deliverable at the end of each time interval does wonders to demonstrate progress to the stakeholder and gives the team an end-goal to strive towards.

4. Schedule regular demos

To tie into the above point, set a recurring meeting at the end of each iteration to demonstrate your progress with your stakeholders. It’s easy to become passive and “wait until there’s something to show off” but having a recurring touch point gives both sides a sense of investment in the ongoing health of the project. Regular demos invite feedback which otherwise might not have been given and provide an opportunity for development teams to ask questions and get answers.

5. (Bonus) Implement feature toggles

This has been one of my favourite techniques for gradually rolling out functionality to end-users. With a simple toggle, you can enable or disable specific app functionality live in production. This allows you to merge code and deploy to production as you develop rather than having to defer production deployments until the entire feature is ready. You can also use them to test functionality with real users and adapt your project specification based on their usage patterns. This allows you to more confidently build what your users need the first time rather than after the project has been completed and shipped.

A quick and dirty example:

// feature-toggles.js
export function realTimeNotificationsEnabled() {
  return process.env.FEATURE_REAL_TIME_NOTIFICATIONS === "true";
}

// api.js
import { realTimeNotificationsEnabled } from "./feature-toggles.js";

function handler() {
  const message = ...;

  if ( realTimeNotificationsEnabled() ) {
    // Partial functionality or functionality under beta-test
    eventStream.push(message);
  }

  return message;
}

Feature toggles can be as simple or complex as you want them to be. You can implement a quick and basic version using environment variables, scope them to users with a relational database, or even leverage a more comprehensive solution. No matter your preference, feature toggles allow you to get user feedback sooner.

Small steps repeated regularly lead to big results

Iterate early. Start the feedback process with your stakeholders as soon as you can. Try to avoid laser-focusing on foundational code and micro-optimisations. Write as much as you need to get your work on-screen and refine as you go.

I liken it to starting a new exercise program. It feels alien and un-natural to conform to a regimen every day. You might even question why all this extra overhead is necessary because it doesn’t seem like much is changing. But like working out, the results only manifest themselves at a later date. It wasn’t what you did the day or week before that yielded the result. It was the culmination of every incremental improvement you made up to that point.