CH 7 Bets, not Backlogs
A slight sigh of relief passed through the room when we said there will be no more backlogs. To some this might be blasphemy to others it might be one less list of things they will never get to.
At Loadup we land somewhere in between where our backlog gets some love, but it definitely has items that will never get done. For the most part ours may be different because the backlog is partly between a decentralized list, and a backlog. The decentralized list idea brought up in the book puts the responsibility of keeping track of important ideas that might still be important when we have time to get to them. Instead of offloading that responsibility to someone who might not see the value of the project you hold on, and potentially champion your project when the time is right.
Really important ideas come back to you.
Chapter 8
Well this turned into a doozy of a conversation. That now seems to be a fortuitous precursor to the direction our company is heading(I'm writing this post a week later, so I get the benefit of hindsight here).
The conversation mainly revolved around the benefit or lack of benefit that would happen if we were able to implement some form of cycle for our work. What it boils down to is the idea that measuring developer efficiency is a weird cross between shaking an 8 ball, rolling some bones, and spreadsheets; all wrapped up in the name of effective planning. Now I know that isn't entirely true, and that the answer is out there somewhere. Yet if you are fine with that kind of ambiguity there can be some benefit that comes from some kind of structure/schedule to how the entirety of the development process works. On a side note you should check out the research article by Microsoft ala Github on a framework for measuring developer productivity. The Github blog talks a bit about how they used it, and has a neat Slackbot to help you improve your developer efficiency and happiness.
One thing that has been brought up numerous times is that Basecamp is a different company, provides different services, and thus we can't just copy what they do. I bring this up because in the chapter there is almost a blase approach to bugs. There are caveats that important bugs will halt the presses, but nonetheless a bug is a bug and can be dealt with six weeks from now. At LoadUp almost every bug directly impacts our revenue flow. Now of course we could take the time to have someone look into each bug, see how often it is occuring, and make the decision to fix it or not. In that time frame we could lose a lot of sales instead of immediately beginning to work on it. One thing we all are leaning towards is having someone available for bugs, bug duty, extermination time, etc. This way we all aren't watching the channel and being distracted by any level of bug.
That's all for now. There is a can of worms waiting for conversation. Hit up some comments if you want to discuss.
Top comments (0)