Philosophy
- On-time and on-budget is a myth, chasing better estimates is a fool's errand.
- Non-blocking Tracks (Delivery + Innovation)
- Complexity Measurement
- The DAG
- The Proposal
- Leftwards Planning is flawed
Foundational Hypotheses
Rationale

Philosophy

Leftwards planning may look similar to other planning frameworks, but the heart of it is not designed to predict when a project will be done or how much it costs. Getting better insights into those topics is a side-effect and not a priority.

The 20% buffer for team capacity is not to protect estimates, it is to make sure people are not over-loaded and work is left waiting. This is an idea from Lean and Theory of Constraints designed to optimize flow through a system, not to error-correct and insulate against bad guesses.

All the ideas in Leftwards Planning are focused on optimizing the way to deliver, not predicting when we will deliver. I can't stress this enough, because I know it will be misunderstood or ignored and eventually used as "a way to do estimates".

Leftwards Planning does this by first trying to remove many of the big items that make projects unpredictable, and secondly focusing on unblocking as much work as possible.

The Proposal section of this framework does contain the possibility for your team to suggest when work will be completed.

On-time and on-budget is a myth, chasing better estimates is a fool's errand.

Professor Bent Flyvbjerg did some very recent research into 16,000 projects of 20 different types from all over the world to find out how often projects fail. Here's the spoilers:

48% of projects finish on-budget. 8.5% of projects finish on-time. 0.5% of projects finish on-budget and on-time, and deliver the expected benefits.

Pretty bad. He was looking at many types of projects (software was just one type).

Somehow, software teams have crafted a bizarro-world for themselves where project owners expect teams developers with a just few years of experience behind them to come up with on-time on-budget estimates for massive, complex, poorly defined projects with lots of unknowns. The problem gets compounded because people who never built something often end up not wanting to understand (not really anyway). They can't approach the details. They don't want to understand why doing something that is easy to state is hard to accomplish and full of unknowns and barriers. They often don't have the facilitation skills to get the reasons from the team and it comes out as a frustrated huff, making everyone miserable. Even when the team does provide "just a guess", the estimates didn't actually help the project move faster. Commonly, it just gives leverage to convince someone they aren't good and are in trouble so they need to work extra hours to make up for being a bad guesser.

Even when the estimates are frequently met, often they are heavily padded and the political story telling was so good that projects appear to be frequently on-time and on-budget. Beware that this is also not a full solution as there is another archetype of project owners who get angry with this. They believe goals should never be met and that teams meeting targets should be rare. There really are directors who tell their managers "You need to push them so hard that they cry". This might be shocking to read and maybe you don't think this is your team, but these things happen commonly enough in our industry that they are absolutely part of the "average" experience.

A lot of this highly counter-productive dysfunctional "process" around estimates is why we have #NoEstimates trending in tech. Not 100% why, but for sure a strong reason why.

The project estimates will almost always be wrong. If we want better outcomes we need actions that lead us there to a better outcome. Putting on the "I'm disappointed" song and dance with the delivery team and brow-beating them to deliver better estimates is one of the furthest things you could do from actions that help the team deliver.Leftwards Planning focuses on actions to take to help remove risks and set up optimal project plans. Higher predictability is a side-effect of it, not a goal.

Leftwards Planning encourages work getting done quickly, not over-promising that it will get done quickly. It's a tool that helps the pragmatic, not a tool that makes promises.

Non-blocking Tracks (Delivery + Innovation)

Rationale behind this is still being written

Complexity Measurement

Estimating the size of any task is traditionally quite challenging and estimators often fall back on "gut feeling" in the best case, or hoping to find an analogous task they completed in the past to "bench mark" the task. Both approaches are flawed somewhat useful and flawed at the same time, but usually they end up being used for finding a time to expect a task is "done".

When estimators have buckets for their initial thoughts on a task, it is much easier to sort out how to refine a task into smaller topics. If there is high effort, look for the repeated components, or an enablement task to pull out of it. If the task has high complexity or discovery work, that task should be designed to start with no blockers and integrate into the project as late as possible to give a lot of time towards solving it.

In Leftwards Planning, the purpose of estimating a size is to constantly refine subtasks until it until it is a small so we can improve the plan clarity, find unknown assumptions, and find ways to optimize the plan. We aren't doing this for the purposes of playing some tragic high-stakes guessing game. While you can have large and medium tickets in Leftwards Planning, they should make up a tiny minority of your project. As a rough rule, the ideal is 100% small, acceptable is 80% small, and if you have 50% small you are probably blocked by cultural way-of-working topics where everyone gravitates towards monolithic tasks and struggles to see value in even identifying (forget doing) small units of work. Estimates for the entire project are handled differently (Explained in 'The DAG') and it should not be estimated the same way tasks are.

