Beginning Continuous Delivery

After finishing The Phoenix Project, I was on a high. I was sharing every highlight from my Kindle app with every person I talked to. I kept referring to the book whenever we realized there was an inefficiency in the way we were working. Before I talk about Continuous Delivery, I want to share some of those highlighted passages and why they resonated with me. Some of these quotes would make me bust out laughing, because it felt like they were documenting what I had seen around me, not adding comedic rests to a fictious narrative.

• Practically every executive in the company is guilty of going directly to their favorite IT person…
  • This didn’t stand out to me so much about the executives, but the lack of rigor in following the process. DevOps, and Continuous Delivery along with, are not so much about tools as they are about rethinking your process. The way we traditionally have developed and delivered software has become less and less effective compared to the expectations we have for ourselves. This quote stood out to me, because executives are in charge of running the company effectively, and yet they were undermining themselves. It just shows that when your place needs some DevOps, you’re often already quite unsatisfied with doing work according to your existing processes. It’s just not efficient enough to get you there.
• Remember, any improvement not made at the constraint is just an illusion, yes?
  • If you don’t look at your system of work in entirety, from idea to delivery, across team and organization boundaries, you could very well be optimizing a section of the pipeline without any real impact to the business or the consumer.
• Unplanned work has another side effect. When you spend all your time firefighting, there’s little time or energy left for planning. When all you do is react, there’s not enough time to do the hard mental work of figuring out whether you can accept new work.
  • Oh how true this is. How many a stressed, frantic Ops person I have talked to that thinks prioritizing or grooming their backlog is futile, because they won’t get to work on it any way, there’ll be another alarm before the grooming meeting is over.
• Improving daily work is even more important than doing daily work.
  • This, and a direct mention of Jez Humble et al. who have gotten the Continuous Delivery conversation really roaring, really got me thinking about where can I attack our current inefficiencies. Software rusts, entropy is a law of the universe. So if you’re not continuously improving the way you do your daily work, you’re guaranteed to churn out less and less quality stuff as time progresses.

So when I finished reading, I was immediately ordering the Continuous Delivery book from Jez Humble, the next morning I was watching his talk from 2013, and now I’m off. I have a new hero, this guy is describing all the problems I see around me, and he has an answer I can’t wait to go and try. Next post will probably be on how that first attempt to employ some of his techniques go. I have a hunch, though, that it’s going to be in the realm of Continuous Integration. If you’ve watch the aforementioned talk, I might have already ordered a rubber chicken and a bell.