Un-SAFe At Any Speed: Rethinking Scale and Agility

There is a bitter irony in the proposal to take a fluid and adaptable methodology like Agile, and “scale” it across the entire organization. The very properties that make Agile so powerful for teams to produce better quality outcomes for business are precisely those properties that make it resistant to leader-mandated transformation programs. It’s a bit like seeing a small but successful organic farm in a forested pocket of the Pacific Northwest, and declaring that we shall now cover the plains of the Midwest with millions of copies of this exact same farm. It just doesn’t make any sense.

Earlier this month, Al Shalloway, founder of Net Objectives, announced that they would no longer be offering training for Scaled Agile Framework (SAFe). Shalloway and his team had long been proponents of SAFe, and I was surprised to see this shift in focus from his organization. Seeing his note about SAFe underscored much that I and many of my colleagues have been saying for years to each other at small gatherings and in the hallways at conferences.

I’ve written several critiques this year of the style of “cargo cult” Agile adoptions we frequently see attempted in large organizations (examples here and here). When I wrote those pieces, I honestly expected to be a voice in the wilderness. But instead I received an outpouring of support, with practitioners from a wide range of organizations expressing strong resonance with the critiques I outlined. Clearly something is amiss in the way we are currently transforming our organizations, and many of us can sense it.

A few key questions, then, need to be addressed. Why doesn’t it work to scale Agile with a process-based approach? What should we be doing instead? And what do we need as a community of innovators in order to accomplish it? I don’t have complete answers to these questions, but I am starting to formulate some proposals. I encourage you to contribute your thoughts to the conversation.

Awakenings

Agile is not new. And I don’t mean that the Agile manifesto is now almost 20 years old. There have been plenty of articles the last few years celebrating the maturity of Agile thinking, some proposing to revise and reimagine some of the original tenets.

No, what I mean is that the spirit of Agile dates back at least to the early days of the Toyota Production System developed by Taiichi Ohno in the 1950s and 1960s. The Toyota Way, as it is sometimes called, is the source of most of the concepts we broadly refer to today as “Lean.” In fact, one can arguably draw a direct line from W. Edwards Deming at Bell Labs in the 1940s (Deming collaborated with the Japanese during post-war reconstruction to help develop this new way) all the way to the Lean Startup movement of today.

Why does that matter? It matters because while there are many themes that are common to both Lean and Agile that have to do with process and structure, the single most important theme is Respect People. There is a fundamental recognition in Agile, inherited from its parent methodology, Lean, that empowering the team doing the work to make their own decisions about how to do it is the key not only to continuous improvement in manufacturing and design, but to business agility as a whole.

Let me repeat that:

“Empowering teams to make their own decisions is the key to achieving positive business outcomes.” — Me, right now.

This principle is most readily observed in Agile through the idea of a self-organizing team. The self-organizing team is able to employ a combination of respect and empathy with each other, along with a healthy dose of the scientific method, in order to iteratively arrive at a process that works for them, given their unique combination of personalities and strengths, and their particular business and technical environment.

In sharp contrast to the self-organizing team, many so-called Agile transformations start with the process (sprints, stand-ups, etc.), move on to the tools (JIRA, etc.), and rarely, if at all, get around to dealing with the people. Teams are slapped together from some kind of resources matrix, sent to a few days of Scrum training, and expected to be high-performing right away. It's no wonder then that there have had to be so many talks in all of the Agile conferences about getting people to embrace change. You wouldn't have to convince the people if you started with them in the first place!

Process Separates Thinking From Doing

Process is very powerful stuff, and I have enormous respect for it. It’s essentially a form of automating human decision making. It separates the “thinking” from “doing” in any work environment.

Process originates, in many respects, from Frederick Winslow Taylor. At the end of the 19th century, most manufacturing was still produced by craftsman in guilds. Knowledge of a process was carefully guarded by masters, and rationed out by journeymen to apprentices. Different master craftsmen did things in different ways. Taylor’s famous innovation, Scientific Management, consolidated process knowledge and standardized it. But more impactful, it separated the “thinking” work (management) from the “doing” work (production).

