This episode is part of a wider mini-series looking at Estimation in Software Development. In this episode, I wanted to look at the impact that dependencies have on software estimation. This episode was inspired by a blog post on scrum.org entitled "Eliminate Dependencies, Don't Manage Them", which I read while preparing this series. In brief, the article talks about how you're better off eliminating dependencies rather than trying to manage them through normal traditional management processes. In his book, Software Estimation, Demystifying the Black Art, Steve McConnell says that 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.
Or listen at:
Published: Wed, 08 Jan 2025 01:00:00 GMT
Links
- #189: Estimation - a review
- scrum.org - Eliminate dependencies, don’t manage them article
- 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 back 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 of estimation in software development. And 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 wanted to look at the impact that dependencies have on software estimation.
This episode was inspired by a blog post on scrum.org entitled "Eliminate Dependencies, Don't Manage Them", which I read while preparing this series.
In brief, the article talks about how you're better off eliminating dependencies rather than trying to manage them through normal traditional management processes.
In his book, Software Estimation, Demystifying the Black Art, Steve McConnell says that 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.
Let's start by summarising what a dependency is.
For me, and for the scrum.org article, a dependency is anything that has to go outside of the team to be done. Examples of dependencies:
- we need work to be completed by another team before we can do our work.
- we need an external approval or sign-off.
- we need another team to deploy our software into production.
Our teams should be cross-functional. They should have all the competencies needed to accomplish the work, without depending on others, not part of the team.
Now traditional project management would have us capture and manage those dependencies.
For example, in a heavily siloed organisation, we would manage all the hand-offs between departments as dependencies. So, as the work moves from initiation, to design, to development, to testing, to sign-off, to deployment, etc. Each stage being performed by a specific siloed function. And we generally capture and manage those dependencies in a Gantt chart or similar.
Now, obviously, experience has taught us how ineffective this approach is. It's too easy for our carefully and painstakingly choreographed dependencies to quickly fail at the simplest of variations from the golden path, causing a cascade of planning and scheduling issues across multiple projects.
And, as the article discusses, the more dependencies can be eliminated, the better, be that be the team taking on that responsibility, or maybe even remove that dependent activity entirely.
The article itself is now 6 years old, so today I'd like to think most people would see this advice as old news.
In reality, however, dependencies, well-meaning or otherwise, continue to exist. And in such events, I'd certainly advocate for following the advice in the article. But for the rest of this episode, I'll be focusing on the impacts of those dependencies on software estimation.
So, in the intro to the episode, I discussed how impactful dependencies can be in software estimation, and if not a similar importance, a close second to size, as raised by Steve McConnell.
In his book, he gave the tip
"Invest an appropriate amount of effort assessing the size of the software that will be built. The size of the software is the single most significant contributor to project effort and schedule."
Steve actually devotes an entire chapter to size and its influence on estimation.
So why am I suggesting that dependencies can also apply a similar level of influence?
In short, it's because it's outside the team's control. While a team can expend effort to estimate things in their control to varying degrees of success, trying to estimate another team's activities is subject to too many variables.
That dependency, for example, a sign-off or a deployment, may seem like a simple thing to the team, but as they're not in control of it, they've no idea how much effort it would take, and thus are unlikely to be able to estimate it without detailed knowledge.
Now, maybe you could use SLAs or simple past experience to educate those estimates?
Yes, but neither an SLA or past experience is particularly accurate. More than likely it would be an overtly broad estimate to allow for the majority of requests. And even then it isn't going to take into account reduced capability through illness or sudden influx of requests causing a logjam.
Our traditional Gantt chart approach would have us asking the dependent team to estimate and provide a commitment to the work, leading to that carefully crafted, but ultimately fragile orchestrated dance across multiple teams. And we know that's simply too fragile to work.
Another approach would be to limit our team's estimation to just our bit. So, for example, we estimate how long it would take us to prepare the software for approval and release, effectively focusing on the portion of the lifecycle we can control. The problem with this is that it isn't getting it far enough to be gaining value. We need to be getting the software in front of the users to where it can really be gaining value.
If we lose focus on that, then we find that we have months or even years of development investment piling up, but never reaching the user. And thus never returning that potential value into realised value.
Plus, it pushes us into dysfunctional activities like batching.
No, rather we should, as the article recommends, eliminate those dependencies.
Doing so helps the entire delivery process, estimation included. We reduce so much wasted effort in coordination and delays inherent in those dependencies.
And as a side note, removing inter-team dependencies may reduce or even remove the value of estimation in the first place, again freeing up time for the work.
In this episode, I wanted to look at the impact that dependencies had on software estimation. I've reiterated the now commonplace practice of eliminating dependencies rather than managing them. And I've compared dependencies to size as one of the major contributors to the value of software development estimation.
So should your estimation activities uncover dependencies, resist the temptation to estimate. Rather, use it as an opportunity to investigate if they can be eliminated rather than managed.
In next week's episode, I want to discuss the psychological scarring left behind from decades of using estimates as punitive targets. I want to highlight the emotional baggage that our developers may associate with estimation, through no fault of your own, and will carry into future estimation work.
I, like most developers with any experience in industry, have worked in organisations that take an estimate and turn it into a punitive target, where a well-meaning estimate has been turned into a commitment, and ultimately a stick to beat the team with. A stick that ranges from aggressive to passive, be it threats of dismissal or simply discussing the failure to hit the estimate.
Thank you for taking the time to listen to this episode. I look forward to speaking to you again next week.