9 Tips For Software Developers to Ship Meaningful Work
by Parker · 44 things on Twos
- 9 Tips from Shape Up by Ryan Singer of Basecamp to Stop Running in Circles and Ship Work that Matters
- Pick a project cycle length
- This is the typical length of your projects or "sprints" so you can consistently put out great work.
- It should be long enough to build something meaningful and short enough to feel the deadline looming from the start so you use your time wisely.
- Basecamp uses 6-week cycles with 2 weeks cool down in between for bugs and other experiments.
- Shape projects based on time
- Instead of asking how much time it will take to do some work, ask: How much time do we want to spend? How much is this idea worth?
- If a project runs over, by default it doesn’t get an extension and is not continued unless picked for another cycle against other outstanding projects.
- The shaped project should define what the feature does, how it works, and where it fits into existing flows.
- Beware the simple question: “Is this possible?” In software, everything is possible but nothing is free. Instead of asking “is it possible to do X?” ask “is X possible in 6-weeks?”
- Take full responsibility
- Completing the project within a fixed amount of time requires limiting the scope and leaving specific things out.
- You can’t ship without making hard decisions about where to stop, what to compromise, and what to leave out.
- A hard deadline and the chance of not shipping motivates the team to regularly question how their design and implementation decisions are affecting the scope.
- Actively make trade-offs and question the scope instead of cramming and pushing to finish tasks.
- We create our own work for ourselves. We should question any new work that comes up before we accept it as necessary.
- Start with the hardest part
- Sequence the work from the most unknown to the least worrisome pieces and learn what works and what doesn’t by integrating as soon as possible.
- Build one meaningful piece of the work end-to-end early on and then repeat.
- If we were out of time at the end of the cycle, which of these could we easily whip together—despite the unknowns—and which might prove to be harder than we think?
- Effective teams choose the most important problems first with the most unknowns, get them to the top of the hill, and leave the things that are the most routine or least worrisome for last.
- You can say no
- It’s easy to overvalue ideas. The truth is, ideas are cheap. They come up all the time and accumulate into big piles.
- Our default response to any idea that comes up should be: “Interesting. Maybe some day.” In other words, a very soft “no” that leaves all our options open. We don’t put it in a backlog. We give it space so we can learn whether it’s really important and what it might entail.
- Backlogs are big time wasters. The time spent constantly reviewing, grooming and organizing old ideas prevents everyone from moving forward on the timely projects that really matter right now.
- Really important ideas will come back to you. When’s the last time you forgot a really great, inspiring idea? And if it’s not that interesting—maybe a bug that customers are running into from time to time—it’ll come back to your attention when a customer complains again or a new customer hits it. If you hear it once and never again, maybe it wasn’t really a problem. And if you keep hearing about it, you’ll be motivated to shape a solution and pitch betting time on it in the next cycle.
- The vast majority of bugs can wait six weeks or longer, and many don’t even need to be fixed. If we tried to eliminate every bug, we’d never be done. You can’t ship anything new if you have to fix the whole world first.
- Take time to cool down
- After each six-week cycle, we schedule two weeks for cool-down. This is a period with no scheduled work where we can breathe, meet as needed, and consider what to do next.
- Ask any programmer if there are things they wish they could go back and fix and they’ll have a list to show you. The cool-down period between cycles gives us time to do exactly that. Six weeks is not long to wait for the majority of bugs, and two weeks every six weeks actually adds up to a lot of time for fixing them.
- Make sure you're solving a real problem
- The solution doesn’t matter if the problem isn’t worth solving.
- Of course, any problem that affects customers matters. But we have to make choices because there will always be more problems than time to solve them. So we weigh problems against each other. Is this problem more important than that problem right now?
- What if the problem only happens to customers who are known to be a poor fit to the product? We could spend six weeks on an ingenious solution that only benefits a small percentage of customers known to have low retention.
- We are extremely picky about the quality of our code, our visual design, the copy in our interfaces, and the performance of our interactions. The trick is asking ourselves which things actually matter, which things move the needle, and which things make a difference for the core use cases we’re trying to solve.
- Take your time
- Teams can’t just dive into a code base and start building new functionality immediately. They have to acquaint themselves with the relevant code and go down some short dead ends to find a starting point. Interfering or asking for status too early hurts the project. It takes away time that the team needs to find the best approach. Asking for visible progress will only push it underground. It’s better to empower the team to explictly say “I’m still figuring out how to start” so they don’t have to hide or disguise this legitimate work.
- The team naturally starts off with some imagined tasks—the ones they assume they’re going to have to do just by thinking about the problem. Then, as they get their hands dirty, they discover all kinds of other things that we didn’t know in advance. These unexpected details make up the true bulk of the project and sometimes present the hardest challenges.
- You need uninterrupted time. When you pull someone away for one day to fix a bug or help a different team, you don’t just lose a day. You lose the momentum they built up and the time it will take to gain it back.
- One piece at a time
- A team should aim to make something tangible and demoable early—in the first week or so. That requires integrating vertically on one small piece of the project instead of chipping away at the horizontal layers.
- Every piece of work has two phases. First there’s the uphill phase of figuring out what our approach is and what we’re going to do. Then, once we can see all the work involved, there’s the downhill phase of execution.
- Start on things that are core, small, and novel.
- Full notes on Shape Up by Ryan Singer