The Tech Startup CEO’s Guide to Good Development Practice. Part 2: Weekly & Monthly 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 2 of what I think will be a four-part series. Part 1 examines daily practices and Part 3 looks at ad hoc and long cycle practices. In this article we’ll take a look at some of the practices that take place on a weekly/monthly basis.

Planning Meeting/Sprint Review

What is it?: Every week (or two, or three; I like every week), the team gets together for a slightly longer meeting than the Daily Standup. It might be 30 minutes, it might be an hour, maybe two as an outlier. The purpose is to review progress as a whole since the last meeting and talk about upcoming work. Sometimes these 1–3 week cycles are called “Sprints”, hence “Sprint Review” is what some people call this practice. The focus is on the larger work items rather than the daily tasks briefly indicated in the standup and it is where demos of recently completed work are given and commented on, delivery challenges are discussed, decisions on how to tackle the next big item are made (or at least a meeting to tackle these is arranged), work for the coming cycle is prioritised, etc.

Why do they do it?: Even a team with a good state of flow needs to take a little bit of time out to step back, take a look at what it has delivered or is delivering, and regroup before diving back in. Demo and design reviews in particular ensure everyone has the same understanding of what is being delivered and has a chance to question decisions made.

How does this help our business?: Planning Meetings/Sprint Reviews are usually open to anyone who is interested to join. They are undoubtedly tech delivery focussed but they are another form of Visible Work and give people who aren’t close to the daily work of the dev team a good insight into the cadence of work, as well as progress on particular features or areas of work. They also make the discussion between the devs and the Product Manager(s) very transparent.

How do I know it is going well (or not)?: Like the Daily Standup, Planning Meetings/Sprint Reviews should be short and focussed. There should be a good flow of demos and discussions on areas that matter. Everyone should be clear what the priorities for the coming week (or 2 or 3) are. If this isn’t happening, or the discussions are long and inconclusive, it might be a sign that the work isn’t all that clear to the team.

Reprioritisation

What is it?: The development team should be working according to the priorities agreed in the Planning Meeting/Sprint Review. But things change quickly, especially in a startup, and so those priorities often need to be revisited. Reprioritisation is a conversation between the Product Manager and the development team about what is changing and what is the best approach to accommodating those changes. Reprioritisation can take place pretty much any time it is not disturbing the team’s development work (unless it is truly urgent) such as straight after a standup or as part of a Planning Meeting/Sprint Review.

Why do they do it?: Changing priorities needs to be a conversation, not a command. It is very rarely best for a developer to immediately stop what they’re doing and start something else (the only circumstance I’d advocate that for is a critical production issue). Usually it is better work out what the trade-offs are between finishing what is being worked on — whether that means just finishing the current development task or finishing of a related set of work such as a new feature — and starting whatever is now the highest priority.

How does this help our business?: Even in a startup ,where everything is changing all the time as you learn what it is your business is supposed to be doing for its customers, being calmly responsive to change is better than being madly reactive. Partially complete development work can have unexpected consequences, constantly having to drop something to start on something new can start to undermine the developers’ confidence in what they’re working on or who they’re working with. If you’re using TDD and have well-factored code, as well as a CI/CD toolchain, developers should be able to start working on new priorities within hours, maybe a day at the outside which, for most changes in direction, is plenty responsive enough.

How do I know it is going well (or not)?: Reprioritisation done well is never a drama. The Product Manager should be able to clearly explain the need to change priorities and the team should be able to respond quickly to that change. If Reprioritisation is a drama then it may be that the reason for the change isn’t clear to the dev team (and it is important they buy into dropping whatever they have been working on and starting afresh on what is new) or perhaps lack of other practices make changing direction hard or painful for them to do.

Small Stories

What is it?: User Stories are a common mechanism for describing what it is users want from a system. Examples of user story might be about using a digital coupon to get a discount on an online purchase, or visualising the progress of their team for the week. Small Stories is the practice of making these stories as simple and focussed as possible, with larger pieces of work (perhaps there are many different types of digital coupon the business wants to offer) split into many separate stories.

Why do they do it?: Stories are the key driver of work for the dev team (they are the things that get planned and reprioritised). A story will be delivered as a series of development tasks but until all of those tasks are complete, the system won’t do anything additionally useful for the user. Keeping stories small helps the dev team concentrate on the smallest set of changes that will add value to the system. It also means that changes in priority don’t end up with large chunks of work undelivered.

How does this help our business?: Delivering business value in small steps is hard to do. Everyone is excited and motivated by the big picture but each little incremental improvement in what you bring to your users is a chance to win more business (not every user needs every feature of the system) and to learn what users really want. You might have a great idea for a comprehensive set of dashboards your users can use to manage their business but perhaps you’ll find out that just a very small number of key metrics gives them everything they need.

How do I know it is going well (or not)?: It’s important when building in such small increments that the work doesn’t become fragmented with small additions scattered about the system. Even if it is delivered in a number of small steps, you may need to deliver a varied set of discount codes and coupons in order to attract and retain all the different types of online shopper you’re looking to attract. Having a Roadmap helps keep work coherent and the ‘big picture’ in mind whilst working on these small fragments of value.

With thanks to @ratkins on twitter for suggesting this practice.

Sustainable Pace

What is it?: The practice of Sustainable Pace is simply one of keeping the number of hours in a working day and working week to a manageable level. What is manageable? Well, it’s different for different people but 8 hours per day, 40 hours per week seems to work well for most developers I’ve worked with, some are able to happily sustain 50 hours, and a rare few 60+ hours. The main criterion, though, is the team is able to sustain the number of hours without quality of work dropping off or people burning out.

Why do they do it?: Delivering software is hard work. It may not look it to an outsider, and it often doesn’t feel like it to the developer as they work; after all it’s not nursing or teaching. But it is a constant shift between thinking like a tester, to thinking like the machine, to thinking like a user, to talking to those users (or their proxies), and so on. It requires a lot of concentration and mental agility. Tired developers often make mistakes that can be hard to find and fix later down the line so Sustainable Pace recognises that there is a balance between the amount of hours worked and the quality of work delivered.

How does this help our business?: This is a counter-intuitive practice for a start-up business. After all, Elon Musk says that you need to work at least 80 hours per week to succeed and no one ever changed the world working 40 hour weeks. You can’t argue with Mr Musk’s achievements but he’s talking about a high-profile, highly invested, Silicon Valley start-up. You may not be able to attract and retain (or just burn through) people in the way he can. More to the point, working at a Sustainable Pace can still deliver excellent progress and it means you have something to draw on when it’s really required, such as when you need to deliver a new feature to land a key customer or an unexpected market opportunity presents itself. If people are working to the point of exhaustion as a matter of course, your options will be limited when those opportunities come your way.

How do I know it is going well (or not)?: In a start-up there is a balance between going flat out to find product/market fit and being able to accelerate when opportunities present themselves. Working at a Sustainable Pace should not slow finding product/market fit down and should allow for short-term bursts of extended effort. If your team is working sustainably and the pace of delivery is too slow, you may have a problem with team capacity, or possibly with your expectations of the pace at which things can realistically be developed. Equally, if you find it hard to burst effort because everyone is already working long hours then you probably need to back off the normal pace of work a bit.

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 weekly/monthly development practice, please do comment.

Further Reading

Part 3 of this series looks at ad hoc and long cycle 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.