(special thanks to Deepa Joshi for her input!)
A critical skill for senior engineers is knowing how to break down a bunch of work into smaller, more manageable pieces. You need to make sure you’re spending your time and effort on the right things, and that the rest of the organization is in agreement. This isn’t always the most exciting part of software development, but I’ve seen a proper work breakdown (WBD) shave months off a project, even when done after the project is already months late. I’ve never seen it be a waste of time, no matter how anxious people are “to get to work” (Those are semi-sarcastic quotes, because planning is part of the work of software development).
Of course, the WBD is no big deal if your work is regularly simple and small and involves few people, but for anything more complex, not doing a proper WBD usually leads to lots of problems like:
The WBD is critical to starting the effort on-track, keeping it on track, and even putting it back on track when it starts to seem out of control.
If you’re anything like me you just want to get back to work and don’t really want to be concerned with this kind of bureaucratic bean-counting. It’s certainly not much fun, and it can feel like a waste of time to spend so much time talking about the work instead of getting started on it. Try to keep in mind though: wasting your time building the wrong things, getting results way slower than you could be, getting mounting pressure and criticism from an organization -- all of those things -- are even less fun than doing a proper WBD. A proper WBD is pure bliss compared to a large project failing. You’ll never be a useful contributor to the management of a larger software effort unless you're willing to learn how to do it.
A lot of developers have a bunch of experience doing WBDs along natural boundaries into smaller pieces and maybe have seen some success, especially on smaller projects. If they haven’t studied what other people in the industry are doing though, they’re almost certainly not doing very effective WBDs. Good WBDs don’t look at all like you would naturally or intuitively expect. There are decades of prior thought on this and you’d ignore it at your folly.
Here are some common methods of breaking work down that don’t work very well:
It’s important to not confuse a work breakdown with an architectural design. You might have various architectural components involved in a larger effort you’re undertaking. They could be standard architectural components like model/view/controller or just frontend/backend or multiple services in a more service-oriented or microservice architecture. It’s absolutely worth a good chat about the architecture, and it’s worth doing an architecture breakdown with diagrams and written plans. I would keep this very light in the beginning and define it as you go, but it’s definitely worth doing.
Don’t confuse this with a WBD though!
A WBD is intended to be something that makes sense to non-engineers with the ability to make progress visible. Most architectural components make no sense to non-engineers, and deliver nothing on their own to users. You actually can’t even honestly say to yourself that an architectural component is done with certainty unless it’s integrated and in use by its collaborating components. Instead we want to drive uncertainty like that out as early as possible.
In interviews when I ask Senior Engineering candidates how to break work down, the most common answer I get is “as small as possible”. This is a nice answer insofar as it’s obvious that they do value breaking down larger pieces of work in general (rather than a single 3 month task!), but probably the smallest possible breakdown is character by character of the source code. I’m certain that no one actually means that.
If you’re doing the smallest pieces possible, very few of those pieces will deliver anything to users at all, or result in any learning for the company. You can work for weeks without contributing to progress visibility or value delivery. Of course we want to divide-and-conquer the larger effort, but we’ve got to be more thoughtful than just saying “the smallest pieces possible”.
Instead, we want the smallest pieces possible that still make our progress obvious (ideally even delivering actual business value). If you break things down further than that, you run the risk of showing false progress, and introducing many new kinds of risks.
The next most common way of breaking work down seems to be for the purpose of assignment to different people on the team. This is where you get tickets for the frontend devs and tickets for the backend devs, or one ticket for the devs and one ticket for the tester.
This can be a nice clear way of showing who is working on what, but it actually hurts both visibility and value delivery. You get people saying “it’s done but it just needs to be tested”, or “the backend is done but we still need to build the frontend”. These are weak definitions of “done” where we can’t deliver anything to users, and we’ve learned nothing in production. Saying “done” in these cases is a bit of a smoke screen to stakeholders; the testers could reveal bugs that require more work, and the frontend devs could uncover missing functionality on the backend. Without them being in a production environment with real users you still won’t know about the defects that the testers missed, or whether your backend can handle the load. Telling the stakeholders that something is done in any of these cases won’t really be 100% true and so at best won’t be as transparent/visible as you could be. Sometimes I’ve seen people showing a frontend on its own and that can be downright deceptive to non-technical folks that don’t realize how much work there is involved in making the backend (which is sometimes the majority of the work).
Note: Unfortunately most ticketing systems only let you assign a piece of work to a single person, but you shouldn’t let the tool get in the way of you doing the right thing and having multiple people (where useful) working on the same ticket when it’s the most visible way to work and gets you actual value delivery. You can easily chat informally (off the ticketing system) as a group about who does what if you want to take different portions of the ticket individually. If you need to put a single name and face on a ticket, choose a leader for it and assign it to them.
Ultimately a good WBD should put the focus on real accomplishments as much as possible instead of efforts, and put the focus on what the team is doing, rather than what individuals are doing. How do you do that? I’ll tackle that in my next post.