In every project there is always an opportunity to try something new. Unfortunately this artificially introduces a lot of unknowns into the project which puts the delivery at risk. Not innovating also puts all future projects at higher risk by not finding ways to make things in better ways, eventually causing the projects to grind down and become a challenge as complexity scales and new challenges are introduced.

The solution in Leftwards Planning is to run two tracks in your team:

Delivery
Technical Innovation

Example of two non-blocking tracks (view image)

Your teams will work in track 2 to build a deeper and richer set of shared agreements, standards and common conventions on how things are built. In track 1, they use those conventions. This makes space for innovation without putting any given project at risk.

A common challenge for teams is that they have no pre-existing standards of any sort, and sometimes standards change regularly based on the opinions of people with more senior positions in the team. In Leftwards Planning this is no longer sustainable, so teams must regularly meet to discuss what the standard approach to writing software on your team is. This can be done easily with a list of proposals to add to the standards and a weekly call to debate the changes and add them to the team standards.

It is also worth doing a check for what common undocumented practices the teams already uses. For example, if the team always uses one specific framework it should be accepted as a fact that doesn't need to be debated. However, changing it is also open for debate with a good proposal.

Innovation track ideas should not be wedged into delivery projects until they have passed a level of certainty that they will not introduce major risk into the project itself, but also not introduce major risk into the technical portfolio of how many things the team needs to maintain over the long term.

How to propose new ideas

Teams should reserve a few hours to come up with new proposals. It is up to the team how to arrange this time (weekly, monthly, fixed days, etc). Team members need to get in the habit of creating proposals. Not everyone needs to propose something new every week, but never making a proposal is also wrong.

Proposals can come from one person, but they can be even better when more than one person worked on it.

Proposals should be in response to something concrete that will improve the project. There should not be any "try Kafka just for fun (or to put it on my Resume/CV)" or "I used it at my last job", but really propose it in response to a problem or opportunity, "We know that we need to 10x the data we handle next month", "We have regular issues with tightly coupled systems", etc.

Proposals should be defined enough that there is low ambiguity about what will be introduced. RFCs can sometimes support this, but the quality of the RFC and how your team interacts with them can be a second large hurdle to overcome. If the idea is very simple ("We add this linter"), a simple one-liner, or a short 5-10 minute discussion is probably enough. Do not use a one-size-fits-all approach for all proposals, but do use a format that provides the right amount of detail based on the size of proposal, and context the team is in.

Prototypes can be a great way to show an idea, but be careful: if developers are putting the delivery project on-hold so they can experiment with an idea, they did it wrong. The existing project should move without being blocked by experiments and new proposals, it only uses things that have been agreed on. Blocking delivery to have debates about standards is a worst-practice. You can make a prototype, but also deliver the project without it.

How to debate changes to the standards

It is up to each team to find a good process for regularly debating standards and changing them.

A recommended process is to regularly meet for 1 hour each week and walk through a list of proposals ranked by near-term importance. In this meeting, proposals are given an explanation by the authors, and the team decides if they will enter it into the standards or raise their concerns with it. It is the job of the team to help transform a proposal into something that moves the team forward. A common trap with these types of meetings is to either accept everything or block everything, and neither of those are good. The meeting should have a facilitator who constantly polices that the teams are in a generative problem-solving and discovery/curiosity mindset first and foremost, and only use the blocking mindset after trying to help move an idea forward somehow.

If you don't already have a good tool for debating and tracking changes, here's a simple google sheet you can start using right away to launch this meeting. A google sheet (Get the Google Sheet here)

This process described above is not the only way teams can debate standards, but it has worked before in multiple companies with multiple teams.

How to accept new standards

You should keep a record of decisions. There are tools that help you keep track of decision records, but also just writing down a decision next to the proposal in a spread sheet can also be fine. Your team should agree on how you log decision records and stick to it.

A common issue for teams is that their decision records do not get converted into a simplified understanding, forcing people to sift through years of records and try to build up the most recent and most accurate version 100% virtually in their brain. You can't scale in time or in people like that. Your team should have a set of documents that explains the presently accepted standards.

