{"id":4051,"date":"2024-04-15T08:06:51","date_gmt":"2024-04-15T15:06:51","guid":{"rendered":"https:\/\/www.microsoft.com\/insidetrack\/blog\/?p=4051"},"modified":"2024-04-15T10:06:52","modified_gmt":"2024-04-15T17:06:52","slug":"devops-is-sending-engineering-practices-up-in-smoke","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/insidetrack\/blog\/devops-is-sending-engineering-practices-up-in-smoke\/","title":{"rendered":"DevOps is sending engineering practices up in smoke"},"content":{"rendered":"

\"MicrosoftWhen it comes to modernizing how software engineers write their code, sometimes you just have to light things on fire.<\/p>\n

Just ask James Gagnon.<\/p>\n

He\u2019ll tell you that good engineering teams at Microsoft and in Microsoft Digital are driving towards using DevOps to do their work, and with good reason.<\/p>\n

\u201cDevOps is a foundational part of actually achieving digital transformation, of becoming truly agile,\u201d says Gagnon, a software engineering lead on the Microsoft Digital team delivering finance applications inside Microsoft.<\/p>\n

Moving to DevOps can be as simple as combining software engineering and support roles, then delivering smaller software increments. That seems easy enough, but here at Microsoft, Gagnon and others driving this kind of transformation often find that organizational boundaries, team culture, and business processes must also evolve to get people to buy into this modern approach to engineering.<\/p>\n

Gagnon has seen this story play out over the last six years.<\/p>\n

\u201cThere is no doubt that implementing DevOps will increase the speed and quality of software delivery, but it will cost you everything if done in isolation,\u201d Gagnon says.<\/p>\n

Leaders must burn old practices<\/strong><\/p>\n

\"James
James Gagnon is driving his teams\u2019 DevOps transformation inside Microsoft Digital. He is a software engineering lead on the Microsoft Digital team delivering finance applications inside Microsoft. (Photo by Jim Adams | Inside Track)<\/figcaption><\/figure>\n

\u201cDevOps thrives with increased autonomy,\u201d Gagnon says. \u201cEmpowering teams to measure, deliver, fail, learn, and improve internally will yield greater outcomes. Leaders that measure outcomes over execution governance will give their teams the freedom to innovate while taking greater accountability of their work.\u201d<\/p>\n

Gagnon says that team productivity measures and processes such as sprint burndowns, velocity, work in progress limits, and story pointing must be private to the sprint team<\/em>. He says leaders should enable these basic practices and ensure they are in place, but they should also make sure the data stays with the team.<\/p>\n

\u201cThis creates a safe environment to reflect and enables continuous improvement,\u201d he says. \u201cLeaders that create aggregate reports and force specific practices will create a culture of gamification. Reports and scorecards will become more important to the engineers than the outcomes and the customers.\u201d<\/p>\n

Leaders who control and over-centralize solutions will frustrate engineering teams and impact their ability to deliver working software with agility, Gagnon says.<\/p>\n

\u201cDevOps transformation starts with software transformation and culture transformation,\u201d he says.\u00a0 \u201cThe sprint team knows best the debt that is impacting the team and is best suited to partner with business and leadership to define the roadmap.\u201d<\/p>\n

Delivery of schedule driven projects is a legacy success metric of the waterfall software delivery lifecycle. Gagnon has been part of this and learned the hard way that it doesn\u2019t work.<\/p>\n

\u201cI\u2019ve seen the perfect software engineering storm and it was a long nasty ride,\u201d he says. \u201cLeadership had set a date for achieving transformation. The engineering team changed structurally with new undocumented expectations. Engineers had to modernize monolithic legacy software, originally built on a tight budget, all while success was measured by new business feature delivery and quality. Unfortunately, leadership was the first and only thing to change.\u201d<\/p>\n

How it works\u2014the UAT example<\/strong><\/p>\n

User Acceptance Testing (UAT) is one of the areas causing excessive toil when moving to an agile or modern engineering culture, Gagnon says. Many times, these legacy software engineering practices have been part of the release process for years and compliance validation or other factors required the business stakeholder to review and approve changes. When left in place, this conflicts with the goals of DevOps in general.<\/p>\n

\u201cThe UAT process alone has huge implications in our ability to move towards DevOps, it\u2019s simply not compatible. Engineering of the current feature sprint can\u2019t stop while UAT happens for the previous feature sprint,\u201d he says. \u201cThis is supposed to be faster, right?\u201d<\/p>\n

The changes required to move away from UAT need to happen both in engineering teams and the business teams.<\/p>\n

\u201cEngineers must take full accountability for quality and business stakeholders must be integral to the process,\u201d Gagnon says. \u201cAchieving the agreed upon success criteria defined at the beginning of a sprint must be demonstrated by a simple sprint review as part of closing the sprint.\u201d<\/p>\n

Not only does a UAT process slow down agile methodology, it creates code line management complexity, he says. This requires a separate integration step, an additional branch, and slows down development with increased cost.<\/p>\n

\u201cModern engineering can\u2019t be achieved when managing branches that map to legacy process,\u201d Gagnon says. \u201cWe must deliver to production what was engineered within the same sprint.\u201d<\/p>\n

People make it happen<\/strong><\/p>\n

Just as culture needs to transform, the software engineers who make up that culture do as well. At Microsoft it started by combining the development and testing role, and now the company is merging the service engineering role into this DevOps role as well.<\/p>\n

\u201cThe goal is to drive end to end accountability into the software engineering discipline,\u201d Gagnon says. \u201cThis is crucial to the service view and achieving modern engineering practices.\u201d<\/p>\n

It\u2019s a transition that\u2019s harder than it looks.<\/p>\n

\u201cThis isn\u2019t simply a matter of learning a few new technical skills, but, also soft skills,\u201d he says. \u201cWriting code is just one expectation.\u201d<\/p>\n

Engineers need to work closely with business partners, manage more aspects of a project, and collaborate with other team members.<\/p>\n

\u201cI\u2019d love to hire the mythical unicorn, someone who understands quality, who understands security, who can code, and who can communicate with others,\u201d Gagnon says. \u201cThese candidates are far and few between. I hire for the basics across all required areas and seek diversity across the team for specialization. This approach has helped balance the team where everyone can contribute within the DevOps model.\u201d<\/p>\n

Putting it all together<\/strong><\/p>\n

Gagnon says proper implementation of DevOps has required multiple adaptations to culture and processes at all levels in Microsoft.<\/p>\n

\u201cIt\u2019s helping to drive our transformation,\u201d he says. \u201cIt\u2019s not only moving the organization forward, but the people as well. It\u2019s driving a shift to centralize on outcomes over solutions, which enables DevOps engineers to truly own and take pride in their work.\u201d<\/p>\n

It\u2019s the kind of thing that fires you up, and sends old, outdated practices up in smoke.<\/p>\n

\u201cI\u2019ve never been more excited about what\u2019s possible at Microsoft than right now,\u201d Gagnon says \u201cThe transformation is occurring throughout leadership, which is making it easier for our engineering teams to realize their goals and have fun while doing it.\u201d<\/p>\n

\"Related<\/p>\n