The Tech Startup CEO’s Guide to Good Development Practice. Part 4: Adopting & Adapting Practices
An interesting person — the founder and CEO of a technology startup — asked me an interesting question:
Where do I go to learn about good software development practices? I want to understand how my dev team works (or should work) and why they work that way. I want to be empathetic and not question things just because I don’t understand them but I also want to make sure we’re doing the right thing for the business.
(Undoubtedly I have paraphrased this somewhat)
This is Part 4 of a four-part series. Part 1 examines daily practices, Part 2 weekly/monthly practices and Part 3 looks at ad hoc and long cycle practices. In this article we’ll take a look at how and when to adopt and adapt some of these practices.
Adoption
If yours is the type of startup that can assemble an experienced development team from day one, there is a good argument for adopting most or all of these practices from the start. None of them require huge investments of time and energy and most of them will be familiar to at least some in the team.
But assuming this isn’t an option, which practices will deliver the best value to the team and the business?
Daily Standup, Visible Work, Planning Meeting/Sprint Review, Reprioritisation and Retrospectives are all very simple practices to install and will foster a cadence to the development process as well as good communication between the dev team and the wider business (which in the smallest startup may just be you, the CEO, and one developer). There’s not much point in having a Daily Standup of one person but as soon as two or more people are involved in delivering the product it can help, and if you’re acting as an early stage product manager it will be useful for seeing daily progress and also providing information about the business developments that may affect the future flow of work. Visible Work, Planning Meeting and Reprioritisation are all necessary in managing that flow of work and maintaining the ability to respond to change without becoming overly reactive and vacillating between the huge number of possible things you could be working on.
Personally, I think the earlier you install TDD, Refactoring and CI/CD the better. Once you get into a rhythm of delivery you want to be able to make changes quickly and reliably and get them into the hands of your users with the minimum of fuss. There is an argument that says this isn’t a problem until you actually have some users and so it’s not worth prematurely implementing these practices but a good CI/CD setup should take no more than a few hours to a couple of days to get right and TDD done well has a positive, not a negative, impact on end-to-end delivery times.
Pairing and Mobbing can be tricky in a startup with just a handful of devs. There may be times where one developer needs to be coding, another doing some kind of set-up work for a new customer or opportunity and the third providing some technical input to a sales opportunity or investment pitch. All while trying to support the existing system and users. Startup development work can be very fragmented and trying to force Pairing and Mobbing prematurely can lead to tensions between getting things done and doing things ‘right’. However a pragmatic approach that says “we Pair/Mob when we can, don’t sweat it when we can’t, and look to put in place the additional resources and practices to help us Pair/Mob more as we go” will give you most of the benefits and set a solid foundation for future improvement.
Managing Technical Debt should be relatively minimal in an early stage startup. Early stage is where you take on a lot of Tech Debt in order to broadly explore what works and what doesn’t. A simple mechanism for tracking Technical Debt is probably enough and an equally simple Roadmap (possibly no more than a list of “stuff we might work on in the next six months” up on a wall) will help the team start to figure out where limitations built into the system may become a problem in the short- to medium-term future. When Tech Debt does become something you actively need to manage you’re going to need to have those automated tests; another argument for early commencement of TDD.
The hardest practice to install in an early stage startup is Sustainable Pace. What is sustainable, especially when the early team are all super-excited to be getting going, energy levels are high and possibilities are endless? This will be different for every team and I think the main thing is to look out for signs that people are working unsustainably and to be empathetic to the fact that one person’s normal pace is another’s long week.
Adaptation
These practices are all described at a fairly high level and there are a lot of people out there who will tell that you’re doing Pairing ‘wrong’ if you’re not doing it 90–100% of the time or that you need to buy their tools to have any chance of success.
One of the key things to remember is that the game you’re playing is trying to get a business of the ground, not to win awards for the best run development process (those can come later :)).
None of these practices is new so it’s worth reading about each of them in more detail because there’s a lot of good experience and insight out there for you to build on. But don’t feel bad about ditching a practice because it doesn’t work for you (especially if you’re getting the same benefits from some other practice) or changing it to work in your particular circumstances.
Apart from CI/CD and TDD, none of these practices particularly requires technology support and often benefit from the simplest possible approach. For Visible Work I like cards stuck on a wall or whiteboard.
Of course, remote working changes this somewhat and right now — one year and counting into the global Covid-19 pandemic — it would be an unusual startup that tried to get all its developers working in the same room right from the off. For Visible Work the Singletrack development team has moved to LeanKit which is proving popular, we use GMeet for Daily Standups, Planning Meetings and Retrospectives, and Tuple for remote Pair Programming. The team has experimented with Zoom and GMeet for working in Mobs but has felt this wasn’t as effective as Tuple. Interestingly, if anything the enthusiasm for Pairing has further increased from an already high level. I take this to be down to developers wanting to avoid the isolation of working on their own at home all day.
Last Word
I’m not a CEO and have no ambitions to be one. But I am the co-founder of two successful technology businesses and have worked closely with startup CEOs as the technical lead in their business. These practices are not a collection of academically interesting ways of working or just the things you see most teams doing, they are the practices I rely on in order to deliver fast-changing, high-quality technology to a business in a way that also helps build the team that will sustain that delivery as the business grows. Some of the practices may seem counter-intuitive or hard to justify but I’d counsel a temporary suspension of disbelief; just long enough to see if they can work for you, your dev team and your business.
Thanks
Thanks to everyone who responded to this tweet on twitter but especially @andylongshaw, @jimhead, @YitzOfTheBits and @jayfresh who each proposed a great set of suggestions, @ratkins for suggesting the practice I called Small Stories and several people who recommended Accelerate as good reading on this topic. John S Nolan took the same question and came up with a different approach to answering it.