Forem: Jayne Groll

Premier DevOps Upskilling Event and Celebration: Global SKILup Festival

Jayne Groll — Tue, 24 Nov 2020 22:49:17 +0000

2020 has been the year focused on the human. As the pandemic unfolded, the Humans of DevOps worldwide did their part to help mitigate the many challenges we faced. We are grateful to the tech community for their tireless efforts in helping individuals and organizations adapt to the new ways of working in new and non-traditional ways.

After a long year, DevOps Institute wants to honor our member community and partners by coming together like never before. We’re hosting a week-long celebration 100% dedicated to advancing the Humans of DevOps from December 7–11: Global SKILup Festival 2020!

The premier DevOps upskilling event and celebration is not your traditional conference. The agenda will include a variety of different activities that focus on social, professional, and educational experiences. It also features a deep-dive into technology trends and presents career advancement opportunities. The world’s first such unique festival will take place virtually, and is sponsored by industry leaders Rancher, AppDynamics part of Cisco, CircleCI, Moogsoft, CloudHealth by VMware, Harness, and Epsagon.

Want to learn more about DevOps?
Then this premier DevOps upskilling event is for you! The festival runs continuously worldwide and includes a career fair, certification opportunities, courses, hackathons, our ever-popular Global SKILup Day conference, and more! The 2020 event also features keynote speakers Mirco Hering, Global DevOps Practice Lead / ANZ Modern Engineering Practice (Managing Director) at Accenture, and Patrick Debois, Director of DevOps Relations at Snyk.

Check out the rest of our speaker line up as well.

Workshops, Hackathons, and Certifications
Many of our partners, sponsors, and DevOps Institute Ambassadors are running seminars, hackathons, and certifications throughout the week. We recommend attendees start planning their schedule and save their spot by checking the agenda and signing up in advance.

SKILup Careers Fair
Network with HR and hiring representatives and discover DevOps career paths at leading organizations worldwide. Hear from the hiring leaders themselves which skill sets are most important. Explore emerging and available DevOps roles.

Get SKIL’d Up Days
Enjoy learnings on gamification, LEGO Serious Play, Kubernetes, Relationship Agility, and more! You’ll also have an opportunity to learn more about DevOps and get certified with one of our education partners (advanced registration is required).

On Wednesday, join us for the Global SKILup Festival DJ Party — send us your song requests and celebrate with us!

We’ll end the week with this one-day conference where you can listen and interact with speakers worldwide as they share their stories and experiences with you. You will have the opportunity to ask questions in the ‘meet the speaker’ sessions and join in some great discussions.

We look forward to celebrating with you soon!

Want continuous delivery? Get agile with change management

Jayne Groll — Tue, 22 Oct 2019 18:26:58 +0000

As organizations move towards a faster flow of automated software delivery, agile change management has become imperative. So how do you achieve it?

Change management controls the gateway between development and deployment. It does not assess the technical worthiness of a change, nor does it build, test, and deploy a release. Its objective is to control, manage, and mitigate the risk of changes to the production environment.

Many change management processes were designed when waterfall development was the norm, and when governance, risk, and compliance were key objectives for IT. To evaluate risk, organizations stood up change advisory boards (CABs) as a decision-making authority and typically met weekly. All proposed changes had to be accompanied by a request for a change in advance.

At the time, IT operations were focusing on change control, while development was exploring the faster, more iterative, and incremental approach of agile and Scrum. Agile software development paved the way for DevOps and continuous integration (CI), continuous delivery (CD) and continuous deployment. With DevOps, the focus shifted from controlling changes to expediting releases.

Despite that, change management remains an essential process.

The CI/CD model does not eliminate the need for controls and change data. In fact, faster, more frequent deployments mean even more change and risk. Regulatory controls and audits still exist. You must manage risks, whether it’s the risk of making the change or of not making it. Most importantly, everyone in IT should always be able to answer the question “What changed?”

The problem is that while today’s software delivery processes can deliver faster and more frequently, the rigor and limits of traditional change management can seem like a frustrating constraint. If you apply the Theory of Constraints, efforts to improve the adaptability of change management to the CI/CD model of app development would likely result in improvements to the end-to-end value stream.

