Startup: which software development process to choose
The short answer is:
- it must be agile;
- do not reinvent the wheel and use a standard one (Kanban, Scrum, etc.);
- once chosen, stick to it.
The honest answer is it depends. It's akin to asking which red wine is the best — it is very nuanced and requires lots of input, as all startups have unique contexts that should be considered.
While scarce and not well researched, the empirical evidence suggests that most early-stage startups use bits and pieces of various agile frameworks and adapt them to their needs. So let's continue and see why it is important to have a development process and how we can make an educated decision on which one to choose.
Why having a straightforward development process is important.
Early-stage startups are a mess: constantly changing directions, trying to prove multiple ideas simultaneously, adding features, removing features, onboarding new team members, and dealing with investors. One might argue that the chaos of the early startups is incompatible with any processes; instead, we must ship the features and get the product out of the door. However, you need a process if you want to:
- have some predictability for your roadmap (i.e., what is going to be shipped when);
- develop and ship the software iteratively;
- track the rate at which the features are released — measure velocity;
- ability to size the features and split them if necessary;
- have a possibility to prioritize the order in which features will be developed.
As a startup founder, your company's survival depends on how well you address your customers' pain points. Once you have identified them, you need to size, split if needed, prioritize, and predict (with a certain degree of accuracy) when the features that address these problems will be released.
Process is not a religion but an instrument.
Unfortunately, many founders (mainly non-technical) see development processes as obstacles. On the contrary, they are the means of achieving the results.
Each goal requires its instrument in every profession and is not different in software development. The good news is that in software development, we've got some time-proven frameworks that can cover a wide range of situations (call them swiss army knives if you want): XP, Kanban, Scrum.
Each of those frameworks can be fine-tuned to the needs of nearly every software development effort. Of course, each startup founder thinks their company is unique and requires a unique approach (just like parents with their first child), but the truth is that you can use the standard methods and adapt them to your contexts without reinventing the wheel.
The founders must not see the process as something that is defined at the beginning, and that is never changed. Like with a sports team, you set the rules, play the game, inspect, adapt, then repeat. See it as a sound controller; you change the settings, listen to the result, and adjust; once you are happy with the result, you stick with it knowing that you can continuously adapt it later.
On the reputation of Scrum.
There's lots of hatred towards Scrum, especially from developers. This is mainly because Scrum is easy to start with but difficult to implement correctly.
Again, it is not a dogma, so start small, don't try to build a castle when you need a tent. Begin with something, make retrospectives with the team, and adapt depending on their feedback.
It is also very important to explain why we need a process to the team (i.e., predictability, business management, etc.), as implementing something without understanding why reduces motivation.
Importance of sticking to a known framework.
Scrum, Kanban, and Extreme Programming are known to most developers, meaning new team members won't have to spend time learning new terms and methods. These frameworks also scale very well, so if you find your product-to-market fit and grow rapidly, you'll have one less thing to think about.
You might be tempted, but please, don't try to invent your own process. Tens of thousands of hours have been spent optimizing these frameworks. They've been used in teams of a few developers and companies with hundreds and thousands of engineers.
A very important note for non-technical founders: do not introduce new ceremonies, terms, or methods in the existing frameworks. A much better approach would be to think about what you want to achieve in terms of business and then think about how you can do it with existing processes.
So Kanban or Scrum?
Both can achieve the same results if done correctly. Both will allow you to fail too. Using one of them doesn't automatically mean that your startup will succeed. It depends. That's the hard truth, and sorry for telling you that, but that's the reality.
Do your teammates already worked with Scrum? Do you have roadmaps or product milestones? Use Scrum.
Do your priorities change daily? Your team says they have no idea how to estimate the tasks because most of those are research and development efforts? Kanban is probably more well-suited here.
The good news is that you can always switch from one to another. If applied pragmatically, both will help and not get in the way of shipping the code. Either way, the process will help you to:
- set the rhythm (i.e., ship the code in regular intervals — iterations);
- provide some evidence-based visibility of how fast you can ship a certain amount of software (i.e., track the velocity).
How to start?
Identify your context, choose a framework, align the team on it (perform training if needed) and start small. Track progress, identify areas of improvement, and implement them. Stick to it.
Remember: the best is the enemy of the good.
Importance of engineering best practices.
Every building needs a foundation, and engineering practices are your product's foundation.
No matter which development process you use and how well you stick to its ceremonies if technically your product sucks — you won't succeed.
Agility means moving fast. In software development, it needs that each developer must be enabled to move fast:
- User stories are written and clear, and acceptance criteria are well defined;
- Tests are written, and code coverage is appropriate (use TDD or ATDD);
- At least Continuous Integration, better with Continuous Delivery;
- The team is aware of Technical Debt and is keeping it in check. Taking new Technical Debt is a conscious choice, not a side-effect;
- Use existing Design Patterns to structure your code;
- Adopt DevOps.
Tests are especially important as they provide a quick answer to the question, "did my changes brake anything?". You need to know in minutes whether your new version of the product is still working as expected or not.
Conclusion.
All startup team members need a well-defined process to advance rapidly in their product development adventures. Searching for a product-to-market fit is like looking for a path in mountainous terrain with poor-to-zero visibility: you go forward, change direction, and sometimes you have to go back! Being organized is crucial: everyone follows the same rules and moves in the same direction.
For co-founders, it's not a developer's toy but a means of visibility into your product's development. For developers, it's not a founder's bureaucracy but a way to stay in sync with business, reduce waste and develop features that matter most.
Remember, a startup is a team; you must be organized to achieve great results!
