3 Reasons IT Ops Uses Lean Flow (Kanban for DevOps part 3 of 3)

In this three-part series on Kanban for DevOps, Dominica DeGrandis, Director of Training and Coaching at LeanKit, explains three key reasons why IT Ops teams and those implementing a DevOps value chain use a lean flow approach to product development. If you’re just jumping in to this series, check out part one and part two.

Reason #3: People responsible for product support have a voice during product development.

Accountability with no authority sucks. To be responsible for keeping production running smoothly — but have no voice in the changes rolling into production — sucks energy, sucks morale, sucks cash. And that sucking noise means organizational health is heading south.

The problem is twofold:

1) The economic cost of owning something is not necessarily reflected in the building of it, but in the support and future maintenance of it. We often don’t understand the effort required to support products.

2) The prosperity of organizational health (i.e., a company’s economic performance, job satisfaction, levels of trust and cooperation, and tolerance for experimentation) is dependent on the alignment of connected teams. When teams ignore or compete with each other — instead of working to improve overall success and growth — organizational health deteriorates. Let’s not forget that the intent of the DevOps movement is to improve the system as a whole.

Product support impacts economic cost

How much budget is needed for maintenance? Who knows?

Let’s define maintenance. Maintenance includes work to provide enhancements, fix defects, run tests, support customers, expand capacity, migrate platforms, optimize performance, reengineer features, update security/compliance, localize global elements, and decommission servers. Maintenance almost always includes some form of operational support. And often enough, some form of design, development and testing is necessary.

Research¹ on budgeting for software maintenance shows that product support needs anywhere from 20-75% of the initial cost of the product development. The variance of the range is due to many factors, including size, skill level, complexity, duration and scope.

Even though it’s difficult to clearly define the maintenance impact of a new product, it is worthwhile to get thoughts from people responsible for its support. They are the ones who get paged at 2:00 a.m. to stabilize the product in production, to handle performance issues and to react to customer complaints. Asking them what they think early on allows for differences of opinions to be aired and debated — a fundamental feature of organizational health.

Product support impacts organizational health

“If people don’t weigh in, they can’t buy in,” asserts Patrick Lencioni in his book, The Advantage (2012). Lencioni correctly observes that people do not actively commit to a decision made on their behalf unless they have had the opportunity to provide input, ask questions, and understand the rationale behind it.

When people are aware of new product development and have a voice during the development of it, they can avoid being blindsided with, “Oh, by the way, you are inheriting a new product tomorrow,” Giving people a chance to anticipate support needs leads to all sorts of goodness. They can allocate capacity for support and have time to consider a proper solution. They can identify load balancing requirements and security implications. Authority enhances their accountability when they are empowered to suggest alternative improvements that are likely to reduce overall costs and risks.

People want to know what’s headed their way and have an opportunity to weigh in on decisions. Even if their suggestion isn’t implemented, they know that their contribution was considered. This alone can improve trust and cooperation — essential ingredients for alignment.

How to create alignment across the organization

Creating alignment begins by creating clarity so everyone can understand why the organization is moving in a particular direction. Clarity on the company’s intent reduces confusion and ambiguity. With a straightforward and consistent message from leadership, employees can freely execute their responsibilities. There are few more destructive obstacles for employees than having to continually maneuver through shifting or contradicting communications from misaligned leaders.

Communication gives people the clarity they need to move forward as an aligned organization. Organizations can boost communication by creating visual representations of their priorities, risks and workflows. We’ll explore workflow visuals here.

Solving misalignment problems with lean workflow visuals

One way to solve misalignment problems is to look at the way work moves through an organization. Analyzing how the iterative bits of work flow across the whole value stream and into the hands of the consumer brings clarity to and supports consequent alignment across teams. From design, to build, to release, to product support — people use lean workflow visuals (such as Kanban boards) to help them see problems related to handoffs, waste, rework and blockages.

people use lean workflow visuals (such as Kanban boards) to help them see problems related to handoffs, waste, rework and blockages.

A Kanban board showing development, operational impacts, and support work

Mapping a cross-functional view of iterative product bits moving through the organization on their way to production reveals how traditionally unrelated processes function and how decisions made upstream impact the flow of work downstream.

In the Kanban board above, the support lane at the far right calls attention to the support responsibilities the team will need to prepare for. In true DevOps fashion, we are reminded that product development is not done until it’s working right in production and fully supportable.

Additionally, the data flow model and data storage tasks call attention to themselves in this view so that they can be reviewed by those impacted. By inviting broader participation in the building of the product, we can avoid troublesome retrospective questions, such as “Why did they design the data flow model like this? It will take at least six weeks to procure the storage needed to handle the data integration — and we want to go live when?!?!”

An anticipatory understanding about what is involved to release and support a product requires early and regular engagement from those impacted.

Ways to build team engagement

To engage impacted teams, organizations are embracing one of two effective strategies:

1)   embedding operations and infrastructure talent into product development teams

2)   insisting that product teams take responsibility for the operation and support of the product.

In the first case, the level of trust and cooperation obtained from having a voice in the matter increases quality and job satisfaction. In the second case, the accountability obtained from servicing the product increases quality and autonomy. Either way, these changes to traditional operational support methods put companies at an advantage where they can react and adapt faster.

The bottom line

In order to prosper, grow, and increase cooperation and job satisfaction, we need alignment across the organization. We need everyone rowing the boat in the same direction. Lean flow helps us anticipate what’s headed our way and gives people a voice in the process. Empowered, engaged accountability means organizational health is headed north.

¹Hayes, Jim. (2014, December 3) How Much Budget Do I Need for Software Maintenance?

Dominica DeGrandis

Dominica teaches Kanban to DevOps enthusiasts. As Director of Learning and Development at LeanKit, Dominica combines experience, practice and theory to help teams level up their capability. She is keen on providing visibility and transparency across teams to reveal mutually critical information. Follow her on Twitter at @dominicad.

One thought on “3 Reasons IT Ops Uses Lean Flow (Kanban for DevOps part 3 of 3)

Leave a Reply