I went to DevOpsDays Berlin on Oct 23-24. And besides giving an Ignite talk titled “Sane Secrets Sharing”, I also proposed and facilitated a session about “Minimum DevOps” during Friday afternoon’s Open Space.

The title “Minimum DevOps” was more or less taken from the October Meetup of the DevOps Frankfurt group, where we tried to answer the question of “How do people new to DevOps get started? What are the first and absolute minimum steps they need to take?”.
The Meetup’s topic was a reaction to people regularly and increasingly asking about what DevOps is and how they can get started with it.

I basically asked the DevOpsDays session attendees the same question, but this time also made an effort to gather as many opinions as possible and also record them.
The raw result is captured in the following photo and this tweet.

Result of "Minimum DevOps" Open Space Session at DevOpsDays Berlin 2014

However I want to summarize them and add context, where it may not be obvious from the pictured flipchart image.

Pick highly visible & easy to achieve first

In my opinion the best practice and advice that was shared in the session was, to carefully choose your very first initiative so that it provides a very easy to achieve but highly visible outcome.
The thinking behind this being, that an easy yet visible win, will make it easier to show the effectiveness of the measures and changes you’re looking to implement in the future.

Highly visible of course is somehow specific to each company and team. Examples that were mentioned revolved around making some metrics or monitoring data better visible or simply accessible to a larger audience and enabling that audience to do something meaningful with that data they couldn’t do on their own before. Another example is to introduce centralized logging to an important subset of your servers to enable collaboration around that logging output which was impossible before.

It’s essentially “start small” or “divide & conquer” as one participant called it. So it shouldn’t be really new to most. But it gets ignored often enough, nevertheless.

Identify what you can & can’t control

Quite similar, and especially relevant to large companies is, instead of fighting windmills from the beginning and frustrating everybody in the process, you should take a careful look at what in fact you can possibly change.

In the frenzy to use new tools and approaches on the one hand and the sometimes total helplessness of large enterprises it can be easily lost, to ask the simple question: “What can I actually change? And what is a meaningful change?”

Don’t scorch the earth before even starting, by skipping this question.

Have a Vision & Share it

Before kicking off an all too wild change-frenzy, where you start to automate X only to realize that some other part is dependent on X and has to be changed too, sit down and work out a little more than a rough idea of where you want to end up. List the benefits you’re looking to achieve as well as the main hurdles you expect while implementing the changes.

And if you don’t work on the vision with other relevant people (why actually don’t you?), then it’s a must that you share it with them at some point in time.

Once you got the vision, shared it and agreed on it’s usefulness, it’s time to pick out the first parts that you can start to automate or somehow improve otherwise.

Sharing & Collaborating on central processes

This one is somehow related to the previous ones but important enough to be mentioned on it’s own.

That’s because DevOps is not only about tools and automation but also about people & processes. Which James Fryman BTW beautifully illustrated in his DevOps Day 2: People and Process talk at the same DevOpsDays Berlin.

What is meant by the approach is that you pick some process that’s central to your organization, and that’s currently not implemented optimally. The classic example of this being deployment procedures.

Then Development and Operations people collaborate on making this process better. The important part is, that people really work together on this, share knowledge and perspective throughout the whole change process and (hopefully) experience the benefit of working together directly.

Sidenote: Facilitating Change

In most companies it’s not a simple matter of inviting people to a meeting and stating a goal of “now work together to make our deployment process better”. Instead you should probably understand first what made the current process the way it is, understand people’s motivation and desires (Hint: NVC can help you with this), and then take knowledge about those into account when considering the best way to get people to collaborate more.

Conclusion

Looking back, when I asked the question of “What is the Minimum DevOps one can start with?” I was a bit naive.

I expected answers in the sense of “Do X everyday in a week, and it will help you achieve Y”. Somehow similar to some people teaching that if you practice TDD everyday you can’t help but get better.

Of course DevOps is not one or even a set of skills that a single person can train for. It’s about collaboration. One person cannot get better at DevOps, but a team of Development and Operations people can work together in better ways to deliver value more effectively and efficiently (Thanks Alexander Schwartz for placing the spotlight on those two terms during the conference).

And the above mentioned practices and advices will probably help you get started onto this road of more and better collaboration.