I am fascinated about planning, especially in context software development. It is so amazingly difficult topic. This post works as a reference and reminder, rather than absolute truth.
Red flags
Fixed time AND fixed scope (fixed scope is rarely needed in the real world)
Features are planned far into future
"Design" is done ahead of time and separately by someone somewhere
People expecting others to do the planning (the act of planning is seen in negative light, e.g. boring)
The plan (document) is more important than the value and outcome it aims to generate
Description of the planned work (e.g. Kanban board) is more important than the generated value and outcome
Planning has become complicated and requires a lot of time and work
Planning is not transparent and the activity is hidden from others
Change requires paperwork
People working on tasks do not know the next milestone
No feedback loop: is the currently active plan working?
Tasks whose importance, content and purpose is not thoroughly validated are treated and described as they are. (Note: this is very hard to get right!)
More than 3 people are in the exact same work pool
Things are measured only because they are easy to measure (but don't really matter)
Qvantitative measurements are used to analyse aspects of development that are fundamentally qualitative
Organising around the things to do, instead of organising what needs to be achieved
Watermelon reporting: green on the surface, red on the inside
Plan for Outcomes (Long-Term)
Envision how the world would look like when the work is done
Focus on what success looks like, not how to split it into tasks
Set clear, understandable and identifiable outcomes rather than vague descriptions
Keeps teams aligned while allowing flexibility in execution
Plan to Work (Short-Term)
Get into details as late as possible i.e. near execution (e.g. next week)
Break down initiatives into actionable tasks without over-planning
Use iterative feedback to refine execution without losing sight of outcomes
Avoid over-crowding pool of work with too many people. Split responsibilities, even rough division helps structuring work. The split can be technological, functional or something in-between
How to do both (long-term, short-term)
Define long-term goals (e.g. milestones) with measurable success criteria
Maintain a rolling backlog for near-term work
Continuously review and adjust based on progress and feedback
Encourage, expect, promote and demand autonomy of execution and adaptability of the plan, in order to achieve agreed outcomes and milestones