Here's a proposed format for this to bucket documents in 3 groups: Conventions (how we do things; example: "use a facade here"), concepts (important to know topics that are specific to this team; example: "We use CRDTs for document change updates"), and practices (how to go about doing different duties/tasks; example: "When there is an outage, everyone stops their tasks and leaves their calls to help out"). Once a new convention is agreed on, the authors of the proposal must update the existing documentation to ensure the standards reflect the agreement. Also, if it deprecates old standards, the team needs to understand it has officially deprecated the former style, so all of that work is potentially "tech debt" and needs to get updated.

What if the change is really really small?

That's great! The majority of proposals should be small. Big ones are fine, but they should be less frequent.

If your team had something like simple like "let's use this new linter" and everyone agrees, and it only takes a short amount of time to add, you still must move it to the standards first and add it later on without adding scope to the existing on-going project. Don't skip this process, it's there to prevent projects from "death by 1000 paper cuts", or in this case "1000 great but out-of-scope ideas".

When conventions get in the way

You might be working on a project where your typical development framework doesn't make any sense (for example: you always wrote back-end API servers in NestJS, now you have to write a front-end project, using React or Vue would make infinitely more sense). Leftwards Planning is not an excuse to avoid doing the right thing and using common sense. You have to be really careful however, because hype, hidden agendas, political power in your teams, or any number of motivators can trick you into thinking you need to do something that the standards don't cover. In general, going beyond the standards must always be in response to a legitimate constraint.

Secondly, if something isn't covered by the standards (written or the common undocumented practice) it is fair game. If someone joins a project and writes unit tests in a way you don't like (but are not going against any clearly established pre-existing way) it is fine for them to do this. It should also trigger a debate in the innovation track about what the right way to write tests are, because that would block a project to try and introduce new standards. We don't block work based on personal preference. Again be careful, someone may be really passionate that only their way is the one true/correct way to get the job done. In the majority of cases, there are multiple valid and good ways to get the job done. Not having a healthy debate rooted in real constraints just pushes out reasoning and feeds egos, misunderstanding, and mistrust in your team mates. Always defer to conventions, but be pragmatic enough to know when the intentions of the conventions didn't apply to some new situation. You will always have a tiny bit of mess, but it will be controlled and understood.

Core Concept: Complexity Measurement

We measure complexity in terms of "small, medium, large". Everyone that will be working on this project should be included in figuring out how complex the tasks are. Picking sizes should be done individually per task, but you can wait until after the first pass at creating "The DAG" (another Leftwards Planning core concept). You will likely need to take multiple passes over the diagram to reach a good state.

There are 3 measures of size for any task: Effort, Complexity, and Unknowns. Tasks that are considered medium or large because they are composed of more small tasks need to be broken down until they are at-least small. There is no need to go smaller than small. While it is possible to do a comprehensive evaluation, picking the size should really be a fast activity to understand if the topic is small or needs attention to break it down or remove risks. Remember: our goal here is to optimize the project, not guess at when it will be done.

All tasks could be measured on all 3 criteria, but generally speaking it is not worth the discussion when the task is already agreed to be of a specific size and reason, such as "medium effort" or "large complexity" or "medium unknowns". Opening up the discussion to find out which of these 3 topics make it medium or large is only meant to further assist breaking tasks down towards small tasks again. We don't need to discuss why a small is a small unless some members of the team are unsure about that choice; challenging assumptions is healthy, but having discussions that won't add value is not.

Not every task can be broken down, but a serious effort should always be made. If your plan is less than 80% small tasks, go back and re-think how to break the tasks down further. If it is really impossible to break something down, special care must be taken in "The DAG" and "The Proposal" to de-risk it.

We do not use these estimates to fix dates that tasks are completed, and that's not just a nice to have statement but actually part of what makes Leftwards Planning work. If you start to attach dates to any task except the final right-most task, you will undermine the design of this framework and not get the results you expected. Individual task dates are not fixed and the team can agree to change the order of tasks as new information becomes available while working in the project. You need this level of freedom to deal with unpredictability. For a deeper explanation, please review the "Rationale" section.

Explainer for how to work with task complexity (view image)

Breaking tasks down