The DAG

Often when breaking a big tasks up into small steps, planners traditionally think "rightwards", thinking of the start of the project and messily skipping backwards and forwards until they feel they covered enough points. What we often see (and want to avoid) is a project plan that is more of a "todo list" which can contain a lot of wasted work, assumptions that were not thought through, missing steps, missing dependencies and resources, even private agendas get injected easily when "rightwards planning".

Going Leftwards and associating tasks strictly by what they unlock prevents scope creep by focusing the mind on converging by asking "What is required to unblock this?" (and not diverging, "What else might I want to do in this project?").

The Proposal

Rationale behind this is still being written.

Leftwards Planning is flawed

There's a lot of stuff Leftwards Planning doesn't do perfectly, it is not a panacea, and might not be a fit for every team, culture, or project.

Here's some known flaws or arguments against the methodology with some short insight into why you might want to use it anyway. Up to you if you and your team if you agree with these points and trade-offs.

  1. It assumes the smallest task worth discussing is a "small". There are things that need to be done which could be broken out as "extra small" or smaller, and some extra small tasks will be misidentified as small because of this. This is however intentional and helps introduce some slack into the overall project, but something you should keep an eye out for when breaking down tasks.
  2. It doesn't give perfect clarity on when some sub-task will be done. This is also intentional as fixed dates create a culture of "sticking to a plan" instead of "adapting to change". Having these fixed dates are often not useful outside of the team, with nobody really receiving value until the final task is completed.
  3. It doesn't work well for 6 month roadmaps. Elements of Leftwards Planning like The Dag can support you with things like that, but the entire concept of Leftwards Planning itself is focused on the delivery of one well defined scope quickly in a few days or weeks. Also, whether you use Leftwards Planning or not, any 6 month roadmap should be made of business outcomes, not a massive set of tasks to do or features to ship.
  4. It doesn't make sure that everyone is working on something at all times, but instead that what can be worked on is being worked on. Leftwards Planning aims to get projects done in the shortest time and aims for high throughput, which means that we don't aim to fill up developers with tasks but instead aim to have all possible tasks in progress. It is actually a very bad idea to have people at "100% utilization", and in fact that creates a bottleneck which prevents things getting done quickly as per the last 50+ years of research over multiple topics have shown us. (For starters, look up: Theory of Constraints, Lean, Little's Law).
  5. Leftwards Planning does not fit well for projects that couple delivery with highly innovative work with many unknowns. It assumes what is being built draws on pre-agreed standards (either written or "that's how we always do it" status-quo) and only a small amount of narrowly scoped and de-risked unknowns. Innovative discovery is considered medium-to-high complexity and if your project contains more than 20% tasks like that, this methodology is unlikely to help you reach the stated benefits of Leftwards Planning. The right way to handle it in Leftwards Planning is to deliver what is already known and use the two non-blocking tracks (Delivery + Innovation) to build standards and proposals. The innovation track does not have a DAG or require that tasks are small.
  6. You will probably not think of every task in advance, so the initial plan can never be perfect. This is also true for any form of planning, not just Leftwards Planning. The methodology minimizes this problem in a few ways. First, we design our plan "leftward" to converge on concrete requirements to complete a project (convergent thinking) instead of "rightward" which opens our mind to endless possibilities and options to add stuff to a project (divergent thinking). Second, we aim to minimize assumptions by making all tasks small, so there is a lot less hand-waving or glossing over details which come up as a big surprise later on. Third, there is a big focus on de-risking things by setting up the DAG in a way that risky tasks have time to catch up if they fall behind. Fourth, we move spontaneous "hey I want to try this" into the Innovation track instead of the delivery track. Fifth, because we focus on dependencies of a single outcome we make it very hard to introduce scope creep into the plan. Despite all of this, we can even still have an incorrect plan for many other reasons. In this event, the right thing to do is to step back with your team and re-plan leftwards from the final task and go as far back as needed (but don't include tasks that have already been completed, just things that need to be done), re-build the proposal and have an honest and transparent conversation with stakeholders about what the incorrect assumptions were, what the plan change looks like, and what that means for them.

Foundational Hypotheses

To help you understand why things are the way they are in Leftwards Planning, here are some of the foundational hypothesis that lead to this exact design.