Continuous Delivery (to the pub)
Think of the times you've planned to leave work and go to a restaurant, pub, or the like with a few of your colleagues.
I'll use the metaphor of the after work drinks, since I'm most familiar with that one. What often happens is something like the following:
Thirsty worker #1: "I'll send an email to everyone asking who wants to go to the pub after work"
Thirsty workers #2 to #6 all reply that they do.
Thirsty worker #7 says, "I just need to finish a few things off. Can you wait 5 minutes?”
Thirsty worker #8 says "I'll see you there, I'm gonna be here another half an hour at least".
Five minutes pass. #7 apologizes and says, "I'll just be a couple more minutes".
Some other workers, who aren't yet sure if they'll go or not notice the crowd all waiting around #7's table.
Now, #9 comes in and says, "If you wait for me, I'll come too".
By this point, #8 has almost finished work. "I’m nearly done, wait for me!”
There are now seven people with their bags on their shoulders; half an hour has passed since workers #1-#6 were ready to go to the pub and worker 7 has finished and joined them as they all stand around worker #9's desk, since #9 wasn't quite as 'nearly finished' as they thought. Worker #8 packs up and joins them, now all waiting for #9.
#9 finishes work a few minutes later. They're all about to head out when #5 exclaims, "I've just remembered I need to send a quick email. I'll just be a sec". Everyone else waits. Almost an hour has passed. Worker #1 is beginning to regret even thinking about going to the pub.
As #5 returns, #4 decides to go to the toilet.
Finally, an hour and fifteen minutes after they first decided to leave, 9 people are waiting for an elevator. The first to come can't fit all of them, so some wait downstairs for a few more minutes until the next lift brings the rest.
They get to the taxi rank (these are responsible people who don't drink and drive.) They realize that since there are 9 people, they need three cabs. There is only one cab at the rank. Since they don't want to split up, they wait until three cabs are available.
They arrive at the preferred venue. They discover it's closed for maintenance. It's now 9.30 pm and nobody has yet had a drink. Every decent venue in town is already packed, and #3 now has to go home to feed the cat. The rest are tired and half-heartedly go through the options of nearby venues, slowly eliminating each. Eventually, everyone just goes home, unhappy and thirsty.
CD to the Pub
Does this sound familiar? Can you spot the software release metaphors? Do these happen in your organization? If so, you need to try Continuous Delivery. Why not practice it on your trips to the pub before using it to release software?
Let's see how it pans out:
Thirsty worker #1 says out loud: "I'm off to the pub in 5 minutes sharp. There's some spaces in the cab if anyone wants to come with me?"
Workers #2, #3 and #4 all leap up, enthusiastically, and join #1.
#5 and #6 also show interest but are a little slower. "Sorry guys, no space in our cab. You guys can jump in the next one,” says #4.
#7 says the same, as before “I just need to finish a few things off Can you wait 5 minutes?" and #8 still says "I'll see you there, I'm going to be here another half an hour at least".
Workers #1, #2, #3 and #4 get to their favorite pub a little under 15 minutes later but it's closed for maintenance. Unperturbed, they go to the place across the street and secure a table that can fit 6 people, knowing the other two are following shortly. They let their colleagues know the change of plans and they sit down to enjoy a nice cool thirst-quenching beverage.
Meanwhile #5 and #6 work out whether they're willing to wait for #7 and decide they will, since dividing the cost of a cab between three instead of two is worth the extra wait. #5 says, "I've just remembered I need to send a quick email. I'll just be a sec". He finishes his email just before #7 packs up and is ready to go.
#8 says "oh wait for me, I'm nearly finished". The other three hesitate, but then #9 says, "I'm almost done too. You three can go, why don't I split a cab with #8 when we are both done". That works out fine for the other three and they head to the pub. They arrive and take up the seats the first group had saved for them and say "By the way, #8 and #9 are coming - we should make space for them", which they do. Conveniently, the snacks that the first group ordered have just arrived too so all enjoy their drinks and snacks.
#8 and #9 arrive a little while later, and everyone has a jolly good time.
Applying this to software delivery
Can you think of examples in your company/project where this metaphor can be applied to your software delivery?
- Do you have working pieces of software (thirsty workers) that could be deployed to production (the pub) now, but are waiting for their colleagues (Monthly/Quarterly release)?
- Is the change that you deploy (group of workers) so large, that when something unexpected happens (pub closed) it requires you to sync and deploy everything again (trying to find another pub that can accommodate a large group at the busiest time)?
- Do you lose your opportunity window synchronising all development teams for a release? (Do the pubs close before your workers finally organize themselves and get out of the office)?
Can we get to Zero Waiting Time?
How can these thirsty workers get even more efficient at arriving to the pub with little or no waiting time?
Here are some suggestions:
- Find a pub that's not so far away so there's less time to get there - if they find a pub that is within walking distance they could go one by one without having any extra cost. (Assuming worker #1 doesn't mind drinking alone).
- Have a standing agreement that every evening, if people are thirsty, they just head to the usual pub when they like rather than having to organize an outing.
What about working in the pub (making changes in production)? Well, this may have long-term risks around the health and effectiveness of the workers and their company, and isn't recommended!
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.