Hi folks đ
First off, I made an update to last weekâs post on culture fit. I got some great comments on how we can evolve the culture fit interview to be inclusive. In retrospect, I agree that we shouldnât place absolutes on things like this. Culture fit interviews can be useful if (and only if) they are corrected to be more inclusive with a bend on adding to the culture rather than fitting into it.
This weekâs post is on my recent obsession with evidence-based scheduling. This came from me diving into lots of articles on engineering leadership over the weekend. I wonât have any posts at the end of the newsletter to promote because honestly there is more than enough great content to sift through in that Awesome list.
Hitting deadlines
My recent productivity obsession is around Evidence-Based Scheduling.
Software estimation is hard. But I also want to make sure our stakeholders understand how far we are along in our projects and when we think we can reasonably deliver some software.
While watching The Last Dance this weekend about the â98 Chicago Bulls basketball team, I got to thinking about how great sports teams all review tape from their previous performances.
Who does that in software? I donât think Iâve seen anyone do that. And yet, if you think about the principles behind the book Deep Work, you have to get as much feedback as possible as to how you are performing at your job.
Practicing estimation is a skill and takes effort and time. In speaking with a few colleagues and friends on how theyâve implemented this themselves, there are a few things to keep in mind.
Buy-in and messaging is key
On the surface, this sounds like micromanagement to the nth degree. Now my boss is tracking my time? Iâm not tracking your time - YOU are. Itâs really easy for a framework for this to sound like a way to place the lens of Big Brother over your development teams. That is not the goal at all.
Instead, this is about tracking yourself to see how good you are at estimating your own work. Endless articles have demonstrated that we, as an industry, are really bad at estimating how long our work will take. This is putting that into repeated, frequent practice.
There are no points for completing things early and there is no shame in finishing things way off target. The point is not to grade your performance in matching expectations. The point is to see what is your pattern for estimation in the first place and account for that.
Maybe you are the chronic optimist and everything you do actually takes 20% longer than you expect.
Great! Now we can ensure that if you take a ticket we can reliably add 20% to the estimate to predict when any of your work will arrive. The time to complete doesnât matter; all that matters is the message to stakeholders about when we think this will most likely arrive.
It takes a lot of work upfront
A friend of mine mentioned that his team of 8 took about 8 hours a week in meetings breaking down tickets in grooming and providing granular estimates of the work that was to be delivered. Thatâs a lot of time in meetings per week, particularly for individual contributors.
At first, that seems like the effort is way too high for a team size that small. However, after a few weeks of working through this system, they were able to get these meetings down to about 2.5 hours while also increasing their accuracy and delivery.
Would you spend 5% of your week ensuring your delivery is 90% accurate to stakeholders? Iâd take that each and every week without fail!
Target practice
Remember that all of this is not an excuse to let stakeholders pepper your team with deadlines. It is an anti-pattern to adopt EBS so you can enforce deadlines. Rather, it is a reaction to an anti-pattern of deadline-driven development so you can get your teams out of the corner youâve already backed into.
The end result of adopting evidence-based scheduling should look something like a bullâs eye target. This analogy I use time and time again with my team leads when one of their stakeholders is adamant about requiring a specific date for something to arrive.
Imagine you are firing an arrow at a target 100 yards away with a 5â radius. The goal, of course, is to hit the bullâs eye in as few shots as possible. There are two ways to do this:
Increase your accuracy. Each time you fire an arrow (i.e. deliver an estimate) it should get closer to your target. In other words, if you think something will take 2 days and youâre off by 1 day this week and then off by 2 days next week, your estimation skills are only getting worse.
Move closer to the target. Itâs a lot easier to hit a target from 50 yards away than 100. In software, this is just time moving forward. The closer you get to the projected date of delivery (i.e. target) the clearer the bullâs eye becomes. You probably know what you hope to accomplish today but who knows what youâre confident to deliver 9 months from now.
So if you practice hitting a target regularly (i.e. practicing evidence-based scheduling) while simultaneously moving closer to the target (i.e. building more software every day), you should be moving away from deadlines towards target dates which just get more accurate and predictable over time.
At the beginning of the quarter, your project will arrive in 3 months with 60% confidence. In 2 months the project will arrive in 3 weeks in that month with 80%. In that week, the project will arrive on that Thursday with 95% confidence. This is how we shift away from deadlines to target dates.
Stakeholders still hear a date that makes them happy and you arenât beholden to a rigid delivery date which makes you happy. Everyone wins. That is why I am so excited to try this system out and if you have any experience with EBS please let me know.
đ Thatâs all folks đ
Aaaand weâre done with issue 129 of the User Interfacing Newsletter.
No articles this week (see the intro for a great list). If you got something out of this newsletter, feel free to forward it to your friends, family, and/or coworkers to help it grow.
Interested in sponsoring the newsletter? Have questions, comments, or corrections? Hit that â©ïž reply button and let me know what you're up to!
Cheers,
Adam