People wait a long time for fixes and features
The slow delivery of new features has been a pain point for a very long time. We often accept that because we don’t have much funding and a very small development team. We are actually doing a lot with such a small team.
Recently Stephen Barker shared an article with us about shipping code more quickly: Faster and More Predictable
I’ve been thinking a lot about a point that we have been struggling with in the global team: coworking across timezones. Many discussions happen asynchronously and delay delivery. It’s common for code review to take a week. And big contributions can go back and forth for a month even if all parties are very responsive.
One issue at a time
What if we all worked on only one issue at a time? No, not one each as we are doing at the moment, but one in total and we are all working on it?
We do this for S1 issues already. Across time zones, whoever is available picks up the batton and tries to solve the issue without waiting for feedback. If we are the only one awake, we have to make the call.
When I came back from parental leave, I started with code review only, without being assigned to any particular tasks. If I had suggestions to a pull request, I would often implement them and the code didn’t have to wait for another 24 hours or more in case there were more issues in the second round. That felt very efficient but I stopped doing it once I had my own big tasks on the plate.
A process proposal
There’s a lot we can do to achieve fast Continuous Delivery but just as the next step we could try the following:
- A developer starts the day by looking at the top of Code Review and assigning themselves to the first issue.
- When requesting changes, we then implement these changes. We try to advance the top priority in the Code Review column as far as possible.
- If we do significant changes, we still keep it in Code Review. Otherwise it can go to Test Ready.
- We unassign ourselves before moving to the next task.
- When we don’t know how to solve a problem, we try to educate ourselves instead of waiting for another expert in the team. We don’t want single people holding all the knowledge of a certain domain.
- We only start a new issue (from Dev Ready) when In Dev is empty and all issues in Code Review are waiting for another person. We aim to have only one issue In Dev.
Challenges along the way
It will be more difficult for junior devs to progress on issues than for senior devs but they will never be solely responsible for the issue. Everybody will get help at least once a day.
Since we always pass an issue on at the end of the day, we have to hand over and write comments. It will be much clearer what we worked on and what we tried already. This will also increase visibility into what work was done by whom.
Working together on the same issues also helps us to gain a deeper understanding of the code we review. Lots of reviews contain “looks good to me” these days which basically means that we don’t feel knowledgable enough to tell if the code is really good, it just looks good superficially. We pass responsibility back to the “expert” and to our amazing testing team. But me having a go at frontend tasks would give JB an opportunity to teach me as much as I teach him about Rails. And we would both understand the code better.
Passing on the batton works well with different timezones but we also have overlapping timezones. It would be great to work together, as in Pair Programming. We are lacking the tools for that. For example, my current setup prevents me from sharing my screen (I hope to solve that soon). But we can at least be in a call and discuss what we are doing. Many studies have shown that this is increasing code quality and reduces the time to deploy because code review is already built into development and fewer bugs mean that testing will pass more often and we don’t have to follow up with fixes. It’s more efficient than developing on your own.
There may still be cases when we work on our own. I would still enjoy that. It’s exhausting to always be in dialogue. But it may happen naturally when the other person is taking a break or has to respond to something else. We can see how we go.
As a trial, we could pick one focus task each week in the delivery circle and we all work on that one. Only when we can’t progress we go back to the ones we are assigned to already.
Vision
I can imagine that a pull request which took a month before can be delivered in a week using this new process. We may be able to incorporate the testing team in the process more. We already have cases in which Filipe is writing specs for another PR. This could happen on the same day.
On some issues, we have to go back to the product team to clarify details. Imagine they were instantly available, too. (Maybe they are in Europe, I just don’t know. ;-))
Work which doesn’t include translations could be deployed straight after merge. Most release testing needs to be automated for this. But we can also monitor our logs and revert to the previous code in case of any errors.
Basically, a Continuous Deployment process with a very focussed team can deliver features in days and weeks instead of months.
