A Planning Approach To Speed Up Development and Reduce Defects
or How to Plan Better
Retrospectives are great for identifying where things went wrong and then coming to the brilliant conclusion that the team needs to ‘plan better’.
This article is what ‘plan better’ means.
Each member of the team should go through the following two steps individually before the first planning session.
1. Step through methods around where the new feature will exist to get familiar with the code, see how data is moving, and identify entry points.
2. Sketch a map of how the different parts interact.
Phase 1: Find the Problems
This phase is for identifying problems to solve, NOT solving them. I can’t stress enough how important it is not to mix the two processes in order to benefit from the planning sessions.
Seriously, do not solve the problems you find at this point.
Start by listing what needs to exist and any refactoring that will need to take place. This is your list of what needs to happen, your problem list.
This is not a list of well defined services, modules, or components. It could be state alterations, data movement, alterations to current logic, etc.
When the team starts debating something that doesn’t have an immediate path forward (and you will), congratulations, you found a Big Problem. Mark it for phase two and move on. Moving on is arguably the most difficult part.
By the end of this phase your team should have a bullet list of ‘things that need to exist or happen’. Nothing more. If you have more detail than that you’ve already ruined Christmas, go home.
Phase 2: Solve the Problems
Phase 2 often has two parts: one for working out the Big Problems, and one for working out smaller problems. It can even be a good idea to have a separate planning session for each Big Problem.
Work through your list of problems one by one. Identify different approaches to the problem and discuss. Choose a solution for the problem and outline what needs to happen to achieve the it, NOT how it will be implemented.
I need to stress how important it is not to go into the how at this point. If you do, you will only negate the benefits of the process.
By the end of this phase you should have an idea of what needs to be done to solve each problem, but not the exact how.
Phase 3: Create the Road-map
This phase is for working out the hows and reducing your unknowns to small enough pieces that everyone feels comfortable tackling them on their own.
Flesh out and amend the list with more detailed implementation. Maybe those ‘things that need to exist’ start becoming components, modules, models, and services.
You should start to see things that can be thrown out, merged, or otherwise simplified. This is the real programming right here, before you ever write a line of code.
Create a UML diagram if you feel like it. Make sure everyone on the team has a plan forward and an entry point for their development.
From here stories can be created or amended by the BA and the team can pull from a workable backlog.
As engineers we go straight to problem solving mode — professionally and personally. We need answers and if we see a path forward it’s hard not to jump straight at it and start working it out. We feel compelled to immediately follow things to their logical conclusion and find it nearly impossible to just let things go. We’re thinkers.
And all that sounds nice, but it’s really just a self-aggrandizing way to view our lack discipline and poor self-control. In reality we’re just shit at doing things with a structured approach.
Because it’s easier to jump right in and start hacking away. It’s more fun to get knee deep in a design problem and start trying solutions as they come up.
But this is also why we find ourselves pigeonholed due to a decision ten steps back. Or realize we’ve introduced a race condition. Or we’ve ended up with nasty branching logic, null checking, and flags everywhere.
Sound familiar? Those are all symptoms of unstructured and ill disciplined planning. So plan better.