JIT software planning

Wikipedia defines planning as

“the process of thinking about the activities required to achieve a desired goal. It involves the creation and maintenance of a plan, such as psychological aspects that require conceptual skills.”

In software parlance, planning is the activity that results in shipping feature x at time y, which sounds much simpler and easier than it is. If in doubt, I recommend you to search for “software planning” or “software project management” on Amazon to explore the variety of books (and practices) dedicated to this topic. Even more bewildering is the amount of literature dedicated to software projects running amok. It seems that planning for the delivery of software project is at best a game of chance. Or is it?

Working in a start-up teaches you that you better be right about choosing and prioritizing the projects you work on (what to work on). Even more importantly is in delivering these projects/features at a agreed upon timeline. Choosing the wrong projects ends up wasting invaluable resources. Similarly, delivering a project over-time or budget is equally wasteful. You need to eliminate the waste in both choosing the wrong project(s) and delivering them way over time. We’ll explore both aspects over this article and a subsequent one.

What to work on?

In the absence of limited resources, figuring out what to work on is relatively easy — you can work on everything and in no particular order. Sadly, that is not the world most organizations, and specifically resource starved startups, live in. Resources are scarce; much less than the amount of work that the business wants delivered.

I’ve worked at various organizations where planning and prioritizing is typically an annual, or perhaps a semi-annual activity. Typically, a group of people get in a room to argue and debate about the product plan for the next 6, 9 or 12+ months. These folks would span sales, product, support, engineering, finance and other constituents. This process could last one or more days and result in a product roadmap, which details what ought to be built and when.This model has many problems.

First, it assumes that this group is good at predicting the future, which research tells us over and over again is something humans are not good at. Case in point: hedge funds, who rely on predicting the movement of stocks, yielded 50% of the returns of simply betting on the S&P500 in 2017. The implications of this are profound. Relying on terrible predictors of future events (read humans) to build a product plan is incredibly risky. The bets this group made about the wants and needs of the consumers of this product will likely be wrong. I wouldn’t want to bet the future of my product or company on this approach. It’s best to accept that we humans are terrible at predicting, and, therefore look for a system that doesn’t rely on humans making long term predictions.

JIT manufacturing

This problem isn’t particularly new. Car manufacturers were faced with an equally challenging problem, that of predicting demand over a period of time. Not only did they have to predict aggregate demand (how many cars will they sell), but they had to break that demand into discrete components (demand for Toyota Corolla vs Toyota Camry). Car manufactures would rely on these predictions to purchase raw materials, build up inventory and hope that they are right. Get these predictions wrong and they would end up spending huge amounts of cash and a massive build up of unsold car on their lots. That could spell disaster for a car company.

And then, came Toyota..

“Just-in-Time means making only what is needed, when it is needed, and in the amount needed. For example, to efficiently produce a large number of automobiles, which can consist of around 30,000 parts, it is necessary to create a detailed production plan that includes parts procurement. Supplying what is needed, when it is needed, and in the amount needed according to this production plan can eliminate waste, inconsistencies, and unreasonable requirements, resulting in improved productivity.”

That. Is. Amazing!

JIT software planning

Much has been written about the merits of the Toyota Production System (TPS) and its reliance on Kanban and JIT manufacturing to eliminate waste and maximize yield. At Qumulo, we wanted to build a process that can yield these same outcomes but work for the software industry. The very first problem we tackled was in trying to answer what to work on at any point in time. For that, we relied on a process that continuously re-evaluates and re-prioritizes work.

Bootstrap the backlog

The first step in our approach is to create a prioritized backlog of work. This assumes that we are starting from a blank sheet of paper: no product exists yet. The bootstrapping process will likely be much similar to the process I outlined earlier whereby a group of stakeholders from various parts of the company get together and try to predict the future. The difference this time , is that they all agree that whatever they agree on will be continuously reviewed — in our case on a weekly basis — and likely change.

The plan is never locked. The end result of this bootstrapping process is an ordered list of work, with high level estimates to delivery associated with some or TBD with ones that are still without estimates. An example list is shown below.

Figure 1: Initial backlog

The diagram above shows the result of this bootstrapping process, which results in an ordered list of features. Features are assigned to an available product delivery team, who will usually start off by providing a delivery SWAG for their feature. Features with no team assigned to them will be worked on in priority order as soon as a product delivery team frees up.

This model has a few key assumptions:

• Product delivery teams are not aligned to a feature. Simply said, teams can work on any part of the product and are not tied to a single part/feature within it. This introduces a tremendous amount of flexibility in the system, albeit with some context switching. We try to balance that by assigning related work to the same team to minimize the context switching and learning curve. However, if no work relevant to what a team has been presently working on is available, that team will jump on the next available most important unit of work.
• Product delivery teams have all the resources they need to deliver their work. Said otherwise, a unit of work will be delivered by no more than one product delivery team, although exceptions do occur. Our teams are staffed with all the resources they need to deliver their work. These include software engineers, designers, UI engineers, hardware engineers, data scientists and any necessary hardware or software needed. It is critical that teams have all the resources they need to deliver their feature without relying on external resources. This eliminates dependency risks, and, more importantly empowers a team to get the job done.
• Teams are trained to always leave their work in a good state. We train our engineers and teams that interruptions will occur and therefore any code they check-in, has to be in good working order, tested and in a state whereby any other team can pick up at a later point in time. This isn’t easy and it isn’t something we strive to do. Dropping work and moving onto to something else half-way through a project is wasteful, but it could occur.

Continuously revise the backlog

Every week members of the engineering, product and support leadership teams will huddle for 30–60 minutes to evaluate progress against the currently assigned work items. That crew will also take into consideration new data learned over the last week. Data points from existing customers, engineers, sales and support might require that the backlog be revisited. The end result of this meeting is an updated backlog, which for the majority of the time remains unchanged from last week.

There are times though that the backlog, and therefore what teams are working on, will change. For example, a customer escalation or an impending deal with a feature request might require that new work be added to the backlog. The diagram below shows the revised backlog from Figure 1 above.

Figure 2: Updated backlog

The initial backlog in Figure 1 was updated to reflect an incoming customer escalation that was assigned to team Quay. That team had to temporarily put their work on Feature A down to deal with the escalation. Similarly, Feature I was added to the backlog at priority 8 pushing Feature F further down.

Conclusions and next steps

This process also relies on us having high fidelity and frequent data about the state of the product. We rely on looking at sales data from Salesforce, having weekly calls with the sales leadership to understand customer requests, evaluating customer support issues and data from our engineering team related to quality, refactoring and exploratory projects (we allocate 20% of our bandwidth to engineering driven projects). This data, along with a weekly cadence of assessing where all projects are relative to their plan, allows us to continuously prune and re-evaluate our backlog. Adhering to this process results in the backlog being a live document that is continuously — at least weekly — updated to reflect all what we know about the state of the product and therefore helps us minimize waste and ensure that we are continuously working on the most important features for the business.

In the next article we will explore how we actually come up with these pesky delivery estimates and what we do when projects run amok — — they never do 🙂

Stay tuned.