How we Plan for Maintenance and Small Changes 🔨
A simple process to do it reliably over time, without losing your mind
In The Four Types of Work I described the different cycles we use to plan product and engineering work. A few people have asked a more details about the Operational Cycle, which is dedicated to maintenance.
A brief summary for those who haven't read the post (but read it if you can and let me know your thoughts!) — our main work gets done in Sprint cycles, lasting 2 weeks, in which we address regular activities. Then we have a separate weekly cycle dedicated to bugs and small changes reported by anyone on the team.
About this one, I will try to answer your questions and provide more context about what we implemented — it has worked well for us and we are all a bit proud of it.
Actually, there is so much to talk about that I will split this post in two:
The first part (this one) will focus on the process itself: why we do things this way, and how we implement them.
The second part, next week, will review the performance of the process and what we did to improve it over time (spoiler: we made it measurable and added some…fun 🏆).
So let's dive in!
Hey 👋 this is Luca! Welcome to a 🔒 weekly edition 🔒 of Refactoring.
Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.
You can learn more about Refactoring here.
To receive all the full articles and support Refactoring, consider subscribing 👇