Often tasks can be broken up many times over. It doesn't always make sense to do this when a task is already small. However, if it can unblock a second task or splitting allows more than 1 person to take on this task, it is often worth it. Especially when you have a working CI/CD pipeline and can gain instant validation on that increment being built correctly.

Splitting repetitive high-effort tasks can be relatively straight forward, simply break the repetitive part out into many tasks (re-bucket them as appropriate).

High-effort tasks that have workflow steps can often be broken into the workflow "skeleton" to unblock multiple "steps" components, where the "steps" plug into the "skeleton". Furthermore, workflows often have logical branches which can be broken up (for example, imagine an on-boarding wizard, it might have different forms for different users, but also it has different workflows for the "happy path" and "form validation failed" which could be broken up too). Likewise, the same goes for variations in data: usually you can solve one case per data type.

Tasks can be large when they are either very complex or require discovery (for example, high-performance software). Often it is possible to deliver the low-performance variant quickly and allow a longer non-blocking time window to work on this complicated performance challenge using some techniques from the Sacrificial Architecture section.

Estimate types

Estimating Effort

Evaluating the amount of raw input work needed, not thinking about the problem solving side. Imagine implementing 1 CRUD API endpoint vs 100 CRUD API endpoints.

Estimating Problem Complexity

A measure of how much thinking and problem solving needs to go into the work. Imagine writing a direct key-value lookup vs writing and fine-tuning a fuzzy search algorithm.

Estimating Unknowns & Discovery Work

Describes the level of knowledge acquisition work that this task includes. Imagine needing to talk to a customer to figure out what to build, or learning a new framework instead of using a well-known one.

This one has an inherent risk linked to a team's skill level at any task, as well as their domain knowledge, and the context the team operates in. Imagine a team of new hires who all worked at fast-paced startups where teams owned infrastructure with IoC and a full CD pipeline, deploying multiple times per day. Now those developers just started working at a new company where they need to get a golden seal of approval from the head of Platform and a 3 month regression cycle. The team estimates that getting into prod is a "small". That's a huge hidden assumption, which ended up being wrong, just due to change in their environment. You will have many of these risks and your team must grow their awareness of what they know they don't know to overcome it and reduce this risk.

What if the estimated sizes were wrong?

Some of them will be.

You need to regroup as a team and correct the tasks on the DAG. This will probably happen to you enough that your team should feel comfortable doing this. There are techniques in The DAG and The Proposal to help you mitigate this problem, but this is ultimately something that gets improved by building the team's shared awareness of task size and what they know they don't know. Leftwards Planning does not describe how your team should go and learn those things, but repeating the planning process with the whole team participating will support that growth. Your team should especially do this so they can converge on fully agreeing when a small is a small.

Core Concept: The DAG

To create a DAG we always start with the end goal on the far right side of the diagram and move leftwards from there. Arrows point left towards other tasks or sub-tasks that must be completed for right-side ticket to become unblocked. This constant flow to the left is why we call the planning model "Leftwards".

Example of a project DAG (view image)

Warning: Teams that Leftwards Plan spend a lot of time looking at The DAG. It is all too easy to forget about the other important topics in Leftwards Planning (non-blocking tracks, complexity measurements, and building a project proposal) because they are less visual than The DAG, and you interact with them less frequently too. Be careful not to exclude them from your planning work. Picking task size should be done while planning the DAG. Enforcing that the way things are done comes from the standards (Non-blocking Tracks) should also be done while designing the DAG. Writing the proposal usually happens after the team agrees to what is on the DAG.

DAG Tasks

There is one (and only one) root node that all other task "grow out of": the right-most final task. All other Tasks must always be concrete deliverables that unblock something else that depends on it. For example, "Complete validation logic" is fine, but "do code reviews", "get customer feedback" or "do QA on that thing", or "fix bugs" is not. Those items should come from your ways of working and typical development process. In other words, if you need customer feedback, QA, or bug fixing, it should not be a task in the same way "use my laptop to write code" is not a task, it's just part of how you get the job done. Now, don't take that as a doorway sneak in a bunch of unrelated work ("I always wanted to fix this pre-existing bug, so I'll do it in this unrelated task"), because you'll undermine the entire planning process, estimates, and non-blocking track concepts; such a behaviour is like money laundering but instead of money, it's for work getting done.