Scientific Management revolutionized manufacturing in the United States, and then gradually, the rest of the world. The result was the mass production of the Henry Ford and Alfred Sloan era. Taylor’s philosophy was heralded by McKinsey and other early management consultants, and woven into the curriculum of Harvard Business School.

Lean, by sharp contrast, originating in Japan and taking the manufacturing world by storm in the post-war era, is characterized by bringing the thinking and doing back together in the form of the team. The reason Lean is so powerful is the philosophy of empowering the workers on the line to use their brains to improve the process of production. It is not the process, or the layout of the factory, or the role definition of the managers.

It is this core concept of putting the thinking and doing back together that makes Agile work. Managers in today’s large organizations inherited Taylor's thinking from business school or management consultants or their predecessors. They are not yet in the mindset to embrace Agile. As a result, they readily buy large and complicated process models like SAFe without investing in the harder but more necessary venture of changing how they themselves lead their organizations.

And it's not quite right to blame everything on leaders who buy Agile processes as a solution to their problems. Hey, at least they have acknowledged that their organizations need to change. They wouldn't spend piles of cash on training and consultants if they didn't believe it truly filled a need for change. Then someone hands them a sprawling diagram like this one below, with dozens of pages of roles, rules, and processes, and it looks like a great place to start. In the corporate world, complicated is often passed off as valuable and effective. All you need is 5 years and 1,500 Agile coaches, and you're on your way to business success!

The fault, rather, lies with us in the Agile community. We have failed to prioritize the people in product development over the process. We over-emphasize the power of automation and cloud infrastructure, practices and rituals, and work item documentation formats like user stories, at the expense of the fundamental concept of teamwork, self-organization, empowerment, and respect that made the Lean transformation so successful and that originally inspired much of the thinking that gave birth to the Agile movement.

Leadership Starts With People

I've been in the Agile scene for a long time--not as long as some, but longer than most. In the last several years, I have been increasingly drawn toward the topic areas of leadership, management, and organization design and psychology. It’s not that I am no longer interested in the technical aspects of software product development. I am—indeed, if you’ve read my other writing, you know I am a huge proponent of the technical aspects of Agile, like Test-driven Development and Continuous Integration. And I readily enjoy testing out all of the new tools, frameworks, and systems available to modern engineering teams. The current toolkit for a developer is awesome!

It’s just that, after 20 years in technology, it has become very clear to me that the biggest problems in most organizations rest with the people, and in particular the leadership. Product development is a team sport. Yes, process is very important. But healthy product teams require clear goals and honest communication more than anything else. A focus on the process and the tech, all too common in the Agile training world, leaves teams ill-equipped to tackle their biggest and toughest issues.

The leadership literature, and there is quite a lot of it, is most striking to me in how drastically it differs from the actual behaviors I observe in most leaders in large firms. The best advice is usually some combination of vision and goal setting, delegation and succession planning, and communication and reflection. What I see up close in too many leaders, by contrast, is process-driven, authoritarian, micro-managing, and more or less tone-deaf to the concern of their people. We can and must do better.

Leadership then, if it is to be successful, must be oriented toward supporting people and teams in achieving their best. It must be about helping team members work toward finding their own approaches to self-improvement, and guiding them more as a coach, and less as a foreman or dictator. Agile is never going to stick in an environment where the team doesn’t trust its leadership.

Several times I have been asked to coach teams in some kind of Agile approach, or product development broadly, with a whispered caveat from the client that “the team isn’t really into it.” Two key observations here.

First, the team should never be told to be Agile. The idea of imposing a methodology from outside the team is antagonistic to the very idea of Agile. And it is not that the team isn’t interested in improvement. It’s simply that they are skeptical and suspicious of management coming along with a new process that they are now all expected to follow. And with good reason. Folks who have spent any amount of time in a large organization can easily tell you of three or four previous “change programs” they lived through that really made little difference to their own lived experience on the job. Why should Agile be any different?

