An experiment in deciding what goes in a milestone
We make products to improve democracy and we spend a lot of our time working to improve those products, too. In engineering at Delib, we’ve been wanting to run multiple product development tracks for a while, but we’ve been in the middle of hiring developers and have had some back-to-back commitments which have meant this has not routinely been possible.
We now have the space to look at multiple tracks of work and — on one of those tracks — to experiment with how we decide what goes into the regular product milestones.
Current state
The current state (for the most part) has been two tracks:
- One support track running constantly: This is a developer on support every day of the week, rotated roughly fortnightly. Jess wrote about that back in 2015, and what she wrote is largely all still accurate apart from that we’re in a different office and I have no idea how Samuel the Spider Plant is doing.
- The other track is for product development.
However: we run a lean business because we need to keep costs low for our government customers. Those customers also need us to meet high standards on things like security, accessibility and performance. These necessities can eat into that second track of ongoing product feature work. By that I don’t mean they eat into regular maintenance on products and infrastructure, but into the time for things which are a bit more than maintenance; those which deliver visible improvements and features or which break new ground by making tools for moving democracy forward.
It’s those visible improvements and features we all want to see more of.
New state
- Support track
- *New* Kaizen continuous improvement Citizen Space track (approx 4–6 weeks per milestone around about 6 times a year)
- *New* Breaking new ground / projects / big ticket track (6–8 weeks or more per milestone)
- + ?
- + ?
We’re hiring for even more engineers*, so we’d like to keep adding tracks and moving faster.
It’s the Kaizen track I want to talk about in this post because not only is it a new thing but we’re going to try a new way of setting it up as well.
Kaizen and deciding what goes into each milestone
Milestones are typically planned via a set-up with Andy (MD and product owner) and one or more developers. Sometimes I might be asked to give my tuppenceworth on whether something is still a priority for our customers or not, but often the main bulk of work is decided in that set-up meeting/IRC.
We assign an account manager and a developer DRI (Directly Responsible Individual) for the milestone and, through them, there’s a process for making sure that what’s planned for the milestone is communicated internally so that we all know when code freeze is due, when we want to get the release rolled out to customers, and what documentation and other work needs to be completed. There’s a template for this, it’s all very organised.
What it isn’t, though, is especially democratic. And even with the internal communication improvements we’ve made, things can be missed by anyone not directly involved. And if we’re going to call this work Kaizen, we’d better be involving a few more people.
How might this change?
The new Kaizen milestone is all about quick wins and visible improvements: ones we can make on a regular basis to make our customers’ lives easier.
We have a project in plan.io in which we collect the feedback we receive on our products. These tickets collect as much detail as possible about the requested change and we document how many other customers have echoed that request. As you’d expect, we also log bugs that we, or our customers, find. Bugs are as bugs is. No software is without them. As long as the product change isn’t too big, it’ll be considered for Kaizen. Bugs will always be up for grabs, too.
We plan to round up all the tickets in plan.io which are potential candidates. This will be a job for Andy (MD), me and probably either Jess or Alan (technical leads) to start with. Then we want to open these up for others in Delib to prioritise. The five tickets or so which have been judged highest priority will go in the first milestone, though that doesn’t mean the others are out. Because these milestones will run regularly — about 6 to 8 times a year — it means the rest remain as possibilities to be chosen in the following milestone, and so on, and so on, until we have no more work to do and can all go for a lie down.
A good handful of bugs will go into every milestone as well; anything which doesn’t affect data integrity will be included in the prioritisation. Urgent bugs already get their own hot-fix via our support track.
How to prioritise?
We make a tool for government called Simulator and our plan is to use this to prioritise this development work. Simulator comes in three types:
- One for balancing an organisation’s budget
- One for simulating how making spending choices on services might affect a household bill (like council tax in the UK), and
- One which allows you to prioritise services/items by spending points.
It’s this last one we plan to use.
We’ll be putting the candidates into Points Simulator, giving people probably 20 points to spend, and up to a maximum of 5 points for each item. Then we’ll all spend our points to determine what the top development priorities will be for the upcoming milestone. If it’s something you really want to happen, you’d whack 5 points on it. At the end of the exercise, points sim will let us easily establish where the top spends are. Through this we’ll also have more of us seeing and understanding the tickets sitting in our backlog waiting for some love, care and attention.
Another benefit of this is that we get to test our own tool out in a real exercise. The term for this type of activity — using your own tools in-house — is called dogfooding. This name is blargh, so I suggest we call it toast-eating. Making some toast and then eating your toast to see if the toast is good or if there’s something you might do differently next time you make it. Toast-eating? Yeah. Like bread. Like toast. Mmm.
How will we know if it’s worked?
- We’ll have regular milestones delivering for customers every 6 weeks. As evidenced by release announcements and feedback from customer check-ins (which we do as part of our release process. If we update something someone has previously asked us for, we call them to let them know)
- We’ll have a better picture across Delib of what’s in our ticket backlog and what we’re doing about it
- We’ll have tried out Priority Simulator for our own needs and found out what it’s like
- I run a support report every quarter looking at how many queries we’ve had in from customers and on what areas of the products. I hope this will show that, where we’ve made improvements to an area of Citizen Space, the support queries in that area have come down
NB: I’d like us to do a retrospective on this whole process after the first round and iterate on it after that.
And that’s it. I’ll report back on how it went. Warts and all.
Are you a developer? Would you like to work at Delib? It’s very good. Give me a shout on here or get in touch using the details in this job link.
