Originally published at Diabol Blog
DevOpsDays is a community driven conference held worldwide. This is the first time a DevOpsDays event come to Stockholm, and even though the agenda didn’t look like the most super interesting one, the takeaways turned out quite valuable and made the conference worth attending. The audience is composed of around 50% OPS people, 40% DEV, 10% people with other backgrounds.
The event was not super focused on the technical level, as DevOps itself is more of a culture thing than just technology. This might be disappointing for some attendees, but to me, it is actually addressing the core essence of DevOps: the CULTURE.
Another “famous” theme for DevOpsDays, is their open space sessions. Unlike most conferences that are filled with tons of talks, it uses the most of the afternoon for open space discussions. Basically, open space discussions are self-organized, open, with breakout sessions people can leave and join freely.
DevOps Culture
The biggest take away from this conference, is the continuous reminder, that DevOps is a culture, not a technology. Different talks have addressed this from different angles:
Building Connections
Employees burned out is one of the many signs of a broken culture. DevOps can address the burnout problem by creating more connections. An employee usually “burns out” not because of the work itself, it is because of the feeling of disconnect, disconnect from the impact of the work, disconnect from other people from other tech teams, or even from the same team, disconnect from the overall picture of the product.
So a DevOps culture can solve some part of this problem. Developers by doing more OPS worked related to their project they are working one, OPS by ”outsourcing” some of their work to developers, it starts to create connections. In some companies it will naturally form a tribe of people that do both dev and ops work, some might call it a ”DevOps team”, but it doesn’t mean if you set up a team do both of the work, you get DevOps, it is the other way around, which is driven by culture.
Some companies go even further, as shown in the talk from Pager Duty, they require everyone in dev and ops team to take on-call responsibilities, the vivid reflection of the term ”You build it, You own it, You operate it”.
This is not an easy change, it is a hard one, The most difficult problems to solve usually are non-tech problems, they are people problems. Quoting from one slide of the Pager Duty talk:
Some changes are not for everyone
Some people who thrive in old ways will fail in new ways.
They are not trying to be jerks
Expect 10% attrition or managed exits.
Katherine Daniels, the speaker of the Etsy talk, Effective DevOps building collaboration, suggested that this connection building should cover an area that is more than the literal meaning of DevOps, bridging the gap between engineering and none-engineering. They have routine rotations, that assign developers to customer support roles for a short amount of time so that they can really see how customers use the product they have built. Countless times have shown that this helped a lot for developers to understand the real need of the customers, to solve the real problems the customers are facing, hence brings more value for the company.
Transparency
Transparency is one important part of DevOps culture. Some practical suggestions from the talks:
Open planning meeting
Open architecture reviews
Open operability reviews
Open post-mortems
Open email lists
Open slack channel
Privileges
This seems to be a topic not seen very common in the DevOps area. Privileges are something very interesting: if you don’t feel it, you probably have it. The background here is for people work in tech, it is not as diversified as many people think. According to the speaker of ”Build A Healthy Work Life/Balance”Jon Cowie, the majority of the people work in tech, falls into this category ”White, Male, Straight”. So he believes that most people work in IT, don’t feel they are privileged, because of they actually are. The minority part of tech faces many challenges that the privileged people have never thought of since the culture was formed from the privileged people, which has the majority. There are many examples:
People less privileged might be not as brave to say No to their boss, as people have the privileged, due to for example visa issues, cultural backgrounds.
They might don’t feel welcomed when facing the culture created by geeks.
They might even feel being offended when facing the jokes that do no harm in the culture of privileged people
etc, etc
This indeed has an important role to play in creating the culture that DevOps has been claiming. This is something you can not pretend that it does not exist. You can admit it is something exists but you don’t understand, and you can, of course, be open and embrace it, the only thing you can not do, is to ignore its existence, because ”that kind of makes you an ass*e”, quoting from the speaker on this topic.
Talking
There was an inspiring talk from Peter Varhol from Dynatrace about “Talking”. Talking to each other is the most basic and original way of communication between humans, yet it is actually a very powerful one. Comparing with modern tools, like e-mail, chat, etc, what is said, is said, it is immutable, you don’t have too much time to phrase your talk when you talk to a human. Talking motivates people to think spontaneously, hence creating innovative discussions. It is not like modern tools do not allow spontaneous thinking, but like with chat, people tend to spend more time phrasing themselves before sending the message, which to some degree, discourage the brain to think spontaneously.
So encourage people to talk to each other on the same team and among different teams, is a very important way in creating DevOps culture. This is why many companies believe doing off-sites, kickoffs, company breakfast/lunch/dinner, meet-ups, conferences, etc, will create more chance for people to talk to each other and many discussions will lead to creative solutions.
Open Spaces.
Open Spaces itself is a great way to organize discussions but in my opinion, on this occasion, it can be done better. There were not so many topics and to my observation people were not very engaged.
The biggest take way from open space though is that most people hate Jenkins and it is a monster. People got stuck to it, only because there is no better solution. This might be a big opportunity for creating a tool that solves the problem in a better way.
Jifeng Zhang