As those who know me or have seen me speak at a conference know, I'm a big fan of DevOps practices. I'm also a big fan of automation. After spending a couple of years digging into the topic, practicing it and talking about it with people from all around the world, I thought I'd share some of my own thoughts and experiences on the topic.
This article is the first part of an ongoing series.
If you're at a shop who've been around for a while, have successful software in production and by every meaningful measure is doing great, then you'll probably have quite a hard time convincing anyone of the need to pivot towards DevOps practices.
That, however, does not mean that you should stop or that your workplace has nothing to win from embracing DevOps practices. It just means that you'll have to take another approach than the blank-sheet-of-paper-startup-unicorns you read about on the internet.
You don't have to make a big sell and convince everyone of the benefits of a DevOps approach. In fact; You shouldn't. You will thank yourself later for not trying.
Start small, in your own team. Choose a couple of practices you think would bring value to your team, experiment and evaluate whether they had the impact you where looking for.
Sooner or later, word will get around about how your team is improving, and with that; other parts of the organization will want to know how you did it.
So, to summarize:
- Start simple, start small.
- DevOps takes time.
- Short-term improvements, while being great morale boosters, mean nothing in comparison to the long-term gain.
- Prioritize your experiments by their (potential) velocity increase.
- Define measurable goals before starting your experiment.
- Evaluate and keep doing what works.
- Stop doing, or change, what does not.
- Stay humble.
Thank you for reading. 🙏🏼
If you enjoyed this article, click the ❤️ button and subscribe to make sure you won't miss the next part.