Tag: event

Devopsdays Berlin 2018; recap

The sixth edition of DevOpsDays Berlin was held over the 12th and 13th of September 2018, and despite the fact that it’s one of the most consistent, longest-running Devopsdays events on the calendar, this year was my first ever opportunity to attend. The tl;dr is that this was a very fine event, and the local organising team clearly has their act together (though they are actively recruiting for new volunteers).

The talks were not recorded, so for the benefit of those who couldn’t make it, I’ve refined my notes from the talks on Day 2 (unfortunately I had to miss Day 1).

Dirk, on trust

The day started with a presentation from Dirk Lehmann of SAP entitled “Trust as Foundation of DevOps”. Dirk has been a DevOps practitioner and booster for years, and I’ve had the pleasure of seeing him speak a handful of times before – as usual, he didn’t disappoint. The central thesis of this talk is right there in the title: that trust, that fickle, difficult, human emotional thing, is the fundamental element of DevOps. He proposed a few ways to think about trust beyond a philosophical concept, and introduced a way of measuring the level of trust within an organisation: by measuring speed. Fast decision making, execution, and turnaround are hallmarks of a trust-based organisation. In terms of fostering a trusting environment, he proposed three key elements: managing team size, cultivating diversity, and embracing “positive failure culture”.

Regarding team size, he looked to the seminal Mythical Man Month, as well as the work of evolutionary psychologist Robin Dunbar (see: Dunbar’s Number). Dirk’s conclusion? 15 people is the largest a team can get before it it breaks – and often it should be smaller. Concerning diversity, the take-away was that teams should organise around projects, products, or goals, instead of the traditional “business unit” (or work-type silos) that have been commonplace for much of the post-industrial era. Finally, citing Google’s research that investing in psychological safety – more than anything else – was critical to making a team work, Dirk argued that embracing failure as a learning experience is paramount.

Yuwei, on mentoring

The next talk was by Yuwei Ren, a Production Engineer at Facebook, entitled “Mentorship: From the receiving end”. Despite the title, most of her talk was about mentorship from the perspective of the mentor, and it was chock full of good tips for anybody engaging in a mentoring relationship.

For example, as a mentor, how do you get off to a good start with your mentee? Start by establishing career goals, and then ask “How can I help get you there?”. Ensure that the expectations are set, and that outcomes are clearly defined by both parties. This is done by establishing a plan to achieve those goals, and setting up milestones along the way. During the process, schedule regular check-ins, and stick to them! Set the bar high, and along with those lofty expectations, make sure that both parties are accountable to each other. The mentor/mentee relationship is a big responsibility, and it must be treated with respect and commitment.

Both parties must acknowledge that disagreements and misunderstanding are inevitable, so empathy is key. Assuming good intentions is important, but that’s only the first part of the equation – both parties need to actively listen and respect each other both professionally and as human beings. Finally, the mentee needs to take responsibility for their career, actively seeking and providing feedback, and acting on the advice of the mentor.

Ken, on DevOps transformations

Next up was Ken Mugrage of Thoughtworks (and fellow member of the DevOpsDays global core) with a talk entitled “Want to successfully adopt DevOps? Change Everything”. His talk was very dense, and to be honest I didn’t quite capture all of it. His four key points to successful DevOps adoption were: redefine words, change your organisation, change your architecture, and use CD to safely deploy more often.

Within a team specifically, and an organisation in general, agreeing on specific definitions is critical. In terms of defining the word DevOps, Ken argued that DevOps should not define a toolset, nor a role, nor a team. Instead, DevOps is verbs: developING and operatING. If you need a noun, why not CAMS or CALMS (upon which much has been written before). Ken then offered his interesting description of DevOps:

A culture where people, regardless of title or background, work together to imagine, develop, deploy, and operate a system.

Words are important, but action is critical, and the best way to implement CA(L)MS is to change how your organisation is, well, organised. Ken invoked Conway’s Law and by way of illustration, explained how just renaming the Ops Team to DevOps team isn’t going to help (nor is any other action that just leaves silos in place). Teams need to be organised differently, which means that the whole organisation might need to be organised differently as well. Furthermore, the success of those teams must be measured by how they deliver business value (not just whether their software functions or not).

Ken then moved into continuous delivery versus continuous deployment, and this is where things got fuzzy for me.

Sponsors!

Three sponsors had an opportunity to say a few words on stage: Chef, Google Cloud, and Quest. I mention this because it’s important to acknowledge the important role that sponsors play in the DevOpsDays series – without them, the events simply wouldn’t be able to happen. Thanks, sponsors!

Tiago, on Microsoft

The final full presentation of the day was from Tiago Pascoal from the Azure DevOps Customer Advisory Team, speaking about how a unit within the Microsoft empire experienced its own DevOps transformation. This one started slow, but once Tiago got going, it ended up being very interesting – so I’ll skip right to the good stuff.