Avoid the urge to group tasks together into a bigger task. This is something we specifically try to avoid doing in Leftwards Planning because it reduces overall ability to manage a project.

Tasks must be strictly required by their dependent. If a task is "nice to have" or "would make things easier if", it is not a strict dependency and should not receive an arrow. There should be exactly 0 "free floating" tasks in your DAG. If it's not depended on by the final task, it's not part of the project.

(view image)

There is only one task that all other tasks come from: the right-most task. Do not create tasks that are free-floating or do not result in the final task being un-blocked. If you have tasks that do not contribute directly to the final task, they do not belong in the project, they belong in some other project as they serve some other completed task.

(view image)

Tasks do not have pre-planned delivery dates. They are only sized by type of complexity. Only the entire project can have an estimated completion date when submitting the project proposal. Pre-planning when the sub tasks will be done and by who is popular in other planning frameworks, but Leftwards Planning assumes that so much can change while a project is in progress that these specific deadlines are counterproductive and creates a culture of rigid "sticking to a plan" instead of allowing the team to "respond to change". Leftwards Planning is about taking actions to keep things moving effectively, not expressing disappointment when guesses about delivery are wrong. If you need to express disappointment; you can express disappointment in some other way if you feel that is the thing that needs to happen at that moment in time with your team.

You may discover that part way through a project all the tasks are wrong and need to be re-created. If this happens, start over and create a new DAG with your new best understanding of tasks and dependencies. If the expectation of when the project can be delivered has changed significantly it needs to be communicated to everyone that needs to know. If you have new team-external dependencies, those need to be communicated immediately.

We should not ask team members to estimate the percentage of a task they have completed while it is in progress, this only provides the illusion of comfort and control without actually improving the situation for the entire project. A more direct and involved approach should be taken to help unblock, break down, and keep tasks moving forward. Knowing a task "feels like it is 60% done" can't help you actually unblock or ship faster. It's just a weird anxiety reducing ceremony that has no concrete impact on actual delivery.

Lastly, there is no multitasking with this methodology. If someone is working on a task they must not pick up a second task at the same time. This anti-pattern ends up blocking someone else from working on a ticket and slows down the total delivery time of the first (and second) task. You must convince your teams there are no "two for one" deals in Leftwards Planning projects. If there is a blocker, it might be better to have the next free person start pair-programming with the blocked person instead.

DAG Arrows

There is only one meaning for an arrow: dependency. There are no "flow" arrows or any other sort of arrows. If you see an arrow, it points at something that must be completed before the box it comes from can be started. So, if something starts and it's dependency is not done, pull the team together and fix The DAG to explain what is going on. It could be that someone is doing the wrong thing, or it could be that there was a smaller task that wasn't broken out and just needs to be reflected in The DAG.

Dependencies may indicate internal or external team dependencies. For external dependencies highlight that task as high risk so you can focus on de-risking the dependency in your own project. It is helpful to highlight external team dependencies with another colour or special symbol in your DAG diagram.

(view image)

You must never start working on a task that depends on incomplete tasks as it introduces high risk of failure, or indicates that there were hidden tasks inside the dependency task that were not broken out into smaller tasks (which also results in many additional planning problems).

(view image)

Arrows must never create loops in your dependency graph. It is impossible to complete a circular dependency. If you run into this problem, there is likely two tasks hidden in one.

(view image)

Calculations

There are many ways to use a DAG to calculate different metrics that give you a hint at where problems can come up in a project.

Converting sizes to small

Much of Leftwards Planning assumes that tasks are small, so to simplify calculations we convert everything to small. We do this to understand path weight, not when the task will be done.

When medium and large tasks come up in plans it is up to your team to agree how many smalls they expect "medium" in general to represent (2? 4?). Typically a medium sized at 2 smalls and a large size equal to 4 smalls works well, but this is only a suggestion and your team must agree on what size conversion to pick. Size conversions must always be consistent, so we can't have some tickets where an M is 2 smalls, and others where an M is 4 smalls. It must always be the same conversion (per project).

