Getting Stuff Done on a Software Team
September 24, 2023
It’s a Friday in the office. The end of another Sprint iteration.
And everything is a bit chaotic.
Multiple devs still have outstanding work awaiting approvals so they can merge them into main. Many of them have merge conflicts. We’ve also got a high-priority bug fix that we still need to start on, which is supposed to be done by the end of the day (the PM promised it would be).
On top of that, no one seems to remember if we hit our Spring Goals—or even what they were! Everyone had focused on working on our individual stories instead of completing our goals.
For far too many devs, this situation is painfully relatable.
For all the promises of Agile software development and tools to facilitate better work streams, many dev teams find it difficult to actually get stuff done. Teams are pulled in various directions internally, find themselves working alone more than intended, and constantly being asked to report on items they never committed to.
But getting stuff done on your software team doesn’t have to be so frustrating and chaotic. And it starts with a simple shift:
Focus on getting things done rather than starting new things.
Getting Stuff Done
One of my favorite books on software team delivery is from Daniel Vacanti. His book When Will It Be Done? helped me understand the way we attempt to estimate when features or fixes in our software will be complete is tragically wrong.
For many teams, the focus needs to move away from estimates and move closer to tracking how long it takes individual items to complete. This, along with probabilistic forecasting, it much better than the burndown charts and average velocity tools used today.
There are many great takeaways from the book, but the one that has stuck with me for the past several years is this:
The single most important thing you can do to improve single item forecasts is be proactive about how long it takes for them to complete
In other words, if we want to get better about accomplishing our goals, we need to be more proactive about getting things done rather than starting new things. Starting a lot of work items only to let them stay perpetually open and rot away does no one any good.
I tend to phrase this idea like this: Teams aren’t paid to start things; they are paid to finish things.
Would you pay a lawnkeeper if they only mowed half of your lawn? Or would you pay an electrician if they came to your house, started working on a new circuit, and said, “Oh, sorry - an urgent need came up across town. I have to finish your installation later?”
I imagine not.
But how do we start finishing things vs. starting them? Conventional wisdom suggests you should use WIP limits.
WIP Limits
The concept of work-in-progress (WIP) limits isn’t new. They’ve been around for a while.
The concept is that you limit each team’s total number of items being worked on at any given time. WIP limits are designed to prevent the team from picking up too much work and to prioritize items in flight instead.
For example, let’s say a team had a WIP limit of 3 items. One team member completes their task (yay!) and looks at the backlog. Just before grabbing the top item in the backlog to start work, they notice the team already has three items in progress. Instead of picking up the item in the backlog, this team member should reach out to their team members to ask how to help complete those items in progress.
The benefits of WIP limits are pretty well-known and understood. A recent podcast from Developer Tea did a great (and brief!) job of explaining how it all works from a neuroscientific perspective to help teams focus by reducing their cognitive load. I won’t go into those details here, but I highly recommend checking out the podcast episode!
The problem is that few teams actually enforce their WIP limits. Many tools allow you to set the limit, but often, it’s just a number on a dashboard that devs can ignore or get around. It doesn’t enforce much.
Enforcing WIP Limits
The natural question becomes how to enforce WIP limits for a team. The best way that I’ve learned to enforce WIP limits is to stop focusing on WIP altogether and focus on something else.
Focus on offering your help to your team for work-in-progress.
The idea goes like this: before picking up a new story or item to start work on, ask your team, “How can I help someone else finish their work?” Raise your metaphorical hand in your team’s Slack channel or Zoom calls (literal hand in that case), and offer to help your team.
Help might look different than just writing code, too. You might be able to help in wrapping up some tests for the feature. Perhaps there is some documentation you can finish for someone. Or maybe someone needs some help pair-programming out a complicated part of a bug fix.
Whatever it is, be a humble developer and help!
Once your entire team starts doing this, WIP limits take care of themselves. You won’t be discussing how many things are in flight because you’ll be spending so much time getting things done!
It Takes a While
It may take a while for some teams to feel comfortable asking for help like this.
Sadly, our industry has become much more focused on individual than team accomplishments. This focus can leave many engineers afraid to accept help when offered and even more afraid to ask for it.
The best action here is to focus on building trust within your team. Don’t get angry or upset when your offers are denied or ignored. And don’t ignore offers from your team to help you! You have to change the team’s culture, which happens through trusting relationships.
Additionally, make sure you follow through. When you offer to help someone with tests, remember to write the tests when they say yes. If they want to do some pair programming, make space on your calendar to make it happen. Otherwise, your “help” becomes another blocker and thing to synchronize around.
Be patient and keep at it. Over time, the team will realize, “Oh, this is a better way of working!” and you won’t have to convince anyone; the impact will speak for itself.
Getting stuff done on a software team is a surprisingly challenging task some days. We have to move past individual metrics and focus on the team working together to accomplish their goals.
Of course, there are more ways to improve your team’s velocity (or whatever metric you used) than what I’ve discussed today.
But no techniques or frameworks will be a silver bullet for your team unless your team stops starting and starts finishing.
If you can lead your team to raise their hands to offer and accept help from one another to do that one thing, the rest will fall into place.
Happy coding!
If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.
Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.