As an organizational transformation coach, my primary job is often to help people find what they’ve lost. It is typical to hear from executives and tenured employees alike that they used to be more aligned, focused, responsive to customers and the market, etc. But after I listen, understand, and empathize, I’ll usually ask ‘where did you lose it?’. As you might imagine, the typical response is a blank stare, and it isn’t surprising.

What do you typically do when you’ve lost something?

Measuring Value & Outcomes

In Part 1 of this series, we discussed three primary metrics of an Agile transformation: value, flow, and quality, aligned with the roles of scrum: PO, SM, and Dev Team, respectively. While these may be considered geek metrics, they do eventually align with ultimate business performance when financials are available months or quarters later. Furthermore, they remain somewhat abstracted from the reasons why organizations choose to implement Agile (see the graph below.) In this article, we explore the value & outcomes category of metrics to holistically steer an organization.

Why Scaling with SAFe is an effective way to realize the full potential of Agile

In the first part of this article, we explored the rationale behind Agile Scaling and briefly toured some of the popular Frameworks, with a specific focus on the Scaled Agile Framework (SAFe). In this segment, we will continue our ascent by examining some approaches for successfully leveraging SAFe.

Why Scaling with SAFe is an effective way to realize the full potential of Agile

Transformational change in organizations requires a razor focus on a future state that must draw leaders and employees out of their current world to embrace a different focus. Creating this pull to change involves fundamentally shifting how individuals understand their value and purpose, and in practice, this can be incredibly disorienting and look high-risk. However, the highest risk comes from continuing the same pattern and entrenching dysfunction.

An Agile transformation is intended to build new business capabilities- to get things done faster, to improve product quality, to reduce risk, to improve predictability, and to improve productivity. Yet, many Agile transformations lack any plan for measuring success. Executives supporting Agile transformation programs often become frustrated with this lack of meaningful metrics. Meanwhile, practitioners debate the relevancy of metrics, often from a silo rather than an end-to-end perspective. Months into the transformation, executives wonder whether the program even merits continued funding. They struggle to pull together data after-the-fact. Because they didn’t have baseline measurements from the start of the transformation, it is hard to demonstrate progress. Often, any data that is freely available becomes the metric of focus.

Principia - meaning “collection of Principles” was first used by Isaac Newton in 1687 (one of the great heroes of the Enlightenment) as the title for his treatise on fundamental mathematics and physics¹

Principia - meaning “collection of principles” was first used by Sir Isaac Newton in 1687 (one of the great heroes of the Enlightenment) as the title for his treatise on fundamental mathematics and physics.

Before we Start – a Quick Preamble

This blog may be viewed as a little controversial by some within the Agile community. However, my intent is simply to challenge some of the established norms, and maybe in doing so, rattle the proverbial cage a little. At the end of the day, and in the spirit of experimentation, this piece is meant to be a playful exploration of alternatives to the status quo. Hopefully, this will lead to a fresh perspective and stimulate some new dialogue on a somewhat stale subject - Process.

 Companies looking to get the benefits of a DevOps mindset often get stuck in the trap of focusing on buying the "best" tool and implementing "best" practices.¹ Tools are chosen with very little, if any, collaboration with developers, testers, or operations staff. "Best" practices are determined by committees, again based on scant practical organization experience. While there are benefits to standardization, premature standardization, or standardization with no room for experimentation leads to stagnation and poor overall performance. And what works today will be unlikely to work as well in the future. The pace of change and innovation in DevOps means new opportunities for improvement are arising regularly.

As Bob Fischer points out in a recent blog post, Technical Debt is a Business Problem, “technical debt is rarely understood by non-technical business people.” So the question is: How do you go about having a productive conversation that enables non-technical people to appreciate the need to actively and continually keep technical debt low?

My solution is simple: keep it visual.

It is common for companies to stall or slow in their quest to improve speed, quality, reliability, or security through a DevOps approach.  It is not technology that slows them down, but their culture.  They have practices and beliefs that make some aspects of DevOps seem impossible:

“Sure, developers at small start-up XYZ can put their own code into production, but we're in a regulated industry, and it would never work.”

“We need separation of duties. What you’re suggesting is impossible.”

“Audit or compliance would never allow a developer to test code.”

In this blog post, we’ve focused on separation of duties.  Separation of duties is an important concept and to some, it might seem to be incompatible with a DevOps approach, but it isn’t. In fact, in many cases the separation of duties in the context of DevOps offers more assurance of quality, security, and audit-ability than traditional approaches.

As an organization goes through an Agile Transformation, one of the roles that is most impacted by the transition is middle management. One day you are managing a team or large department, and the next you find yourself without anyone to “manage”. Instead, your department’s members are now members of Agile teams who self-organize and whose work is no longer under your direct control. This can be a very unnerving experience for middle managers and leave many wondering what their role is now in this brave new world.

It must be bought into. But just what are organizations buying into?¹

For me, the goal is to be able to answer “yes” to this question:

Can we confidently and reliably deploy and operate software at any time to meet the needs of the business?

A mentor of mine from twenty years ago recently asked: "Can Agile commit to long term commitments needed by executives to run their business?"  I answered with conviction that it certainly can, but when I went on to explain, I realized the answer is fairly complex. To simplify, if you prefer managing with data, you will love agile.

DevOps is often misunderstood as simply tools and process, and that's part of the story but misses the mark. DevOps is really about building greater cross-organizational teamwork. Teamwork that ultimately enables speedier time-to-market, higher quality, and more rapid learning. Traditionally, this isn't how people work. It wasn't how I worked when I was a functional manager. I was focused on my individual part of the puzzle being great, not on what really mattered to our customers or the organization. A big production outage provided a great catalyst for me to rethink how I worked. It wasn’t pretty, but it was very instructive.