DevConf.cz 2021

During the last five years, the speakers gained experience in an enterprise environment on their DevOps missions. In two separate teams, they came across two similar problems.

At a first glance, the new freedom of tools, languages and frameworks felt liberating. But it quickly let to efficiency traps and unevenly distributed knowledge inside the team.

Secondly, most of the corporate templates for architecture documentation just did not suite their context and toolset. So instead of using long word documents, they started to experiment with a docs as code approach.

You will learn from first-hand experience how to prevent these problems, no matter if you are just starting out with DevOps, or if you are already getting your hands dirty. We will share some tool tips with you to increase your speed and comfort on the track with DevOps.

Do you know how many work items are there in your team's backlog right now? How many items your team is working at the same time? How many items are YOU working at the same time? If you limit your work in progress you can deliver more. Yes, that's right. These limits are not there to limit your progress, in fact it is quite the opposite. I this talk I want to share with people that understanding, visualizing, managing your workflow and having Work-in-progress limits can help you deliver more.

This session will go over how to make your scrum process friendly for a remote setting. Scrum thrives in settings where everyone is co-located but in the digital world we can not assume that teams working in the same office is the standard. How can Scrum work for your team when its now remote? Its simple! Tailoring the processes to meet your teams needs will allow you to continue working without reinventing the entire wheel. In this talk we will go over what our new remote norm looks like, what scrum is, steps to consider when tailoring, and tips on how to tailor some of the process based off of real world experiences working with remote scrum teams.

As SRE (Site Reliability Engineering) teams contain a fair portion of software development work, and get filled up by software developers, it is a natural move to also adapt agile software development practices. The right agile model depends heavily on the percentage of development work vs. operations, which may be influenced by the team size. For example, in a small team where a high percentage of people is on call during the day, it might not make too much sense to plan sprints of 2 weeks if only a few backlog items are expected to get done in that timeframe.

Audience
This talk is targeted at everyone involved in Site Reliability Engineering, wondering how much agile to adopt - team leads, product owners, software developers, SREs. If you're planning to transform your ops team into an SRE team, your SRE team just got started, or already do SRE since quite some time. As a software engineer who recently joined SRE, I will talk about which practices I found useful to take over from software engineering, which ones are better dropped, and which ones I'm still missing sorely.

Agile Practices
Retrospective
While often being the first meeting to get dropped by teams as the relation to actual work items cannot be seen easily, the retrospective meeting is the tool for teams to iterate on how they work and improve, including which of the agile practices make sense to adopt it which don't.

Planning: Estimating Backlog Items
Planning meetings help the team understand priorities of items, the overall direction a project is heading and get a common understanding of how complex work is (with estimation). However, given a (not known) number of people is on call or doing incident response makes it hard to set sprint goals or commit to a consistent number of stories.

Standups
Standup meetings are useful, especially in distributed teams, to talk about what you're working on and where you need help. Frequency of the meeting does not necessarily be daily - and that hit me as software engineer unexpectedly hard.

Testing
If your SRE team is writing software, that software should be tested. No room for discussion.

That's what the software engineer might think - but you need to discuss. You need to convince your team testing is helpful. And that's as equally hard in an SRE team as in any software engineering team.

Pair programming
It's hard to convince people pair programming is helpful, and it isn't helpful in every situation - but confidence in code as well as operations changes (in an outage for example) is so much higher when working in a pair.

Key Takeaways
During this talk, attendees should have learned (1) that SRE and software engineering likewise benefit from agile development practices, of which at least (2) some practices are worth to adopt while others may not be too helpful for SRE. (3) Which ones are and are not helpful can be the easiest spotted by iterating not only work but also how we work (practice retrospectives).

Scrum has an often unjustified reputation among developers for being a heavyweight framework, with ceremonies designed to ultimately guide a product which can incur a lot of meeting time and commitment to maintenance of tickets, backlogs and requirements documents. Lean looks primarily at waste elimination and in a world that has found itself forced into a work from home culture, Scrum teams are now generating a lot of waste as they adapt their processes to be remote friendly. This is on top of any bad habits that formed around their flavor of Agile. With teams finding themselves experiencing meeting fatigue and drowning in process, the question needs to be asked, how Lean is your Scrum? Join me in this session where we look at the application of some Lean principles to Scrum and showcase the improvements at both a process and team happiness level that resulted from applying them in our remote Agile team.

Red Hat has a long history of remote working, with over half of the workforce long term remote. With covid-19, the vast majority of the company, along with the wider world, have found themselves working from home. Our team, which serves the Open Source communities for Fedora and CentOS, are almost exclusively remote, following our own flavor of Agile which is primarily focused on Scrum, but taking in aspects of Lean and Kanban. Our processes were born remotely and despite that, the pandemic pushed our meeting workload and our team health to the limits. We took a renewed view of the Lean principles that underpinned our processes to make adjustments to how work flows into the team, how the team organises themselves and how we work and live day to day. This session explores some Lean principles that are easily applied and complimentary to Scrum.

Red Hat's CKI ("cookie") project started out as a Jenkins proof-of-concept to show that kernel testing can be integrated into the kernel workflow.

Today, CKI provides all the infrastructure that stands between a merge request for a Fedora/CentOS/RHEL kernel repository on gitlab.com and the green check mark that signals that it can be merged.

Join us in our journey of how a bunch of engineers (that couldn't spell DevOps correctly) learned to operate a fast-moving resilient service used by kernel developers in their daily work.

We will talk about:

How we keep the CKI service up and running by
- using a state-of-the art logging, monitoring and alerting setup
- being persistent in the case of transient failures
- reducing single-point-of-failure

How we make it easy to modify the testing pipeline by
- running canary pipelines for unmerged code

How we make it safe to hack on the underlying infrastructure by
- dividing the backend infrastructure into microservices
- automatically deploying testing versions for merge requests
- automating production deployments

My heart skips a beat every time there's the *new tool that will solve your DevOps*. Working in a team, one can realize fairly fast that the tooling is not the problem most of the time. People are. In this talk, I want to zoom in on the possibilities of building a DevOps *culture*, instead of investing millions into tooling and wasting the time of people constantly re-learning new tools.

Agenda:
- The rabbit holes of DevOps
- No, DevOps is not a single person working for two
- Don't pick what you want, pick what you need
- Tools don't work autonomously - one tool at a time -
- How automation wastes time in certain situations
- Make a consensus

Want great open source technologies? It takes a great team! Enter Bruce Tuckman's phases of team development - a model that's stood the test of time because it remains highly relevant and beneficial. If you are a leader (or aspire to be one), a member of a team (or may be in one in the future), or are just looking to develop your skills, this unique talk (based on Tuckman's model) will give you a practical framework with actionable tips for working in and leading teams successfully. You'll learn about the five phases - Forming, Storming, Norming, Performing, and Adjourning - including detailed descriptions of each along with proven strategies for addressing challenges or issues which may occur along the way. You'll understand how to use the model to your advantage by effectively navigating all of the phases, from team set-up to the after-party!