Within the Azure DevOps unit, teams are assembled into 10 to 12 person groups, the composition of which is heterogeneous and organised around products (see: Dirk’s argument above). These teams are self-forming, so everybody decides which team and/or manager they want to work with. Apparently, while 100% of the group gets a choice, typically less than 20% choose to change from their existing situation. (To me, this is wild, and I’d be very interested to try something like this out at some point in my career.)

Tiago invoked Daniel Pink’s popular book Drive, noting that need teams 3 things: autonomy, mastery, and purpose. He added another layer, which he referred to as “Alignment vs Autonomy”. Autonomy is everything related to planning and execution,  whereas alignment is the organisation, the team structure, and most importantly, the cadence of work. For example, they work in 3-week sprints, and at the end of the sprint, whatever is in the master branch gets deployed – so be ready.

At an organisational level they track metrics; but NOT the classics like burndown, velocity, original estimate, completed hours, team capacity, or number of bugs found. Individual teams can track those if they wish, but at a high level there’s only one metric that matters: impact. Are they delivering value? Speaking of measuring, in terms of code quality, Tiago explained the “Bug Cap”: n * 5 = x where n is # of engineers, and x is maximum bug limit. If the bug count exceeds the bug cap at any time, the team stops working on new features and moves immediately to stabilise. Neat!

Ignites

After lunch, it was time for everybody’s favourite DevOpsDays tradition: the ignites! I was preparing for my own ignite so I missed the first one (sorry).

Daiany, on relaxing at speed

This was an excellently-delivered lightning that told the (true?) story of two teams and their relative stress levels heading into the GDPR cut-off date. It was fun, light-hearted, and carried a strong message: when you’re doing the DevOps at high velocities, even massive EU legislation can’t stress you out! Well done, Daiany.

Daniel, on serverless

I did a lightning talk on serverless. It was fun. 🙂

Thanks!

First off, thanks to the local DevOpsDays Berlin volunteer group. Also, thanks (again) to the sponsors. Finally, thank-you to my employer, Datadog, for sending me out there to speak. There are so many moving parts to make even a small conference happen.

I hope to make it out next year!

LCA, the event that was

Linux Conf Australia 2013, (alias linux.conf.au, alias LCA) was an amazing experience, and it’s difficult to summarise it succinctly, but there are definitely some highlights and important take-aways that I’d like to make special note of.

My fundamental reason for attending was that Ben Kero and I were invited to do a talk regarding Puppet (an important infrastructural tool that we use at Mozilla).  The talk, like all of the presentations given by Mozillians at LCA this year (and there were more than a few), was very well-received, and delivered to a packed auditorium – in fact, people had to be turned away at the door beforehand !

Since our talk bumped up against the lunch period, we had occasion to stay in the space and launch an informal panel discussion that included other Mozillians as well as representatives from a number of other Open Source companies and organisation.  We engaged on a variety of topics, ranging from IT-centric to questions about the future of the web, and the importance of open standards and market competition.  It was only when the organisers forced us out that the auditorium was finally cleared.

Interestingly, from the moment I arrived in Australia, and through until the very last day, I found myself acting as an ambassador for Mozilla.

For example, a day before the conference even started, I was part of an informal debate concerning the future of mobile and the importance of FirefoxOS within it.  Other participants included a Ubuntu employee and a number of hardware hackers who – as it turned out – were already trying to port FirefoxOS to other types of phones.

Another example even occurred at a local cricket match.  I was wearing my Firefox T-shirt (which usually generates interest), and ended up doing a some impromptu demos of Firefox for Android to a couple of different groups – the highly satisfying result was that a handful of people downloaded and installed it on the spot !

These, and more, are all opportunities to engage people about Mozilla, and in many cases, to introduce our values and mission to entirely new audiences.  During this and other conferences, I’ve found that even long-time users of Firefox and Thunderbird (for example) are often not even aware of who and what Mozilla is, and what we’re about.  I try my best to be a good ambassador, and I’m proud to represent the organisation wherever, and whenever I can.

From a personal perspective, the conference had two major benefits: it was an excellent learning experience, and a fantastic opportunity to spend time in-person with a number of my co-workers in the IT/Ops team.

Of note, I had the pleasure of attending a number of talks and presentations about technology that we use in our environment that have had a direct impact in my work-flow already.  Beyond the directly-applicable benefits, I was particularly inspired by a presentation about programming for embedded devices (shout-out to Bunnie Huang) which, due to peculiar technical constraints, requires a very precise and measured approach to development.  These ideals could – and should – be carried through outside of the embedded world.

In summary, LCA 2013 was an excellent opportunity to learn, teach, and engage the public concerning technology in specific, Mozilla in particular, and open source in general.  I’m already looking forward to next year !