Take a look at the large-scale agile frameworks, from SAFe to LeSS, DaD, and the rest. Turn your head to the right and squint hard—at least metaphorically. Can you see what they are all missing?
It's the change management piece. For example, the SAFe diagram tells you where to be—but not how to get there. If you go to ScaledAgileFramework.com and find the page for "Implementing 123," you'll notice four steps. Those steps are training lean-agile change agents, executives, teams, and launch pads; then "adapt."
In other words, to implement, pay us money, get some coaching, and "we're going to make IT departments great again. It'll be great, great, just great. We have the best people."
Getting to the future state
To some extent, that's okay. I get it. Companies need to sell services to remain in business, and coaching and training are legitimate services. But what I don't see in the plans is how we get from here to there. As our book, Save Our Scrum, puts it, we want to get to future-state land, but to get there we need to get past the Cyclops, then weave between Scylla (the multiheaded, dragon-like creature) and Charybdis (the whirlpool) in Homer's Odyssey. And, of course, there are the Sirens, who promise quick and easy benefits but will bring disaster.
Between the current state and the future state lies a lot of hard work. (Map by Lanette Creamer, used with permission).
Here are just a few, real perils I have seen recently on teams trying to get to large-scale improvement:
- When and how do we start? The technical staff is currently multitasking, with the average person assigned to three to four initiatives at the same time. How do we "spool up" a release team of 50 people in this new style without killing the existing projects?
- How do we coordinate? One team is in Boston, another in the Midwest. Traditionally, we spent three months laying out interfaces so the components could interoperate, then a year building, then a year testing and hammering out the differences. Moving from that to three days of planning, six of development, and two weeks of coordinated testing seems like an impossible feat.
- What about smaller teams? Imagine a 30-person Scrum team that can delivery every two weeks but has become unwieldy. Breaking that into three ten-person teams, training them all for several days in SAFe, moving to a ten-week "product increment" release cycle—that seems like moving backwards. Yet that is exactly how one Midwest company recently chose to scale agile.
- Immediate cost hit for distributed teams. Training everyone in the method will cost the organization five days of productivity, plus considerable consulting fees. Release-planning meetings involve flying in everyone on the entire team. That's 50 to 250 plane tickets, 400 to 600 hotel nights, plus food, none of it budgeted—just to create a roadmap for the next few months. All this in order to slow down for the first 12 sprints or so, in order to allow real expertise development.
- The directors feel challenged. The director of product management, or the data warehouse, app dev, the BAs, and so on will not release their staff members to sit in a team room, nor release them to be 100 percent available. You might argue this is a problem with any Scrum adoption, and that is true, but in an enterprise, we have entire layers of roles such as architect, functional leads, managers, and up that might go away. These people have often been promoted out of technical roles and are no longer current in those roles. Expect a great deal of resistance here.
- Job descriptions and roles need to change. Larger organizations have HR politics about not just pay grades, but also the size of the cubicle in square feet that technical staff get, determined by pay grade. Updating job descriptions can be a multi-year process. When all the project managers, who have been doing the role for year, take a two-day class and become release train managers, do we really expect them to perform?
Bottom line: Yes, have your agile, as long as nothing has to change. As my colleague Justin Rohrman says, managers sometimes view agile as "something you do to someone else."
Slow change or fast? The management decision
The classic response to this is to change everything, all at once, and flip a switch. Perhaps, for planning purposes, we begin with a date in mind. "You're given 60 days' notice: on October 1, all these departments will become this or that release train."
J.B. Rainsberger once said the spirit of agile was to make small changes and adapt, yet the agile scaling literature seems to actively compete on how quickly it can convert from traditional handoffs-and-document-driven development to large integrated teams.
The challenge is making those ideas stick with fuzzy humans who can resist. As Gerald Weinberg points out in Becoming a Change Artist, large amounts of change create instability, which decreases performance. Humans can see that decrease in performance as failure and reject the change. SAFe SPCs (scaled program consultants) receive a scaled agile workshop kit, and there may be similar materials for LeSS or DAD, but everyone else will have to work through this on his own. Luckily, the change management literature can help with these sorts of transitions.
Kotter's framework for change management
John Kotter, the famed professor of organizational behavior at Harvard, has an eight-step framework for rolling out a change in an organization. Don't worry, it doesn't need to put you to sleep; the easiest way to learn the framework is probably to read Our Iceberg is Melting, a fable about a group of penguins who need to respond to a radical change. Kotter uses the book to explain his framework and the steps he recommends to deliver improvement; you can read in more depth on Kotter's website.
This includes establishing a sense of urgency, creating a guiding coalition, establishing a vision, communicating the vision, empowering people, getting quick wins, and institutionalizing the change.
Whom do you need to convince?
My experience tracks with Kotter's, at least to some extent. Of course, ideas need the assent of a decision-maker, or "economic buyer." Before the decision-maker, there is usually a technical person, or gatekeeper, who selects a small set of options to present to the decision-maker. We can add in the users on top of that—the people whose lives will be affected by the change. Since no idea will fit perfectly, it will be up to the users to make it fit or, if they don't like it, find the excuses to make sure it doesn't fit.
To help me understand what messages will work in the culture, I try to recruit a coach or two—someone to coach the change agent on the moves to make to get everyone on board. The terms "economic buyer," "technical buyer," and "user buyer" are not mine; they come from The New Strategic Selling. When you think about it, sales is an incredible test of influence.
And how do you convince them?
Once we've found the who of change—the real players in the group (who might be different from the ones in the official system)—we need to convince them. The naive approach is to try to figure things out in a meeting. But new ideas, announced without warning, could undo someone else's plan. As John Lyman once said in the TV show The West Wing, decisions aren't made in meetings. Instead, we need to either create a sort of "safe to explore" brainstorming session, or meet one-on-one.
Jason Little's book Lean Change Management provides a set of tools, including communications, with a one-page change management plan. He also offers an exploratory meeting structure, with what he calls "Lean Coffee" and "Retrospectives." The book includes guidelines to conduct experiments, which are a little bit different from quick wins. Experiments can fail to validate our hypothesis, and that is okay. An experiment that finds us something different from what we expected can still lead to improvement; we'll do more of x to improve, instead of less.
Inside any big project is a smaller one, and for every day that smaller project is late, it delays the entire project for one day.
This aligns with my own thinking for change management around software, which involves a lot of background conversations, figuring out what people can stand to gain or lose, buying a lot of actual coffee, introducing incremental change, having retrospectives, and doing continuous planning.
Finding the project 'constraint'
Kotter's framework suggests finding and identifying quick wins. On a project at scale, that means identifying the constraint, the single element that is causing delay on the project. On a team-of-teams project, this is the one component that everyone else plays chicken against—it doesn't matter if anyone else is late, because this component is going to be later.
Putting that a different way: Inside any big project is a smaller one, and for every day that smaller project is late, it delays the entire project for one day. But this also means that, for every day the smaller project is early, roughly ten times as many people are also early, and they can go work on something else. There is a massive opportunity for improvement just by turning that one group into a high-functioning team. Instead of big bang, we start with small experiment, pulling the members of the virtual small team out of their cubes and into one team room.
Put a little SCARE in your large-scale projects
Keep in mind that you're conducting an experiment. It just happens to be one that doesn't directly threaten any supervisor or manager and doesn't change any job description but does at the same time require much less coaching and training. If it works (and having humans work together in a spirit of creative freedom usually does), then the organization can keep that team together for the next project. I call this Sustainable Cultural Agile Release for the Enterprise (SCARE), and for my money it is a much better way of getting to "agile at scale" than a framework or description of the end-state offers. SCARE is about the journey, about the change.
Karen Greaves, a coach with Growing Agile, suggests a second approach: Consider capturing all the work in the portfolio on a Kanban board. When people see the amount of projects in progress and consider the number of teams, the visualization can often have a cognitive impact. Executives realize that the reason the team can't get much done is because new work is coming in too quickly, and multitasking has an impact on performance. (Hint: It's bad) The simple change of finishing a few existing projects before starting new ones can lead to double-digit percentage improvements for project schedules yet requires only a few tweaks to behaviors.
The overall idea here is to start with principles, with the work of Little and Kotter, taking small experiments over time, which might end up with something very much like agile at scale. But if you start with the big agile frameworks and the big bang, I'm not really sure where you'll end up. And you'll have to watch out for the Sirens.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
