The backlog has lots of benefits in the software development process, but is it necessary? Could there be more to gain by just trusting your crew will do the right thing at the right time? #
It occurred to me while tracking Github commits on a project that I didn’t need to maintain a backlog or a burn down chart or any of those kinds of things anymore. #
Everyone was watching each other’s commits, commenting on issues, and chatting when they needed to. I could see what everyone had done the day before. #
They were all in synch enough to collaborate on the output when it helped to collaborate or work independently when that was more effective. #
What could I add? Remind them of all the things they haven’t done? That’s uninspiring for everyone involved. #
How does everyone know what to work on next? #
The devs know what’s important, and they know how to do their job efficiently…let them work it out. If they don’t know what’s important it will become obvious in their commits. Then you can just steer when the emphasis is wrong rather than mapping hours to tasks. #
They may in fact want to maintain a list that works like a backlog. But maybe that should be a personal productivity choice, not something that’s imposed by someone else. #
What about all those things you want to do that aren’t getting done? #
I’ve never had a feature that really mattered to me just fade from memory. In fact, having no backlog forces a sharper focus. #
How do you know when things will get done? #
Your devs will tell you, and they will be accurate if it’s a personal agreement between you rather than a number on a spreadsheet. If you have a deadline that really matters, then just be clear about that. That becomes framework within which to operate, a feature of the code. #
What if the developer doesn’t understand the requirements? #
Well, do you actually really need to spell out requirements? Aren’t your developers tasked with solving the need? Let them pitch a solution to a problem, agree on it, and then let them run with it. #
Of course, I don’t know how well this approach would work in a team larger than maybe 8 people, or a large-scale project with multiple parallel streams to it. And maybe the chaos does more harm than good over time. #
Clearly, I’m exaggerating for effect a little here, but I wonder a lot about how far you could go with this approach and where it really breaks down. #
I think a lot of folks want things like backlogs because one can establish a meaningful agreement and reduce tension between people who organize stuff and people who create stuff. But it’s often used to protect one side from the faults of the other rather than join them up to create a stronger whole. #
But all projects and teams are different. And it can be very tricky working out what should be done, by whom and when. #
I think what I’m suggesting is that rather than making decisions around time and resource where success is measured by how effectively activity maps to a plan, maybe the better way to lead a software project instead is to adjust decision making according to the appropriate abstraction level for the project. That way you can value quality and creativity over precision of delivery. #
For example, the resources required to build, say, a global transaction platform vs a web page are very different. And your teams will not allow you to rank them together. You have to zoom in or out to understand the impact of those two projects, and that will then affect how you allocate resources to make them each happen. #
Once that discussion has been had and everyone has agreed on what they are supposed to be working on, make sure they have enough caffeinated beverages and get out of the way. #
Keep an eye on their commits each day. And drop the backlog. #
It’s incredibly liberating. #