The importance of sizes is really just to guide the team and understanding how risky or how much more breakdown work is needed.

(view image)

Total Size

Total size tells you how quickly a project can be completed if only one person was working alone on the entire thing (assuming they do not need external support for special skills). This measurement tells you what the workload for an "ideal" person with all the skills would be.

This value gives you a reasonable upper-end idea for how long a project might take if there was only one person available.

To compute it, simply sum all tasks. If you have 10 small tasks and 2 mediums, (and we assume 2 mediums = 4smalls) your project is 14 small tickets. To calculate the total size you simply add together what you have.

Heaviest path

The heaviest path can give you a good idea about the absolute shortest time it takes to complete a project assuming there are enough people available to work on the project.

The heaviest path is the one with the largest sum of tasks along one walk through the dependency arrows. You may have multiple paths that are equally heavy, which is also fine, just include the both of them as "Heaviest paths". The path will change regularly through your project; as tasks get completed, a new heaviest path can form somewhere else, possibly on entirely different tasks. That means it is important to constantly re-evaluate where it is and verify it again after each delivery on the heaviest path.

Don't include paths that are slightly less heavy in this, it won't help you make decisions or discuss the shortest amount of time a project can take. You only need to find the single heaviest path.

(view image)

Task Block-risk

The more things any single task cumulatively depends on, the higher the risk it has for being blocked. This means the final task at the far right is the highest block-risk task in the project at any time, and the ones to the left only inherit the block-risk of their own dependencies. Ultimately the very left-most tasks have no block-risk as they have no dependencies, they are instantly and always unblocked.

On the other hand, a task that is depended-on by many others should be prioritized such that many tasks can start at the same time.

