This episode is part of a wider mini-series looking at Estimation in Software Development. In this episode, I want to encourage you to mentally separate estimation and planning. They are often conflated, which leads to confusion, distrust and dysfunctional behavior. An estimate is generally part of a plan, and a plan can be the outcome of the act of planning. Software development can't be delivered without planning, even if it's only the most cursory of activities. Software development can be delivered without an estimate.
Or listen at:
Published: Wed, 18 Dec 2024 01:00:00 GMT
Links
- #189: Estimation - a review
- #186: Bad for ROI - More Planning - Part 1
- #187: Bad for ROI - More Planning - Part 2
- Software Estimation: Demystifying the Black Art by Steve McConnell
Transcript
Hello, and welcome back to the Better ROI from Software Development podcast.
This episode is part of a wider mini-series looking at estimation in software development. I started the mini-series in episode 189 by providing the following guidelines:
- Don't invest in estimates unless there are clear, demonstrable value in having them.
- Agree what a valuable estimate looks like. This will likely be a desirable level of accuracy and precision for an estimate.
- Provide the team with training and time to develop their estimation skills.
- Collect data on points 1 to 3 and regularly review if you have the correct balance
Subsequent episodes take a deeper dive into specific aspects for estimation in software development. While long-term listeners may find an amount of repetition across the series, I want each episode to be understandable in its own right, as much as practical to be self-contained advice.
In this episode, I want to encourage you to mentally separate estimation and planning.
They are often conflated, which leads to confusion, distrust and dysfunctional behaviour.
An estimate is generally part of a plan, and a plan can be the outcome of the act of planning.
Software development can't be delivered without planning, even if it's only the most cursory of activities. Software development can be delivered without an estimate.
I wanted to use this episode to avoid confusion over the value of a team getting together planning a piece of work. There can seem to be a lot of similarity between a team planning a piece of work and a team estimating the work. After all, from the outside it looks like the team are all sat in a room talking about the work.
However, there will always be value in a team planning a piece of work. Be it for knowledge sharing, alignment, planning etc. It helps the team with alignment and engagement, a shared purpose. That is one of the most powerful things a team can have.
And during those conversations, a team may find it useful to break down parts of work, and maybe even come to a comparative sizing of each piece, maybe using something like t-shirt sizing.
Doing this can be an incredibly useful tool for the team to validate shared understanding. If most of the team thinks something is small, but one person thinks it's extra, extra, extra large, there's a conversation to be had. And it can help in the ordering of work in terms of getting the biggest bang for our buck.
But, that doesn't mean that planning automatically provides a valuable estimate, or indeed a Gantt chart style plan with milestones and deliverables.
Winston Churchill is often paraphrased as saying:
"Plans are worthless, but planning is priceless."
This in itself may have been a rephrasing from Dwight D Eisenhower's quote:
"In preparation for battle, I have always found that plans are useless, but planning is indispensable."
Both Churchill and Eisenhower are talking about the value being in the activity of planning, rather than the outcome of the planning, the plan.
In traditional project management, this has always been turned on its head. The artefact, the output, the plan, the Gantt chart, often carried much more weight than the actual act of planning.
I've had many experiences where well-meaning project managers are pushing for the plan, rather than creating the space and the environment engaging in valuable planning. Unfortunately, their industry has pushed them to produce the artefacts, the output, rather than value the activity that originally created it.
This is why any experienced developer will have scar-tissue around this checklist style of delivery. And I can personally testify to having been asked many times for an estimate before any planning has been undertaken.
So, what makes the activity of planning so valuable?
Planning encourages us to consider the various scenarios, risks and opportunities. It helps us to build a deeper understanding of the situation and prepare us for different possibilities.
As teams get better at planning, they develop an inner checklist of tasks they need to undertake, other teams they might need to interact with, and potential problems. In short, they apply their combined experience to the activity.
Not only does this make the success of the software development more likely, through alignment and engagement, but it also makes a team more adaptable and resilient to the unexpected.
As the German military strategist, Field Marshal Hermann von Moltz, the elder said:
"No plan survives contact with the enemy."
This talks to the idea of the team being able to handle and react to dynamic, unpredictable situations that happen every day in our organisations.
While we can try to plan for the known unknowns, we can only train our teams in how to handle the unknown unknowns.
When our plan hits those unknown unknowns, we want our teams to adapt on the fly, still moving us towards the goal rather than coming to a standstill, or worse, doggedly following the plan in entirely the wrong direction.
Now, obviously, not all planning is great planning. Some planning may be too shallow, and be nothing more than "off-the-cuff".
"Off-the-cuff" is a phrase I've used many times in this series. It refers to doing or saying something spontaneously, without prior thought or preparation. In the context of planning, this would be the same as me saying "oh I know how to do that", and just getting on with it, rather than a thorough examination of the problem.
Note that sometimes "off-the-cuff" planning is actually entirely valid, especially if the work is well understood, or if there's an exceptionally fast feedback cycle, say less than 15 minutes, to be able to then demonstrate and ask "is this what you're after?"
This is why I said at the start of the episode, software development can't be delivered without planning.
There has to be intent to do something to produce an output, even if it only occurs in my head in a few seconds.
Whereas, at the other end of the spectrum is overplanning, the danger of the individual or team suffering from analysis paralysis. I talked about it in episode 186 and 187. There is a balance to be met. And this will be situationally dependent, based on the team and the work to be undertaken.
But having that planning activity, even if only for 15 minutes, provides the team the ability to gain alignment on the work to be carried out, even if the only output from that 15 minutes is they need more time to understand the work.
Regardless of the quality of the planning, you can't automatically equate planning to estimates.
Good planning will no doubt help towards valuable estimates and if you're attatching real value to having a valuable estimate then you should be expecting a considerable investment in the team's time to produce it.
In next week's episode, I will look at the impact that dependencies have on software estimation. That episode is inspired by the blog post "Eliminate Dependencies, Don't Manage Them" on the scrum.org website.
In his book, Software Estimation, Demystifying the Black Art, Steve McConnell says that the size of the software is the single most significant contributor to project effort and schedule. Personally, I'd like to suggest that dependencies, if not of similar importance, are a close second.
Thank you for taking the time to listen to this episode. I look forward to speaking to you again next week.