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.

It’s no secret that women, in particular, are faced with incredible hurdles when striving to advance and maintain their careers. Often, many of these challenges are related to a sense of self-doubt. As a YouGov survey reports, “when asked to compare their own intelligence to that of ‘the average American,’ about a quarter of men declared themselves ‘much more intelligent,’ vs. just 15 percent of women.”¹ The notable amount of self-doubt that many women grapple with often inhibits them from realizing their true worth and potential, and this can translate to women experiencing a skewed and limiting perception of themselves in their work lives.

What are Net Promoter Scores?

Have you heard of Net Promoter Scores? A company’s NPS or Net Promoter Score is a measurement of customer satisfaction.¹ These scores are especially useful in the staffing industry, in which feedback isn’t linked to a tangible product, but is instead related to a more subjective service or experience. For example, when a client says their experience with us was “good,” it’s difficult to derive true meaning from that response, especially as the definition of “good” likely varies vastly from client to client. Thus, the staffing industry was in need of a universally understood, tangible measure of a subjective experience. Enter NPS. While NPS surveys can ask a number of questions, the concept truly focuses on only one:

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.

Millennials. The generation of lazy, narcissistic, self-righteous, participation trophy-toters. As one of those very Millennials, I can attest to the bad rep that we have. Gen X co-workers don’t know how to work with us, and our Baby Boomer bosses struggle to understand how to connect with us. We realize there’s often a disconnect between the generations in the workplace, so I’d like to help shed some light on what we need in order to thrive.

Let’s say you’re a consultant. You just started a new project working for a fantastic client, and you love your role. Even though your employment situation is ideal, you still need some help. It’s late on a Friday night, and you have a problem. You think about calling your recruiter, but it’s outside of business hours. You’re tired, stressed, and unsure where to turn. Sometimes things go wrong, and that’s where our Consultant Advocate Program comes in.

 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?