This means the next ticket priority can be found by looking at the left-most tickets (ones that don't have any dependencies) and computing how many tickets they unblock next.

(view image)

Special Manoeuvres

This is a non-exhaustive list of ways to improve a challenging project plan. These techniques will either remove risk, shorten calendar time, or create more parallel tasks.

Collaboration Catalyst

It may seem counter-intuitive, but often adding a tiny amount of "throw-away" or "interface-only" work can actually shorten the entire project timeline by allowing more people to work in parallel, and validate ideas sooner.

When you see some tasks have many dependencies late in the project it is often due to some "integration" step where all the parts are tied together. Commonly, this can be inverted by isolating one part of that integration task, breaking out an interface (UI or programmatic, both count), or a mock-up, or a bit of "sacrificial architecture" which unblocks multiple other tasks. They may still need to integrate at the end, but overall many people could start work sooner.

(view image)

This might look like:

Providing an API contract or just documentation about what to expect
Shipping a class interface without the class so everyone can program against the expected contract.
Writing a doc that explains how something will work which everyone will program against
Shipping a mock feature that doesn't work but allows other teams to start integrating their code in the right places today, binding to the right parts of the code which will come later.

The more programmatic the Collaboration Catalyst, the fewer unknowns will be introduced for everyone who is unblocked. When the Collaboration Catalyst has no common code but is just an idea, it has greater chance of being misunderstood.

Often using this strategy means there is still one task that blocks everything else, but generally this is acceptable given the overall state of the project is improved (tasks are unblocked faster and can be be started sooner, and in parallel). These Collaboration Catalyst tasks should be as small as possible, something you can complete in a few hours, not days or weeks.

A second trade-off is that any mistakes at this early stage can cause re-work at later stages, but it can also be contained in most cases through good programming techniques. In general your project will still be in better shape (your worst-case is going to be faster than the best-case of not using a Collaboration Catalyst), but you might accidentally set yourself up to over-promise and under-deliver due to your now shortened total project timeline if you end up not taking this risk into account when providing a project proposal.

Pair program

Any delay on the heaviest path in your project will delay the fastest possible delivery time. Assigning developers to pair program on all the tasks in "the heaviest path" allows for redundancy when someone on the heaviest path is suddenly unavailable (for example, they're sick), and this also helps keep things unblocked as there are two people working on solving all the issues.

It can be hard to cultivate a pair programming culture if your team has never done this before. If that's your team, please consider this as a capability your team needs to build over many months and will not be good at right away. Maybe start small with low-risk projects. Consider assigning people to pair program outside of the critical path just so they can develop those skills somewhere less risky than the heaviest path.

The people working on the heaviest path can be changed. While having two fixed developers working on the path is not wrong, it may lead to situations where the critical path is not moving as they're busy with a different task.It is also possible to assign one fixed person and have one constantly changing, or even two constantly changing developers. You will need to use your best judgement given your team's skill, culture, and the specific situation to decide. Ask your team what they think too.

You don't always need to pair program on the heaviest path, especially if the heaviest path is quite short and you have a project proposal that can deal with setbacks. Typically a project made of many small tasks might not have any common topic from task-to-task either, and if they're small the setback could be one day before a new person is assigned to take over the work. You will need to judge the risk based on the size of the path and the size of any given task. Typically the larger the task (especially if it is on the heaviest path) the more it can make sense to pair program on that topic.

Be aware that the heaviest path is not fixed over the lifetime of a project, and it will change as tasks are completed. You will need to re-calculate it after each delivery on the heaviest path to find it again, as it could have easily shifted to a different set of tasks.

Flattening the DAG

A very desirable project plan will be "tall" instead of "long"; lots of things can be worked on at the same time, and the longest path in the project is very short. Aim to use the other maneuvers mentioned above to reach an end state where you have minimal long-sequences of tasks and many short trees of dependencies. This will give you maximum freedom to change what is built and in what order as a project progresses. This means when something unexpected happens you can defer some tasks while asking for more discovery or research, and pivot your team back to focusing on delivering a better understood problem. This allows you to bring people into the project in ad hoc ways to support you too.

(view image)

You can't always flatten a long DAG, but this is a cross-disciplinary skill that you can get better at in many ways including: making your architecture enable it, getting standards that enable it, a culture that supports it, and making sure there is no single skill-bottleneck in the team. Always try to shorten the DAG and look for ways it could be done. Do however evaluate if the DAG really needs to be shorter or not. Often a heaviest path of 3 smalls is really small, trying to going lower than this should trigger some healthy questions. Note: 3 tasks is not a goal for short DAGs, simply the lower-end of what is reasonable. You should still decide and discuss prospectively and retrospectively with your team.

Focus on verifiable work

Sometimes too-few people assigned to big projects so it is too hard to move quickly. In these cases, focus on a subset of the DAG that can be verified in some way to help allow projects to find issues earlier. This can be done by finding the deliverable task that helps validate/invalidate assumptions about customers, process, design, or technology.

(view image)

Job-specific tasks

Often teams will break responsibilities up to some sort of specialization such as "backend" or "frontend", which is different from an environment where anyone can take on any task. This creates a resource-constraint for you which makes planning harder.

A fullstack team might have a pool of 3 developers who can take on the next task at any time, but a team with 1 FE, 1 BE and 1 DevOps person can only work on their own topics which means some tasks that could be started in another specialization cannot be started. It can be even worse than that: the project can get blocked while waiting for a different specialist's task to be started.

You can gain visibility into this by adding lanes to your diagram and adjusting the DAG based on those constraints.

(view image)

There's one major trap for teams made of specialists. Because the project members can have large amounts of "idle" time while waiting for the contribution to be unblocked, they get pulled into other projects to increase the amount of "non-idle time" (% utilization). This means there is a higher chance that when the task that they were waiting on could be started... They can't, because they're working on a different project, so the first project is blocked and everything waits for them. Eventually they get pulled into multiple directions, get stressed out, and either disengage or quit (leaving you with an even tighter bottleneck than before).

The more specialized your teams are, the more "idle time" your individual developers need to have in order to prevent tasks from "waiting" for them to be available. The solution here is to grow the pool of people who can do those bottlenecked job functions to a level high enough that you are no longer constrained here. You can do this without hiring by investing time and effort into training your staff to learn those disciplines (which has other benefits like improved employee retention due to improving the statement "This is a place I can grow!").

Core Concept: The Proposal

The final part of Leftwards Planning is forming a project proposal. Often teams feel they are cornered into just blurting out an estimate using their gut feelings, and often it leads to a bunch of problems like the team being booked at 200% capacity, lack of transparency, lack of highlighting who needs to be involved, and lack of ability to negotiate terms. Meanwhile, external dependencies can get over-looked and under-communicated (and therefore, not ready to help).

The proposal helps you solve problems around expectation setting, cross-team communication, highlighting risks and dependencies, and locking down what is in scope.

Your proposals can take any form but it should include a few things:

What your recommendation is for how many devs are needed and when the expected delivery could be.
External dependencies and requirements
Highlight the riskiest parts of the project plan, mitigation strategy, what you need to make it work

Explainer for project proposals (view image)

Keep in mind that stakeholders who want estimates might need cost estimates (how much will it cost?, how many hours will you invoice?), and time estimates (what day in my calendar will it be done by?) to help organize other projects. It is fully possible you work with people who set estimates for no reason other than they believe they should, in which case you should guide them to a better understanding of how meaningless deadlines demotivate teams and generate extra re-work which extends the time and cost of positive outcomes. "Student Syndrome" should be countered by reasonable fact-informed plans and making it clear what tasks need to be worked on first, not arbitrary haggling over a deadline. "Parkinson's Law" is solved by planning leftwards on The DAG and keeping tasks small. "Healthy tension" is great but when it is genuine and healthy.

Ensure team will not be 100% busy with this project and split over other projects. A common trap is to ignore the base workload a team has just by existing (bugs, meetings, learning, helping each-other, cross-team initiatives, training others, etc). You need that 20% buffer in your team to ensure no task is left waiting. Leftwards Planning is focused on things moving quickly, not on keeping teams stuck in the cost-accounting trap of "everyone at 100% utilization" which enforces bottlenecks and slowdowns, breaking the entire flow. A team at 100% "busy" can often make projects take longer than needed because nobody is around to take on the work when it could be started, leading to "inventory" sitting around waiting generating waste (look up: "Theory of Constraints" and "Lean"). This trap is covered in depth in the works of Eliyahu M. Goldratt.

If you need to give a hard date, convert the smalls into days with agreement from your team, but also take into account the workload your team has (probably only 38% of their time can go to this project). Don't pick due-dates for specific tasks, just for the entire project. Aim to make sure your team is never above 80% workload at any time. Check that your team really kept a 20% buffer on their planning. If your team isn't doing this in their estimates a second-best workaround to this is applying a 30% buffer on the heaviest path (if the heaviest path takes 3 smalls, the project should be estimated as 4).

If your stakeholder is challenging the proposal, invite your stakeholder in to see the DAG and walk them through it, force them to collaborate with you and really understand what is involved. Depending on your culture you may wish to invite the entire team to stand behind their plan.

Deeper Topics

Optional reading that might help you solve problems more effectively or drive conversations inside your team.

Using concepts in isolation

Each concept in Leftwards Planning was grown in isolation and can work on its own to help a team with different and specific challenges, so if you really like one concept feel free to use it.

However...

The four major ideas in Leftwards Planning are designed to support each other in a way that helps a tech team iterate quickly, have better control over their projects, and increase transparency. You may find that using only one or two of the ideas here helps your team but do keep in mind you are not using the full concept in this case and your results will probably be different from the stated benefits of Leftwards Planning methods in aggregate.

At the same time, you might be a team lead who wants to slowly build these concepts into your team and opt to introduce the concepts one-at-a-time. This is also fine, but beware you may create unexpected problems as a result of this -- for example, using the DAG without doing proper proposals can lead to teams planning and breaking work down but not communicating well to your stakeholders and teams you depend on.

Introducing Leftwards Planning in small steps is possible if you can support the team through those problems and identify what wins came from the methodology and what problems came from missing components of it (or missing some alternative solution). Change management is hard (really, really hard), and it might be equally challenging to introduce the entire methodology to your team too. You will need to decide how best to do it based on the skills, culture, mindset, and objectives of your team.

Protect the heaviest path

For projects with tight delivery windows, ensuring the Critical Path is always moving efficiently and unblocked can be supported with a few tweaks to the environment of people working on those tasks:

Remove other meetings. Often people can be involved in many things that are unrelated to the heaviest path. For the time people are on the heaviest path, having them removed from every meeting can free them up and allow them to have guaranteed focus time.
In a physical office setting, set up a no distractions "Path Room" (it could be a meeting room) where nobody goes in except people on the heaviest path. If this isn't possible, consider asking them to work from home if that's a better environment for focus.
Only check slack and emails in the first and last half hour of the day, escalate everything that is important up to the manager.
Clearly communicate to everyone that people who are on the critical path are in this mode of working and expected to not be responsive to anyone.

In general, create an environment that is entirely distraction free from anything except the heaviest path.

Traps

There are many ways that Leftwards Planning can be undermined (intentionally or not) in ways that are not so easy to spot.

Trap: "Reserving" tasks in advance.

In some teams there can often be a culture of developers who want to pre-claim a task for themselves (this is not unique to Leftwards Planning). Allowing tasks to be "reserved" prevents someone who is ready to take it on from actually doing the work, increasing the time the task was left waiting, increasing overall project delay. This reservation behaviour needs to be coached out of the team, or possibly trained to deal with a lack of skill redundancy (ie, only one person knows how to do a task). This behaviour also leads to incorrect sizing because sizes can often be small for someone who reserved it in advance, but when someone else who is unfamiliar with it picks up the task it is large for them. The team should pick the size. Finally, this reservation behaviour can sometimes manifest itself in the planning stage itself when developers try to pack multiple things into one task, which works against the core benefits of Leftwards Planning for reasons explained in depth earlier.

Trap: Running the team at 100% capacity (or higher)

A big part of being able to do leftwards planning correctly is having time for that team innovation. Without it, things rot from the inside out over time. If you have a one-off-team that will never meet again, maybe you don't need it, but that's really the only case.

Additionally, that 20% buffer should be nearly sacred. You need to push back heavily and educate anyone from outside your team telling you to "use that buffer" because they think it is "waste". It is highly counter-intuitive to people who don't understand Theory of Constraints, but it's so simple to explain: if someone is 100% busy, they will almost never be ready to start something that needs to be started quickly. 100% busy optimizes for busy, not for work moving quickly through the system. This is well proven in many domains ranging from DevOps to Queue Theory, even assembly lines in factories and serving tables in a restaurant. A team where everyone is 100% busy (or more) is a team where the total system throughput is ground down to a pathetic trickle. Read "The Goal" by Eliyahu Goldratt to get an easy introduction to this concept.

Trap: Ever-growing buffers

If you discover your team regularly needs 40% buffers or greater, go back to how the individual tasks are sized and broken down. Check that people are working on just the one project and not multiple. Check that scope is not changing constantly. Check that innovation is happening outside of delivery and not blocking progress.

That much of a buffer indicates that the project planning is highly unpredictable. You may have an environment where the team is highly unpredictable (half the team is regularly sick for a week, requirements change mid-project, etc), if that is your case, you cannot fix those problems with a better project plan.

These are cultural issues. You and your management team needs to regroup and acknowledge that the status-quo environment is unsustainable, and no meaningful planning can happen under those conditions. There are ways to improve things, and you can start by hosting a detailed blameless retro to bring all the problems to the surface. Consider having someone who is not a manager facilitate it if you have trouble getting feedback.

Key Contributors shared over multiple projects

This trap is one of the most common for "High Performing" individuals. The simplest answer is that they should only ever work on unblocking "heaviest path" tickets because that will keep the projects delivering quickly. The harder and more long-term correct solution is to have this person work on training and improving the pool of people who can do that special type of work; less doing and more training/coaching/delegating. People who are in this position should be given a lot of room to be "not busy" with tasks outside of the critical path so that they can become instantly available when needed (preventing the project from slowing down). Assigning them to some other task in the project can end up being a risky gamble where that task they started remains "in-progress" for a long time, blocking things that anyone could have taken on and unblocked.

Additionally, when you consider any person is shared on multiple projects, their 38% window of project time is fractured into an even smaller slice. Worse, the overhead cost of context switching drops their ability to contribute effectively.

Trap: Misleading Diagrams

You can position boxes to make DAGs to trick the human eye into thinking they are something they are not.

(view image)