Second, they really do want to be Agile. They just don’t realize that what they are being sold as “Agile”, a sprawling process diagram along with dozens of pages of role definitions, meeting structures, and process rules, is not in fact the spirit of Agile at all. If instead, you told the team you want them to start taking control of how they receive, execute, and deliver work, to focus on delivering value above other concerns, and to regularly meet as a team to decide what to change to make things better, they’d readily embrace it. If you also told them, you were going to give them a business goal as an outcome, and then get out of their way, they’d stand up and cheer.

Understanding Scale

Manufacturing scale in the 20th century depended on removing variation and standardizing process. Taylor’s impact was profound in that process design could be completely abstracted from the individual experience of working on the line. Following the process necessarily reduced creativity and innovation. The result was an explosion of output, but not necessarily of quality. It is this lack of quality that created the opening for the Lean revolution.

The Internet has further transformed our understanding of scale. For the last decade or so, leaders of the largest technology platforms have converged on conferences like QCon or GoTo to describe how they achieve web-scale systems like Google and Facebook and Amazon. The central idea in all of these systems is relatively straightforward. Large scalable systems must be composed of smaller, single-purpose components that communicate with each other independently.

Modern technology companies, particularly those formed in the last two decades, have leveraged this principle of scale, along with Conway’s Law, and structured their people and organizations to match the principles applied to Internet-scale systems. These teams are structured into fairly autonomous, self-organizing groups capable of nimbly responding to changes in demand. The industrial giants, like the behemoth conglomerate General Electric, have, by contrast, suffered from high-profile failures to achieve the same flexibility.

Scale, then, in today’s market requires small, self-organized teams working in concert, not top-down process-driven monoliths or functional silos. And yet, when agility is "sold" to the leaders of large organizations (the vast majority of industry whose corporate structures were long established before the first book was ever sold on Amazon.com), what they are prepared to "buy" is a complicated process diagram and an army of consultants to make it work for them. And the Agile industrial complex of consultants, coaches, and trainers (heck, yours truly included--let's be honest here) are all too ready to make a living on one 5-year mission after another, helping these industrial behemoths to implement the process of Agile.

But what is distinctly not happening in many of these organizations is any real continuous improvement, respecting of people, and genuine organization transformation. While executives feel immense pressure to adapt to the increasing onslaught from the younger, faster technology leaders, they simultaneously fear any real and fundamental change that would be required to actually create the positive business outcomes they so crave. They won't stick their necks out and really champion autonomy, mastery, and purpose on their teams. Why, what would they tell Wall Street analysts (see GE's last 5 years for an example)?! Instead "Big Agile" process models exist to adapt Agile to what executives will buy, not to help the organization adapt an Agile mindset.

Doing Better

So, if "following the process" is about as non-Agile as it gets, and hopefully we now agree on that, what should we be doing instead?

For starters, we need to do a lot more to question our assumptions about why we are doing things the way we are. We need to have the courage to question everything in order to find the right buttons to push and the right levers to pull in order to move the organization's transformation forward. This is true in finance, human resources, marketing, and legal, as much as it is in product development.

To be more concrete, whenever you hear someone say, "we can't do that! It's against corporate policy," remind yourself that policies are not laws. They are internal rules written by people, and they can be changed just like anything else that is written down. A common example is, "the regulators won't allow it." And yet, there are cases where regulators have been engaged respectfully and creatively in an innovation program (drones, self-driving cars, biotech, etc.), and actually helped companies navigate the rules in order to achieve the innovation they desired. Thus it is incumbent on us to question why we can't do things in our organization before just giving up and going back to the old ways.

Second, we need to push and support our leadership to be brave in the face of intense pressure to conform to the norms of an earlier and fading era. As they say, "what got you here, will not get you there." Growth requires change. Unfortunately, it is in the nature of organizations to resist change. For leaders to be capable of achieving the kind of changes necessary to survive the 21st century economic environment, they need to be willing to take risks and to challenge the orthodoxy of long-standing business opinion.