So how does your organization adapt its change management practices to meet the ever-evolving, faster pace of continuous delivery? Here are two key steps.

1. Change your mindset
The first step is to move away from a one-size-fits-all strategy. The cadence of change is not the same for all products or circumstances. The risk profile for complex changes to monolithic applications is likely not the same as the risk profile for updates to smaller microservices.

Consider creating models for different types of changes and how they are handled. The models will define the policies and procedures for each category of change based on risk and required rigor. The model might also clarify the request/approval process, appropriate decision authorities, testing requirements, release procedures, remediation, timelines, and documentation.

The most common model is for “standard changes”—those that are pre-approved, procedural, and low risk because of a strong track record of success. For instance, releases that pass through the CI/CD pipeline could be authorized as “standard” because of the consistency of the build process, testing, deployment, and documentation that is inherent in the toolchain.

2. Become agile
Next, take a page from software developers and instill agile thinking into the change management process. The Agile Manifesto highlights the values that should be important to all IT professionals. It demonstrates that it is more important to “be agile” than to “do agile.” Most importantly, it reminds developers that while the artifacts on the right are important, they should not prize them over the outcomes on the left.

Both the Agile Manifesto and Scrum Guide encourage software engineers to have “just enough” structure, accompanied by a small set of rules. Examine your change management charter. Do the activities inadvertently emphasize the artifacts (e.g., request for change) over the outcomes (working software)? How much is “just enough” change control for your organization?

Also review your change management documentation requirements. Too many organizations require substantial information in the request for change before the CAB can accept and review it. Which is more important, the request for change or the change record? One shows intent while the other shows activity.

Determine whether the information necessary to assess and support the change is available somewhere else, such as a configuration management tool, source code repository, or defect ticketing system. It may be possible to join or auto-populate that information into a central, dynamic change record without spending time replicating it. In addition, many of the tools in a continuous delivery pipeline produce logs and reports that not only provide data about the change, but also confirm evidence of controls.

Who decides?
Finally, consider designating a hierarchy of decision authorities that aligns with your change models. Decision authorities can range from product-specific peer reviews to local change control boards to full-on enterprise CABs. Each decision authority needs to have clear approval thresholds and a well-defined escalation path.

You could designate special decision authorities for circumstances such as emergency changes or standard change designations. A multi-tiered change approval process can result not only in faster and more frequent deployments, but is likely to result in better conformance and documentation.

Time for a sea change
Adapting change management to continuous delivery is as much cultural as it is procedural, as much human as it is technical. So solicit input from developers, release engineers, and stakeholders about what they like and do not like about your current change management process. Consult auditors and other regulators to ensure continuing compliance. Do an experiment: build a model for a small set of automated changes. Then learn from the experience, improve, and repeat.

How ITIL4 and SRE align with DevOps

Jayne Groll — Fri, 04 Oct 2019 16:35:15 +0000

In the early days of DevOps, there was a lot of debate about the ongoing relevancy of ITIL and IT service management (ITSM) in a faster-paced agile and DevOps world. Thankfully, that debate is coming to an end.

ITSM processes are still essential, but, like all aspects of IT, they too must transform. Recent updates to ITIL (ITIL4), as well as increased interest in site reliability engineering (SRE), are providing new insights into how to manage services in a digital world.

Here’s a look at ITIL4 and SRE and how each underpins the “Three Ways of DevOps,” as defined in The Phoenix Project, by Gene Kim, Kevin Behr, and George Spafford.‎

ITIL4 is the next evolution of the well-known service management framework from Axelos. It introduces a new Service Value System (SVS) that is supported by the guiding principles from the ITIL Practitioner Guidance publication. The framework eases into its alignment with DevOps and agile through a bi-modal approach that retains many of the activities from previous versions but acknowledges DevOps practices such as value streams and continuous delivery.

Site reliability engineering
Site reliability engineering (SRE) is Google’s approach to service management, introduced in a book of the same name. It is a post-production set of practices for operating large systems at scale, with an engineering focus on operations.

