FAQ

What about CCPM, CPM, PERT, etc?

These are all good planning techniques (depending on who you ask) for different purposes. One of the main challenges in using them in tech teams is they are often too heavy with too many rules (similar to how UML diagrams often don't "truly" get used by teams in startups).

A lot of ideas from Critical Chain Project Management are re-imagined in Leftwards Planning, but there's a lot of new stuff in here, and a lot of stuff that's been removed too. Enough so that Leftwards Planning is its own methodology.

Leftwards Planning is focused on taking the most powerful ideas form many of those frameworks and turning it into something a small team can plan a quick product iteration in an hour or two. The other methodologies have traditionally been used to manage very large projects (PERT going back to the 1950s to plan construction of a nuclear submarines, well before the Unix epoch).

There are great ideas in those other frameworks you can often opt-into as extensions of Leftwards Planning if your team found it was a valuable thing that solved a concrete problem you had.

A major focus of Leftwards Planning is to give teams the tools to get work done as effectively as possible and share the plan transparently. Building a plan that lets everyone do the best work they can in the best sequence possible is more important than producing estimates about that sequence (being able to do that is considered a side effect or "happy accident" of Leftwards Planning).

What about Kanban, Scrum, Agile, etc?

You can still use them if you want.

Leftwards Planning is not an alternative to any agile methodology. It only helps you figure out how to break up work, sequence it and communicate it. It does not enforce a rule for or against using Kanban boards or backlogs or shipping valuable increments, ceremonies you run, who is on a team, etc.

At the same time, if you have the DAG you probably can use that instead of a Kanban board. Just have stand-up around the DAG instead and use that as your main mode of transparency. Because the tasks are designed to be small, you should not have a lot of problems with tickets being "in QA" for a long time. This does mean your software development process needs to consider the resulting work as a binary "completed or not", instead of in various states of "not totally done yet". This can be an issue for some dev teams working in a silo-heavy environment where tasks are thrown over the wall from one job function to the next. Fixing that is not a topic for project management, but rather a ways-of-working agreement and cultural shift. You may still find that you can use Leftwards Planning in those environments, but the inherent nature of such an environment is that any development task is high risk (regardless of your planning methodology) because you increase inter-team handovers and have longer delivery cycles.

Where do I fit QA and deployments into this?

The DAG tasks should represent shipped and completed work, not things you are doing with the code (writing, testing, reviewing, deploying). Stages in the life-cycle of work can be tracked in another tool, or you could improvise status by putting it onto your DAG as a status badge or label.

Don't represent QA as a task. It needs to be part of a normal task that delivers something.

However, trying to represent status on the DAG exposes the team to the risk of feeling like they can work on things that depend on other tasks that are not actually done and can still change ("in QA" can always come back needing changes). It is therefore important in a Leftwards Planning team to decrease heavy handovers between job functions because teams will end up building on things that either don't exist or are incorrect. The worst case scenario is that a deep dependency ends up causing a change and this will ripple up the entire dependency tree cascading changes into every task that directly and indirectly depended on it.

What about estimates?

Enabling better estimates are a side-effect, not a goal of this methodology. We focus on making same-size small tasks, not converting those tasks to hours of effort. At the same time, we encourage teams to be ready to provide estimates in their proposals when in an environment that constantly asks for them, and pushing back doesn't work (otherwise don't do it).

While this methodology is clearly not "NoEstimates", over time it develops a high level of predictability in the team which is the kind of thing that makes people stop asking a team for estimates.

What about timelines?

The spacing of the tasks from left-to-right is to help show depth of dependencies and what can be stated first. You have a lot of freedom on finding the right way to space out tasks on the diagram. Time is not strictly implied by this spacing but we as humans cannot help but infer time from it. For this reason, it is a best practice to put any ticket that has 0 dependencies on the far left side to make it obvious it could be started "right now", and also help make it obvious how many tasks can be started if this task is completed (helping you pick priority).

What is a "Directed Acyclic Graph" (DAG)?

The DAG is a term from computer science. DAGs are a collection of nodes (we call them tasks) and edges (we call them arrows, and we limit them to dependency arrows exclusively). Nodes and edges when networked together are called a "graph". The graph is said to be "Directed" when the edges point in one direction. Finally, it is Acyclical when those edges do not create any "loops" where arrows point in a circle infinitely.

In Leftwards Planning, our DAG has a few extra rules such as arrows being limited to dependencies only, and the requirement that there is one single "root node" that all dependencies grow out of (the final task on the far right).

Can we mob/team/ensemble program?

Sure! If you want to have multiple people working on one task, you can. However, in practice this probably only helps the team for tasks along the heaviest path or tasks that are medium/large. Because everything is biased to small tasks and projects are built on pre-agreed standards/contentions the value from working together on every small task drops off quickly (a lot of that alignment work has already happened). It can still be useful for on-boarding or team building, or to help align people who see problems differently. Just be sure to take the sharing of a task into account when you build a proposal (if you ask for 4 developers for a small 20 task project, they share all 20 tasks, it will never be done faster than the time it takes to work on all 20 tasks sequentially).

Isn't this just a rip-off of some other idea?

Probably. This idea did not jump out of the forehead of Zeus, fully-formed wearing armour like the Greek myth of Athena's birth.

Leftwards Planning is a collection of many great ideas, modification of those ideas, years of hands-on-experience, and maybe a tiny bit of novel invention.

For example, making projects into a graph is not unique to Leftwards Planning. PERT, CCPM, CPM and others do this. Moving "left" is called Retro-planning, but also backwards planning, reverse planning, reverse gantt, "right to left planning", outcomes-first, and backcasting. All of these are slightly different stand-alone ideas, which have a lot of similarities too. Some of them are modifications of each other, some are all original "multiple discoveries", they possibly even have different inspirations and roots. The ways to work with the DAG and avoid problems is directly stolen from computer science which probably stole it from some other branch of maths which probably stole it from someone's intuitions.

Moreover, Leftwards planning absolutely did not come up with the idea of working on small tasks. You can learn about that in hundreds of books, and tens of thousands of blog posts. Breaking tasks down into smaller tasks is also something that is quite well discussed.

You might recognize one idea as being very similar to something you saw before, and it might be the case. It might also be the case that that idea is a neighbouring idea to the one that influenced this methodology, it's too hard to say really.

Leftwards planning is a fine-tuned collection of ideas that are designed to be used together to help development teams plan projects and eliminate a lot of the problems they regularly run into. Some ideas here are not found elsewhere, or ideas found elsewhere are not found here. The exact combination of ideas is the unique artifact. It is also aiming to make these great ideas intuitive, easy to learn, and easy to use for that audience.