And they can't do it without our support. If there are leaders in your organization who are sticking their necks out to do things in a new way, make sure you let them know you support them. Ask them how you can help them in their efforts.

Finally, we need to take seriously the foundational concept in Lean, Respect People. Organizations are made of people, and people have emotions, people make mistakes, people have biases, and people get burned out under pressure. It is time to start taking seriously the growing body of neuroscience and psychology research in our thinking about leadership and organizations.

Nobel-prize winner Daniel Kahneman, author of Thinking, Fast and Slow, taught us that we aren't as objective or clear thinking as we might think we are, and we have to work hard to engage our analytical thinking--particularly under stress. Daniel Pink has championed the idea that the key to motivating people to do their best is to provide them with autonomy, mastery, and purpose. These and many other leading business thinkers have shown definitively that the old ways of doing business are only driving our people into the ground.

An enormous and growing body of scientific evidence exists now showing that people who constantly feel stressed perform their work poorly, make poor decisions, and are limited in their creative abilities. And yet, performance, clear thinking, and creativity are lauded as some of the most important properties of today's workers.

If we are to create the kinds of new, adaptable organizations we need to address the world's biggest challenges, "following the process" simply won't do. If a leader is ready enough to change an organization by implementing a giant change process like SAFe, maybe they are ready to hear and consider alternative approaches to transformation. If you find yourself with their attention, here's what I would suggest you tell them:

Leadership

Leaders in your organization need to shift their mindset away from authority and process and to embrace this new science of leadership before you invest in anything else "change related." The Jack Welch era of cost-cutting, stack-ranking, and management by quotas is gone. The overwhelming majority of leadership theory today is about establishing trust with your people by trusting them first, by moving the authority down to the line workers where the critical information is, and by empowering them to discover and explore their own individual purpose and setting their own goals for growth and development. Leaders should be evaluated based on their ability to develop and mentor other leaders.

Teams

The team should be the primary unit of people in your organization. Team formation is critical for the success of any endeavor. Teams need to be assembled with care and respect, not as an HR afterthought. Teams need to establish working agreements, and given time to get to know each other before work starts. Teams need the power and autonomy to evolve their own ways of working. And teams need to be measured and evaluated together, not as individuals.

Processes

The process that will work for each team will ultimately be highly adapted and customized to their environment. It may look a lot like Scrum, or it may look like Kanban, or it may not look like anything you've ever seen before. But whatever it ends up looking like, it won't be a one-size fits all process from a binder written by consultants. The place for consultants, coaches, and other third party support is in helping the team to discover what works for them based on long-established principles, not on telling them what they should be doing.

Systems and Tools

The systems and tools the team uses to perform work needs to be appropriate to the job. The team is in the best position to make that decision. Don't just declare that everyone in the organization must use JIRA or Microsoft Project or whatever mandated system has been pitched by the latest vendor of the moment. The supposed cost-savings gleaned by "standardizing" tools across the organization are dwarfed by the cost of delay in teams being frustrated by the inflexibility of the tools. Let the team decide what tools and systems they need to use based on the work they are doing.

Conclusion

Every industry is under immense pressure to change from the era of 20th century mass production to the era of rapid, flexible adaptation to fast-moving markets and technology trends. The executives of major corporations know they need to transform their organizations, and they are trying a vast range of approaches to change. A rigid process-focused approach that reflects the thinking of Taylor and his disciples will not produce the organization and business outcomes that these companies need to really be successful in the digital world. Instead, organizations must uproot the last 100 years of doing/thinking dichotomy, and embrace an approach to change that puts the control over how the work is done in the hands of those doing it. Only then will they have a glimmer of a chance of catching up with the new Internet-era upstarts who are already working that way by default.

--

Start your leadership journey

The world needs better technology leaders to tackle the huge thorny problems we face. Join our Mindful Leadership Accelerator series, and get the skills you need to become the best tech leader you can be. Get more info here.