Skip to content

The good stuff

The good stuff

I.M. Wright I’m tired of arguing. I’m tired of explaining. I’m tired of backing down and backing off. The jury has spoken. The verdict is in. Small teams running DevOps win. Lean wins. Inspiring and supportive leadership wins. Don’t talk to me about how your team is different. Don’t tell me how your approach has worked for years. It’s over. You can settle for what you have and eventually be left behind, or you can align with the proven winner. It’s your choice; just stop ignoring what’s in front of you.

I’ve been a paid software engineer for 40 years and writing about it monthly for nearly half that time. People frequently ask me what practices their team should follow and what steps they should take to improve their team’s impact and outcomes. As my longtime readers know, I’ve been telling folks to move forward with small feature teams using DevOps and lean practices (like Agile and Kanban) that result in continuous delivery. I’ve been telling them to provide vision, safety, and support for the teams they lead. Now, there is clear and unambiguous proof that software teams that follow this advice are twice as likely to exceed organizational performance goals as those that don’t.

I know you think your team is doing well. I know you’ve been rewarded for years for the great contributions you’ve made and success you’ve achieved. I know change is hard, learning is hard, and things get worse before they get better (improvements typically follow a J curve). However, if you fail to adopt lean, DevOps, and inspiring and supportive leadership, you’re gradually going to be marginalized. Worried? You should be. Wondering what to do? I’ll provide you a summary of wonderful, wasteful, and disgraceful practices, along with the supporting evidence.

Where’s the proof?

Before we run through the practices that double your likelihood of exceeding performance goals, I’ll first present the evidence and a high-level summary of what’s effective.

In each of the four years spanning 2014 to 2017, researchers collected data from 23,000 software engineering practitioners from around the globe. These engineers hailed from over 2,000 organizations, from small startups with fewer than five employees to large enterprises with more than 10,000 employees (including Microsoft). The results were tabulated and analyzed using statistical inference. Hypotheses were tested for a wide variety of practices and their causal relationships. The methods, research, and results are documented in Accelerate: The Science of Lean Software and DevOps.

What did the researchers find? High performers use different practices than their peers. High performers are twice as likely as low performers to exceed organizational performance goals—goals of profitability, productivity, market share, and number of customers. The high performers are also twice as likely as low performers to exceed other performance goals, including quantity of products and services, operating efficiency, customer satisfaction, and achieving mission objectives.

How do they do that?

What practices did the high performing teams use that predicated their improved performance? The following graphic, taken from the research, summarizes the practices, using arrows to indicate the causal relationships the researchers identified.

Accelerate Overall Research Program

Overall Research Program: Accelerate: The Science of Lean Software and DevOps by N. Forsgren, et al. 2018: IT Revolution Press.

The graphic shows that improvement starts with inspirational and supportive leadership, which the researchers call “transformational.” This leadership drives several aspects of lean product development and continuous delivery. When you pair these practices with lean project management, you’re twice as likely to exceed performance goals. The research also shows you’ll have less burnout, less deployment pain, less rework, a clearer sense of team identity, greater trust and collaboration (“Westrum org culture”), and greater job satisfaction. Can you and your team replicate these results? You certainly can: It starts with leadership.

You’re my inspiration

It’s true that software engineers are the ones who write the code. It’s also true that leaders have great influence over the practices used, the expectations set, and comfort and camaraderie in the workplace.

  • Wonderful: The research found that transformational leadership guides high performing teams. Transformational leaders present a compelling vision, are inspiring in their communication, provide support and intellectual stimulation to their teams, and recognize team member’s contributions on a personal level. The research focused on team leaders, but it also applies to org leaders. You don’t need to be a great orator to be a wonderful and effective leader. You just need to care about your people, support them, help them grow, recognize their efforts, and provide them with a vision of meaningful and important work that makes a difference to our business and our customers.
  • Wasteful: The research didn’t focus on anti-patterns, but I sure do. Leaders are wasteful when they use people’s time in ways that are unproductive or generate work that’s thrown away. An obvious source of waste is ineffective and unnecessary meetings. Being inconsistent and indecisive also wastes time. Overplanning and overcommitting generate work that’s thrown away, as do heavyweight estimation and overly detailed schedules.
  • Disgraceful: I list a bunch of disgraceful management practices in Management malady. They include secrecy, micromanagement, and playing favorites. However, the worst is leading through fear and intimidation. Doing so is the opposite of being an inspiring and supportive leader. Maybe being a bully was effective previously, but in the long run, you’re despised and discarded.

