Leftwards Planning
Summary
Leftwards Planning is an easy-to-learn and powerful planning methodology for teams that value short iterations with a defined deliverable. It offers techniques to correctly staff a project, prevent over-loading a team with more work than possible (mitigating burnout), reach true transparency, helps explore find multiple options for how to organize tasks and people to get the work done under multiple constraints, and also shows you ways to build safety into the project plan with the flexibility to protect deadlines and estimates when surprises come up. Ultimately, Leftwards Planning is a pragmatic way to get your incremental deliveries out faster and safer.
Who this page is for
- Managers of software teams who want their teams to deliver faster
- Software developers responsible for managing a project
- CTOs/Director-of-Eng/VP-Eng/Head-of-Eng looking to get more outcomes sooner from their teams
How is Leftwards Planning different?
- Actions over estimates: It puts a focus on actions to take that make things move faster and reducing risk, not adding more ways to estimate tasks
- Teamwork first: Planning is meant to be done together as a team instead of by one person on their own.
- Small batches: Projects are biased towards many small projects instead of one large complicated year-long project.
- Intuitive: Once you get into the flow of things, you don't need to stop and do complex calculations, use special software, or get a special certification to use it the right way.
How it works
Overview
Leftwards Planning has 4 components:
- A project dependency graph
- A set of tools to form reasonable predictions about progress, make trade-offs, and minimize high-risk situations
- An agreement that allows technical innovation without delaying projects
- Tooling agnostic
Non-blocking Tracks (Delivery + Innovation)
Leftwards Planning teams run two parallel tracks at the same time: delivery and technical innovation. It encourages a balance; ongoing projects aren't jeopardized by innovations, and future projects are not stifled by a lack of innovation. Innovation happens at any time, but it is not part of a project. Accepted new ideas are moved into the team's Standards & Conventions which gets used in future projects instead of blocking the existing project with extra discovery scope and risk of failure. This approach allows space for creativity without risking project deadlines and supports a culture of constant improvement. The majority of this methodology focuses on making delivery work really well, the Innovation track is left up to your team to find the right process. It also promotes better, more consistent code as the code base will not be littered with thousands of small obsolete experiments, but rather things from a common set of agreed standards.
The DAG (Directed Acyclic Graph)
The DAG visualizes tasks and dependencies from the project end goal (the right side of the diagram) back to the beginning (the left side). This 'leftward' flow is where our methodology gets its name. The DAG aids in identifying which tasks depend on others and helps plan the sequence of work to not only prevent delays, but give planners the foundations to speed up a project and remove risk. Think of the DAG as your tactical operational overview for your project. Everyone on your team should be able to see it, and changes should be made collaboratively. Planning needs to include everyone working on the project.
Complexity Measurement
To ensure tasks are broken down to manageable sizes or de-risked as much as possible we measure task size based on effort, complexity, and unknowns. Tasks get a size of "small, medium, or large". Medium and large tasks are constantly broken into smaller ones to improve clarity, identify hidden assumptions, and optimize the plan. Tasks that truly cannot be broken down are de-risked in the DAG as much as possible. At-least 80% of tasks or more should be small before moving forward with a project. The people who are working on the tasks should be the ones to estimate size.
There are multiple tools and techniques to help re-structure a DAG to make projects run faster with less overall risk, and also improve transparency. See the DeepDive page for more details.
The Proposal
The Proposal is where all the planning comes together. Here, project estimates, timelines, and resources are laid out. The Proposal includes best and worst-case timelines, recognizes external dependencies, and notes areas of project risk (and how it is mitigated). It provides a comprehensive view of the planning process and allows teams to upfront address possible issues, ensuring a smooth execution. In addition to this, it also is the final gate to make sure your team is not over-committed to take on more work than they can handle, and things outside the project are taken into consideration too.
Where can I learn more?
The DeepDive page contains detailed information about how to implement the methodology, the reasoning behind it, advanced topics, and traps to avoid.
What Leftwards Planning is NOT
Leftwards Planning is best applied in project planning for one iteration where the end deliverable is well identified and there is only a small amount of innovation needed. Leftwards planning is only designed for planning the very concrete delivery of tasks as quickly as possible in a sustainable way with the least project risk. It works on the tactical level, not the strategic.
It is not designed to be:
- A way to ideate, innovate, and find new solutions as part of a project
- A way to research new things
- A goal setting framework
- A way to measure performance
- A long-term planning framework over multiple iterations
- A product roadmap framework or product strategy
- A process for change management
- A process to manage meetings or how teams and team members communicate
- A performance evaluation framework
- A replacement for "Doing Agile"
- A personal work/time management tool
- A retrospective on how the project went after it was delivered
- A way to handle emergencies and outages
- A way to schedule meetings
- A way to organize ad hoc work outside of a project delivery (like answering emails, status reports, etc)
Leftwards Planning may be compatible with some existing frameworks for those topics, and elements of Leftwards Planning could be useful in some contents for some of these topics too. Regardless, it was not designed with those tasks in mind and there are many ways things could go wrong when applied to those topics without a new nuanced and focused approach to them.
Feel free to experiment with new ideas or making those things work, just know that you'll be doing things not described in the manual. If you find something that does work, give it a new name and write about it!