Every single company depends on software, and startups are no exception. Software has gone from being critical to every business, to BEING the business.
Software creation is an art, a craft, and a process.
Building and shipping software is a marathon that lasts the entire lifetime of the company.
To ship software effectively you need to establish cadence, and a process. In this post we discuss a lightweight framework and tips that startups can follow to ship quality software regularly and effectively.
1. Setup sprints
To start, you need a light process for identifying what to build and how to actually build it. Teams that choose to ship without a process end up being chaotic, stressed out, and ultimately not successful.
Here is a light process, called sprint, that will help your team ship to production every 2 weeks.
The sprint starts with planning what to build. The features are organized into two lists – all features you want to implement, and a subset of features you will actually implement in this upcoming sprint.
Before the beginning of the sprint, the team gets together and re-prioritizes all features. Once the ranking is complete, the top 3-5 features are moved into the list to be completed for the upcoming sprint.
Once the features are selected they are LOCKED for this sprint. You can’t add new features in the middle of the sprint.
This is critical. Making changes in the middle of the sprint throws off the timeline, and causes massive stress to your engineering team. Avoid doing this at all costs.
Similarly to having 2 lists for features, you will have 2 lists for bugs as well. Before the start of each sprint, re-prioritize all the bugs, and move the ones that need to be fixed into the list for this sprint.
Here is a sample setup for your sprint:
- Planning: 3 days before the start
- Fix Bugs: Day 1: Wednesday
- Fix Bugs: Day 2: Thursday
- Code: Day 3-7: Friday – Thursday, except weekends 🙂
- Test: Day 8: Friday
- Test: Day 9: Monday
- Ship: Day 10: Tuesday
- There are a few tricks to setting up the sprint.
Never release into production on Friday, or in the evening.
Why? Because things tend to break and then you might end up ruining your weekend or be stuck in the office all night.
The second trick is always fix the bugs first before coding new features. This way you are making sure that you are building new features on a solid foundation.
If your sprint is 2 weeks, you have 5 days to code new features. This is plenty of time assuming you broke down your features into small chunks. In fact, this system forces you to do that. You are always making progress, improving the product, and moving forward.
The last part of the sprint is testing and making sure you release quality software.
The last few days of each sprint should feel like a spiral.
You test, find bugs, and fix them. The closer you are to the release the fewer bugs you should find. Once there are no bugs found, you are ready to ship.
When you are in the home stretch of the release, it pays for everyone to focus on specific bugs or features together. When everyone is focused together you squash down a bug faster and then move on to the next problem. This strategy helps the entire team spiral down toward the release together.
2. Prioritize and handle emergencies
In addition to implementing sprints, get your team to always prioritize and stack rank features and bugs.
When everything is important, nothing gets done.
Create simple and clear language that everyone can adapt when talking about priorities. For example:
- P1 – highest priority, business critical
- P2 – important, needs to get done, but not critical
- P3 – not important, nice to have
If there is a P1 bug that is found in production, and it impacts the business, you need to pause the release, and push a fix into production. This situation should be rare.
If you finding that this happens all the time, then you aren’t doing a good job testing and fixing bugs in the final stages of your sprints. You need to revisit how you are handling your spiraling down toward the release.
As you review your lists of features and bugs, you re-rank and re-assign priorities. It is totally fine to have priorities change between sprints, just not during the sprint.
3. Pair program and test
Agile software development comes with a toolbox of methods to help build high-quality software. My favorite two are pair programming and testing.
Pair programming is literally two engineers working together. One is typing the code and the second one is watching.
Pair programming may seem like a waste of time but it is actually a more effective way to code, especially critical pieces of your system.
Pair programming increases the quality of the code and establishes awesome camaraderie between team members. You create clear and bug-free code out of the gate.
Testing, and unit testing in particular, is another strategy to ensure quality code. It is actually pretty hard to write and maintain a body of tests for your code, but it is necessary and it pays off. After all, if you didn’t test something how would you know it really works?
There are two types of tests that are particularly helpful. The first set of tests is for critical pieces of your software; things that just can’t break. The second is a set of tests that exposes the bugs you find. Whenever you find a bug, first write a test that exposes it and then fix the code. This way you are certain that if the bug returns your test will catch it.
4. Refactor your code
Like anything else in the universe, software decays over time. This may not be as obvious because we don’t readily see rust in the code, but it surely is there. Over time, large-scale software becomes tangled and fragile, and needs to be refactored.
The way to deal with this is to constantly refactor, or improve your software. Much like you go to the dentist for regular cleanings, you need to proactively clean your code.
Encourage engineers to remove unnecessary code, and constantly improve the software to make it better.
In addition, every 6-8 weeks schedule a cleaning and improvement sprint. In this sprint instead of business features, the team is focusing on cleaning up the code, making it better, and writing tests.
5. Create a happy and productive engineering team
It is really easy to grind down your engineering team, and most startups manage to do it quickly.
Startups thrive on chaos, but a chaotic approach to building software just doesn’t work. It is like trying to sprint through a marathon – you can’t do it.
Writing software is a highly creative and intellectually intense activity and requires a fresh brain, clarity, and a specific cadence. Software engineering can be either incredibly rewarding or incredibly stressful.
Setting up sprints and having clear priorities is a great first step to creating a happy and productive engineering team.
By creating cadence you reduce stress. By enabling your team to ship to production frequently, you are making the engineers happy. After all, there is nothing more rewarding than seeing the code you created work and make a real difference in the world.
Please share with us the strategies and techniques you use for building software in your startup.
Top comments (8)
Love the emphasis on "Once the features are selected they are LOCKED for this sprint. You can’t add new features in the middle of the sprint."
Nothing gets my goat like a sudden scope change in the middle of a sprint.
yeah its ridiculously stressful and should not be allowed.
I agree that would be ideal.
Sometimes there is new information (e.g. from customer feedback) that shows up and suggests that something we accepted into the sprint should be re-thought. In those cases, it is better to stop and re-asses than to spend time building the wrong thing.
Of course, if this happens every sprint, that seems wrong and you need to improve the decision -making that goes into planning the sprint. But "should not be allowed" seems unnecessarily categorical and plain unrealistic, in my experience.
Thanks for a great post Alex, definitely speaks to us.
We do things a bit differently here and there, but I would have loved to have had this kind of blueprint on my first attempt at startup engineering!
What is the sprint that you guys follow?
I’ll take some time to write a bit about our process tomorrow 🙂
Excellent write-up Alex! I'm moving to a new startup in a few weeks and I think this will help shape up the culture a lot. Thanks for this amazing post.
I found this really helpful. As a programmer that new to sprint, now I have a clear idea to properly follow agile software development. Thank you very much sir.