Planning is an important aspect of continuous coding. Many have the misconception that if you are working continuously then planning merges into other processes, but this is a mistake.
There are a few different common ways to do continuous planning. You can do all or some of this, as needed.
There are two scales at which one needs to plan. There is the high level, long term feature plan. This document is not about that. This is about the daily planning that must take place whenever work is to be done.
- Daily Standup
- Regular retrospective
- Iteration planning
- Release planning
- Raising blockers
- “Cost of Delay” prioritization
- Create small behavioral batch sizes
- Preparing for future work
How does this apply to me as a developer?
- Never start working on code until you have a clear plan of action.
- Between every Red/Green phase, refactoring isn't just about removing code duplication or fixing variables names. It's a time to plan and think about where the project is headed. Are we moving in the right direction, or is this going to give us problems later on?
- Every step of the feedback loop is a time to plan and think. The longer we go without feedback, the longer we go without planning. The less we plan, the more mistakes we will make. The more mistakes, the more wasted work.
- Don't confuse planning with knowing what to do. An important part of any plan is how to respond to feedback, and reduce wasted work by planning for feedback as soon as possible.
- Escalate issues that will be more costly (time or money) if they are delayed.
- Prioritize based on optimizing queue throughput.