Speeding up our delivery pipe

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.


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.


Hey @maikel
Thanks for sharing your thoughts, very interessting, I’d never had such a reflexion, and after reading your post my first comment is: “Yeah, let’s just try and start it!”

Below, just small comments:

  • My first thoughts was: can we work in parallel too? But you answer that point by mentioning Pair Programming. What a nice idea! I feel like it could be exhaustive as well, but yes, I guess we could also work alone if we feel tired or want to take a break.
  • You already talk about junior, and maybe it could be more difficult for them. I agree with that. It should also have implication about the recruitment too.
  • I’m concerned also about the biais that could be: “If maikel, as the master jedi, will resolve at the end all the issues, how can a junior (or me actually) can improve themself?”
  • I totally agree on your opinion about the “Looks Good To Me” symptom. I totally have this one.
  • I really like when you’re saying that the code review is built into development when pair progamming
  • Filipe included all the process is a really nice idea, we do have similar process together and it’s very nice to have Filipe that mastering specs.
  • Let’s start by picking up together one issue per week chosen on the delivery circle ! :+1:

Of course I know nothing about the process of coding (although, I"m gleaning a lot from watching you folks work and reading this post). I’m so inspired by what our dev team accomplishes and how well you work together - and its encouraging to those of us who make other kinds of contributions to the community. But I had a further thought on this issue - maybe something more long term to work toward - what if we focus our hiring so that we have at least 2 devs in the same, or adjacent timezones at all times? So we’d need a second dev to work with George in EST time, and with Maikel near his time, etc etc. ?? Would this be a long term vision to work toward? It shapes our hiring I guess…

Thank you Theresa for the encouraging words. :hugs:

That would be awesome to avoid the lonely wolf work we do at the moment. But we are having difficulties to find any developer at the moment. We can’t make that as a condition right now but it would be great if we could in the future. And maybe if we have multiple candidates then that could be a criterion (<- yes, I had to look up the singular for this word, English kept the original Greek spelling for once).

At the moment, it’s actually quite convenient to hand over work from one time zone to the other. A bit of overlap would be good but we almost have “Continuous Development” as in 24 hours a day. :wink:

I think let’s try it - I am so happy that you are thinking ‘out of the box’ @maikel and coming up with things to try that might help!

We have been doing this for two weeks now and found it positive so far. We’ll keep reviewing it in the delivery circle.

1 Like