Everyday I’m hustlin’

A central differentiator of high performing software teams revealed by the research is continuous delivery. (It’s literally in the center of their summary diagram above.)

  • Wonderful: The research found that continuous delivery depends on the following capabilities: automated testing and deployment (including management of the inputs), trunk-based development, secure from the start, loosely coupled architecture (like microservices), continuous integration, version control, monitoring, and proactive alerts. Fortunately, new Microsoft services do all this (with help from Azure DevOps), and old Microsoft services are rapidly catching up as they better integrate with Azure.
  • Wasteful: Engineers are wasteful when they let tools dictate their lives, overanalyze, overgeneralize, forget the basics, carry too much technical debt and unfinished work, can’t work together, and don’t ask for help.
  • Disgraceful: The opposite of continuous delivery is the death march. I can’t even talk about it.

Lean on me

While Microsoft appreciates and encourages inspiring and supportive leadership, along with continuous delivery, it’s less actively pursuing lean product development and lean management. Yet the research shows that a lean approach is an essential prerequisite for high performing software teams and the remarkable results they produce.

  • Wonderful: The research found that lean product development and lean management together are as integral to the great outcomes of high performing teams as continuous delivery. The specific practices include working in small batches, visualizing workflow and status, limiting work in progress, team experimentation (team-driven continuous improvement), gathering and implementing customer feedback from production and other sources, and having lightweight change approvals. Adopting all these practices may sound daunting, but for small feature teams, it takes just two shifts in approach: using Kanban (small batches, workflow visualization, work-in-progress limits, continuous improvement) and using DevOps (alerts, dashboards, customer feedback loops, lightweight change approval, continuous improvement). If you’re looking for other tips for going lean and achieving higher productivity, read Productivity mechanics.
  • Wasteful: Big teams that run long stabilization periods, throw money at problems, and use inappropriate buffers are dinosaurs and must go extinct.
  • Disgraceful: Managers, teams, and engineers who put technology and personal ambition over the business and our customers are the worst.

Eric Aside

Scrum, coupled with a work-tracking board and short sprints, can be used instead of Kanban to facilitate small batches, workflow visualization, work-in-progress limits, and continuous improvement. However, Kanban achieves these outcomes more directly, frequently, and comprehensively.

You’re the best around

This column is loaded with links, but being a high performing team that’s twice as likely as low performers to exceed performance goals isn’t that complicated. Only a few things are required: inspirational and supportive leadership, continuous delivery, small feature teams, Kanban, and DevOps.

The cultural change at Microsoft is driving inspirational and supportive leadership, along with inclusivity and customer obsession. The move to services is driving continuous delivery and DevOps, and improvements in Azure DevOps are helping enlightened teams move quickly to Kanban (or Scrum with boards and short sprints). All that’s left is choosing to have small feature teams that run their own microservices.

Fostering a high performing team is no longer a mystery or a debate. Many teams across Microsoft and the industry are embracing inspirational and supportive leadership, continuous delivery, and small feature teams using Kanban and DevOps. You can too. Yes, you’ll need to refactor your large services into smaller ones, burn through your technical debt so that DevOps isn’t overwhelming, and adapt the size and practices of your team. That’s a lot, but you were probably already planning to do it, and if you don’t, you’ll be left behind. The jury has spoken. The verdict is in. It’s time to act.

Published inUncategorized

Be First to Comment

Your take?

This site uses Akismet to reduce spam. Learn how your comment data is processed.