SRE is “what happens when you ask a software engineer to design an operations function.” It is both a role and set of practices that have attracted the interest of large enterprises as an adjunct to agile teams and DevOps automation practices.

The three ways of DevOps and ITSM
Automation is essential to improving flow and service quality. Previously, ITSM automation was used primarily for record-keeping and monitoring. In the digital age, most ITIL4 processes will be underpinned by tools, particularly during transition and operation processes as part of continuous testing and delivery.

Automation is inherent in SRE because it is an engineering practice for operational service management. SREs can code, and therefore will make pervasive use of automation to manage reliability and reduce manual work known, in Google-speak, as toil.In addition to automation, these other steps are crucial.

Increase flow and reliability through change management
The crossroads of agile, DevOps, and ITSM forms the cornerstone of change management. Simplify current change management practices, and you can increase flow many times over.

ITIL4 and SRE take very different approaches to change management. In SRE, the team is given an error budget that represents the gap between perfect reliability and agreed service level objectives (SLOs). While the team is allowed to regulate its own workload, there are policies and consequences that govern what happens if an error budget is blown or service levels breached. Since error budgets are meant to be spent, the team can make autonomous decisions to increase flow.

ITIL4 has a stronger emphasis on governance and change approvals. The newest guidance now provides different options for assessing changes based on the change category, ranging from a central decision authority to peer-to-peer reviews.
By definition, the purpose of the ITIL4 change control practice is “to maximize the number of successful IT changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing a changing schedule.”

ITIL4 does support the use of automation and rapid decision making to expedite change decisions.

Shorten feedback loops by improving incident response
The best way to shorten feedback on the quality of a product or service is through incident management. Fewer incidents equal higher quality.

Both ITIL4 and SRE refer to incident swarming — a model of networked collaboration — as a means to provide simultaneous and fast engagement to reduce the time and impact of a significant incident. Monitoring systems and dashboards visualize the current state and can be shared with key stakeholders. ChatOps systems open engagement opportunities for collaboration, input, and feedback on past, present, and even predictive incidents.

Since SREs are an established role with direct access to developers, feedback on both sides can be fairly continuous. SREs also have the technical ability to diagnose and potentially fix incidents independently, so the ability to capture knowledge at the source is shortened. For its part, ITIL4 advocates for the breakdown of silos — capturing knowledge at the source — and emphasizes the importance of recording incident activities.

Foster continuous learning and experimentation
DevOps encourages a culture of experimentation where “fail fast and learn fast” are the keys to practice, mastery, and improvement. This principle is supported by ITIL4, SRE, and virtually every agile and ITSM framework. The spirit of continuous learning and improvement is embedded in every ITSM activity. In SRE, failure is an opportunity to improve. In ITIL4, “improve” is called out as a value chain activity.

Process skills are critical to DevOps
The DevOps Institute’s recent Upskilling: Enterprise DevOps Skills Report proved that process skills are statistically equal to technical and soft skills in the current talent landscape.

It is interesting to note that the upper half of the “must-have” process skills do not map to a specific framework or method. These are higher-level, critical process skills that can be applied universally in the management of products and services. While still strongly “nice to have,” experience with frameworks such as ITIL, Scrum, and project management was not considered essential by the 1,600-plus respondents to the survey.

Which service management framework is right for you?
Both ITIL4 and SRE have their merits, and both claim to support the DevOps in three ways.

Culturally, SRE is more aligned to DevOps values and agile principles in encouraging self-organization, error budgets, smaller and faster increments, and an engineering mindset. You can also hire SREs.

ITIL4 promotes a more command-and-control-oriented structure than do DevOps and agile, but it hints at closer alignment. However, for traditional organizations that are not ready to take the leap from change control to self-organization, ITIL4’s bi-modal approach may be attractive, if not sustainable for the long term.

Regardless of the framework you choose, it is imperative that you adopt an agile service management mindset to determine how much is “just enough” or “minimally viable” process for the business.

Either way, IT service management is here to stay.