The Tech Startup CEO’s Guide to Good Development Practice. Part 1: Daily 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)
The context is that they don’t have a technical co-founder who knows how to run development processes or grow technical teams. They’ve talked to a lot of different people about what they need to do in that area and had a lot of opinions, many from people trying to sell them stuff.
The question resonated with me as I’ve often been in the situation of having to explain why I employ certain practices to start-up CEOs who don’t necessarily intuitively understand what they’re for and what value they bring to their business.
So here is an attempt to explain good development practice to start-up CEOs. It’s opinionated in the sense that these are what I think are good and so it’s not necessarily bad if your dev team are not doing all of these, or are doing similar but different things. However, if your dev team are doing none of these, or if they are doing them but you’re not seeing the benefits, you may need some external help.
We’ll start with the Daily Practices: the stuff you’ll see the dev team doing day in, day out. This is Part 1 of what I think will be a four-part series. Part 2 looks at Weekly and Monthly practices.
Daily Standup
What is it?: Everyone in the team meets together at or near the start of the working day. Historically, everyone is standing (hence the name) as this helps to keep the meeting short. Everyone speaks briefly about what they have been doing recently and will be working on, often expressed as “Yesterday I …” and “Today I will …”. Issues they are having — sometimes called ‘blockers’ — are raised and either very quickly dealt with in the standup or else someone will offer to follow up with help after it.
Why do they do it?: There are concrete benefits to the Standup such as people hearing what others are doing and so having a greater sense of the overall team work, and being able to ask for or offer help on blockers. To me, though, the standup is the software development equivalent of the sports team huddle; the team coming together for a moment before they go about their work. It is where the team show they’re there for one another.
How does this help our business?: Software development is a team sport. You want your team to know and trust each other if you’re going to have any hope of getting a decent performance from them. Other practices reinforce team togetherness but the daily standup is the central practice for achieving this. It’s also pretty good for reducing wasted work whether due to efforts getting bogged down, duplicated or heading off in the wrong direction.
How do I know it is going well (or not)?: Even for a team of 20 a standup should take less than 15 minutes. If the Standup regularly exceeds 30 minutes there is either a problem with the way the Standup is being run or, perhaps, a deeper problem with the team or the work. A happy and close-knit team will often congregate a few minutes before the Standup and share jokes, talk about what they did last night, etc. After the Standup the team will be energised and quickly start to form Pairs or Mobs (see below). Silence pre-Standup and people quickly rushing off to their individual desks post-Standup is a sign that the team isn’t working well together.
What if we’re working remotely?: Remote working changes the mechanics of the Standup but not the purpose. Video conferencing services such as GMeet and Zoom work perfectly well but need a bit of direction to keep them short and to-the-point. Some teams use a messaging service such as Slack for their Standup but, to me, this negates the ‘team huddle’ benefits of the Standup and reduces it merely to a status reporting mechanism. For teams working asynchronously, this may be all you want.
Test Driven Development (TDD)
What is it?: In Test Driven Development (TDD), developers guide their development work by initially writing code that tests the expected function of the feature they will build. This test code is then run continuously as the developers build out the solution. Mostly the tests are for some very specific aspect of the part of the system they are working on. “Unit tests”, so named because they test a very specific unit of functionality like the rules applied to passwords (e.g. minimum of 8 characters with at least one number and one capital letter). Some might be to test wider behaviour such as the whole of the user login flow (“system tests”, “integration tests” or “end-to-end tests”).
Why do they do it?: TDD helps developers to focus on the outcomes they’re trying to achieve rather than just the detail of the solution. There are many additional benefits to TDD (test-driven solutions tend to have cleaner designs; there is a human-readable but computer-executable ‘specification’ of what the system should do) but the key benefit is having a comprehensive suite of tests that tell the development team if they’ve inadvertently broken something as they work.
How does this help our business?: Users hate bugs and they hate bugs that get ‘fixed’ and then come back even more. Unfortunately, bugs are just part of developing software (like ‘snags’ are part of building a new house and typos part of writing a report) and the faster you’re trying to build things the more bugs you’re likely to introduce. Regardless of that, though, buggy software very rapidly undermines the trust of the users and if that software is delivering your primary business function — whether because you sell a software product or you’re an online business — then it is undermining your customers’ trust in you. Even if you subscribe to “move fast and break things” you can’t keep breaking the same things over and over.
How do I know it is going well (or not)?: TDD-built software should have a low number of user-visible bugs and once fixed these bugs should remain fixed (because the fix process is to write a test for how the buggy code should work, see the test fail, fix the bug, see the test pass). Additionally developers should be able to change any part of the system, even complex and core functions, quickly and without fear. Post-implementation test automation — where developers or testers write automated tests after implementing a feature — can deliver these benefits but the discipline required to retain a comprehensive test suite is often undermined by tight deadlines where teams opt to come back and “write the tests properly when we have time” and never do.
Pair Programming (Pairing), Mob Programming (Mobbing)
What is it?: A traditional view of a developer is one of a lone worker, heads down, headphones on, not to be disturbed until they’ve finished their task. In reality though, developers are often talking to each other about how to tackle a particular problem, getting help with fixing a bug, reviewing code for good design, etc. Pair Programming and Mob Programming make this collaboration a continuous part of the process by two or more developers working together to tackle a single task.
Why do they do it?: Software development is a team sport and working in pairs or small teams is generally more fun than working solo. It’s not only ‘fun’ because of the social interaction of working with a colleague or colleagues on a problem (although that is a factor), it’s also the removal of many small frustrations of working as a developer: getting stuck and waiting for a colleague to come free to help; needing to perform a code review or wait for your code to be reviewed; struggling to hit on the right solution for a particular problem.
How does this help our business?: Pairs and Mobs tend to deliver good solutions to problems faster than developers working alone. Sub-optimal solutions get discarded faster, tests are more robust and comprehensive, bugs are less likely to slip through. The key business benefit though is that your whole team will work across the whole of your system, reducing the key person risk where some work can’t be done because the person who ‘owns’ that part of the system isn’t available to work on it.
How do I know it is going well (or not)?: Pairing and Mobbing is not for every developer (although it is a learned skill and I’ve seen many developers who initially baulked at these practices grow to love this way of working) and there needs to be accommodation for those who find it challenging or intolerable. Dogmatic application of Pairing or Mobbing to every task every time is a sign that the practice has become more important than the benefits it delivers. Also, if the same people are always Pairing together then you’re not getting the benefit of knowledge of the system being spread about the team; this is less of an issue with Mobbing.
What if we’re working remotely?: My team’s experience of remote Pairing is very positive. We use Tuple as it prioritises screen resolution over video & audio in situations where bandwidth is limited and has useful tools for highlighting areas of the screen or requesting control. We’ve tried Mobbing with GMeet but that has proved a lot less effective; I’d be interested to hear if any teams have had success with remote mobbing and what tools they use.
As an interesting side effect, remote Pairing has helped with team cohesion and general mental health during the pandemic lockdown. Prior to this our whole team was co-located and Pairing was the norm, albeit not entirely exclusive, way of working.
Refactoring/Rework
What is it?: Refactoring is simply the practice of revisiting some code that works and spending some time cleaning it up and making it easier to read and change. Rework is the same concept for things such as the UI of a feature or some underlying technology the system relies on, again not changing what it does but improving the way it does it.
Why do they do it?: Rework is a fundamental part of work. No report is just written from start to finish and then delivered, the writer will always re-read it, rework a section to be clearer, change the ordering of some sections to strengthen the argument, and so on. Code is no different and, like a report, code is meant to be read and updated by humans, not just executed by a computer.
How does this help our business?: Like TDD, clean code (‘well factored’ code) helps developers make changes more confidently and more quickly. Instead of having to decipher a jumbled mess of code to figure out where to apply an update, well-factored code will make it obvious where that change should go. If a developer (or Pair, or Mob) needs to work in an unfamiliar area of the code, clean code will make it quicker and easier to understand what it’s doing and how.
How do I know it is going well (or not)?: Refactoring and rework should, normally, just be part of the development process and not especially visible to a CEO. Occasionally, though, there may need to be a more significant investment of time and energy to larger scale rework, and this should be made visible and discussed. Developers will talk about building up ‘technical debt’ and how an overburden of debt can hamper efforts or even start to constrain what can be delivered. This is a healthy conversation whereas hiding this level of rework or simply not tackling it can both lead to an inability to deliver valuable functionality regularly and repeatedly.
Continuous Integration/Continuous Delivery (CI/CD)
What is it?: Even in small teams working in Pairs or Mobs you will have a number of development tasks going on at once. Continuous Integration (CI) brings the outputs of these tasks together and Continuous Delivery (CD) shifts all of this into an environment where it can be accessed by users and/or testers.
Why do they do it?: Traditionally, software was built as a set of isolated units that were worked on for some time and then first assembled when they were all finished or nearly finished. This frequently led to many issues: incompatibility between units, misconceptions about what a unit did, unexpectedly long periods of time required to assemble the system, etc. CI/CD removes these issues by doing this on a continuous basis.
How does this help our business?: CI/CD is a fundamental mechanism for ensuring you can get updates to your software into the hands of your users and customers as quickly and reliably as possible. Especially in a startup, a software development effort — such as the implementation of a new feature — only starts to deliver value to your business when users can use it.
How do I know it is going well (or not)?: CI/CD requires discipline from developers and an investment of time in the ‘tool chain’ that implements it. These days, however, CI/CD is a common practice and the tool support is available off the shelf and in the cloud. A good CI/CD implementation should take no more than a few hours to a few days to set up and should require little maintenance. If the developers are spending a lot of time tinkering with the CI/CD implementation it you may benefit from some external help.
Visible Work
What is it?: ‘Visible Work’ means having the tasks that the development team need to work on visible to everyone in the team and also to those outside the team. Typically this will mean having a board or a wall covered in index cards or sticky notes that represent the tasks, with the position of those cards or stickies indicating the state of the task (waiting to be worked on, being worked on, delivered, blocked, etc.).
Why do they do it?: When a team is working at pace, with Pairs and Mobs forming and reforming, a fast flow of work builds. People aren’t being assigned work, they are choosing the work they can best apply themselves to from the whole set of work the team needs to deliver. A high degree of self-organisation is emerging. The last thing anyone wants to do is keep interrupting this flow to check exactly who is working on what task, hold detailed status meetings, write progress reports, etc. Visible work enables everyone to see what is being worked on and where it is at.
How does this help our business?: Visible work is largely a tool for the dev team but those outside the dev team can substantially benefit. The dev manager or CTO can get a good sense of team productivity from the flow of work cards from one side of the board to the other. They can often spot problem areas when a task is ‘in progress’ for a long time or keeps moving from ‘in progress’ to ‘blocked’ and back. Product Managers can see work related to a specific feature or customer getting done and so get a sense of progress. CEOs can look for the presence (or absence) of business-critical features.
How do I know it is going well (or not)?: Making work visible is a simple thing but it can easily turn into a stick to beat the dev team with. “Why has that card been there for two days, I thought it would only take a day to do?”; “Why is the task I particularly care about still not started, I want it worked on now”. This will, in turn, lead to work being held off the board or the team gaming the system to avoid unhelpful scrutiny. At its best though, a team using Visible Work can do away with long and boring status meetings and just use the Daily Standup and Visible Work to manage the flow, focussing on what really matters: delivering valuable software.
What if we’re working remotely?: Teams that work with one or two individuals remote from an otherwise co-located team can still use a physical manifestation of ‘Visible Work’ with the remote team members asking their colleagues to send them pictures of the board and move cards for them. But with a full remote team an online system is necessary. My team uses LeanKit out of preference, Trello is another popular option. However, when the Visible Work is an online tool it takes discipline to constantly review it, something that happens as a by product of having a physical board or wall in the office.
Is this really just for Start-up CEOs?
I’ve worked with the CEOs/COOs/CIOs of later-stage and larger organisations who are struggling with technology delivery and much of the argument for these practices is the same. But different challenges and opportunities present themselves to those in a start-up trying to get itself going.
In many ways, an established organisation has already solved the number one problem of building a successful business and so any issues with technology delivery are ‘just’ efficiency/optimisation problems. A start-up needs to find its market fit and whilst a lack of good development practices won’t entirely prevent that from happening it can seriously hamper the effort, to the point of severely constraining the business’s ability to deliver just at the point of where some market fit is achieved.
Isn’t there more to it than this?
If you’re familiar with these practices or software delivery in general then you’re probably thinking “but there’s so much more to these practices (and others)” than this.
Yes, you’re right.
But I’m targeting a very specific audience here. There are loads of books and blog posts written for techies to explain why they should use these practices (and others). There are many that explain them to tech-savvy CxOs. What I’m trying to do is focus on the key practices and give simple explanations about why they’re used and what they achieve for someone who doesn’t have that context.
Having said that, if you think I’m missing a good daily development practice, please do comment.
Further Reading
Part 2 of this series looks at Weekly and Monthly practices.
Many of these daily practices have their roots in eXtreme Programming and Kent Beck’s Extreme Programming Explained remains the best book on these practices and how they fit together.
Eric Ries’s The Lean Startup describes how to start and grow a technology business and talks about how and why to apply some of these practices.
Nicole Forsgren and Jez Humble’s Accelerate provides a deep analysis of the benefits of some of these practices to a business, providing hard data to back up the beneficial claims made for them.