SEVEN

Create Flexibility

A few months have passed since Blair asked the team to update the process guide. Vincent, along with a few others, reworked the guide, renaming it the playbook. Its new name reflects that it is now a more user-friendly resource, with helpful checklists and visual aids organized in a way that supports the team, rather than a recitation of policy and rules. Vincent even led a couple of informational sessions to bring the team up to speed. Blair starts to notice concrete improvements in how quickly they now process standard contracts. Turnaround time has gone down quite a bit, and they’re reducing the backlog of work while building close relationships with the program managers.

As Blair preps for her regularly scheduled one-on-one check-in with Ms. Barton, she reflects on the progress she’s seen in establishing a more stable process for routine contracts. She also wants to focus her attention on the new, more flexible contracting approach that her team has just started to see a need for. She especially would like to encourage them to learn and experiment with ways to be responsive to the programs. Figuring out where to be more rigid and where to be more flexible is a challenge Blair decides to raise with Ms. Barton.¹

Now let’s turn our attention to how to embed flexibility. One way to provide this flexibility is by keeping the organization’s structure stable, as discussed in chapter 6, and then supplementing it with small teams that quickly test possible solutions using experiments and pilots. Rapid experiments help diagnose the problem, identify which solutions are likely to work, and quickly refine solutions. Pilots are small-scale implementations of solutions used to refine and improve the solution before rolling it out on a larger scale. Rapid experiments and pilots can also be used to find new opportunities to improve how work is carried out.

RESPOND WITH TEAMS

Agile organizations deploy a wide range of teams to respond to crises or explore emerging trends or pressing issues. Sometimes, teams are short-term or quick-response; other times they may endure. They go by various names: task forces, crisis teams, tiger teams, and rapid-response teams. Some teams may form on their own, while others may form at the direction of a leader. Employees who have already come together, whether virtually or in person, to sense and interpret what a change means might want to continue to explore the change by considering responses. In agile organizations, not only do leaders request that teams be formed to address specific problems, but collaborative norms permit employees to decide if and when they want to get involved in teams to address the swirl of change.

Creating a formal, temporary team brings some advantages—the team can request resources that it needs to test and experiment with possible solutions. Higher-level leaders, who provide access to resources the team may need, also provide top cover for the team, authorizing them to continue their activities. With an emphasis on quick, inexpensive experiments, temporary teams often do not require significant funding; in fact, resources are conserved when solutions are found sooner through low-cost experiments.

Of course, those in positions of formal authority may also serve on temporary teams, bringing their technical or functional expertise to bear on the problem as well as their knowledge about where to find other experts and resources across the organization. Employees can decide if and when to join a temporary team as well; as the team interprets signals that it is picking up on through sensing, its understanding of the problem may change, resulting in a need for new or different expertise. So temporary teams are expected to form, reform, and disband appropriately.

Agile organizations rely on temporary teams to respond both re-actively and proactively. Not every change that affects the organization will be noticed before it happens. Sometimes, the organization is affected by something that comes out of the blue, requiring you to scramble to find a response; however, doing a good job staying on top of what’s about to change or might change, through sensing routines, allows the organization to anticipate change and to try out different responses before they are needed.

When a team is faced with a rapidly evolving situation, they’ll sometimes find that the situation has shifted again, even before a response was found to address the original problem. In this case, the team may need to speed up its experimental cycle. As previously mentioned, experiments can be done quickly and inexpensively by testing out essential parts of a solution rather than a full-blown version, so this may be a technique that the team needs to try. Another way to deal with rapidly changing situations is to pull in new team members with different expertise. The team shouldn’t be locked into its current members—it may need to switch them up.

Changes that are expected to last longer can be addressed by using more permanent project teams or task forces. Employees can be matrixed out to such teams, and long-term team assignments can help employees gain specialized knowledge about a specific customer or service offering.

Another type of team that can be created to manage the swirl of change is the on-call team, which springs into action on demand. Even though it’s impossible to predict every exact situation, you can often predict that something will happen at some point. In that case, your on-call people can jump in; until then, they can perform their regular jobs.

No matter the type, teams provide a way to bring together employees from across the organization, helping ensure the right skill sets are brought to bear. Given the collaborative nature of agile organizations, employees are permitted—and even encouraged—to form teams spontaneously and to change team membership and disband when they see fit. Because employees are expected to share information about changes and to work together to figure out what those changes might mean for the organization, self-forming teams are a natural result. They may form to share signals that people are sensing, discuss how processes might be affected, then come up with ideas for quick, iterative experiments that could lead to a solution.

Whether self-forming or leader-directed, however, it is important to keep teams small; research shows that small, even two- or three-person teams, can provide powerful results. In small teams, it is easy to keep everyone up to date and on the same page, assuming that the team has the right skill sets.

Also keep in mind that, although some teams form on their own, they may require resources as well as some degree of oversight and support from leaders, if only as part of information sharing. Leaders can reinforce teams in many ways. They can ensure that norms support sensing, interpreting, and responding routines. They can ensure psychological safety—the sense that it’s okay for people to try possible solutions, learn from experiments, and share what they learn as they go along. Leaders can help ensure that budgets include enough resources to enable experimentation. And they can provide top cover and help keep their own leaders, whom they report to, informed of the team’s progress.

INCORPORATE INNOVATION TECHNIQUES TO SOLVE PROBLEMS

Building teams is an important first step toward solving a problem. So teams should start by generating ideas to address the problems. New and complex problems require fresh thinking to develop new solutions or adapt them from another context. Luckily for leaders, this process need not be mysterious or reserved for a select few. You’re probably familiar with some techniques for encouraging divergent thinking, such as brainstorming or identifying unintended consequences. Another divergent thinking technique is design thinking, a human-centered approach to generating and testing novel ideas that has demonstrated success in helping cross-functional teams generate, select, and prototype ideas to solve complex problems.

Design thinking begins with the team immersing itself in the problem context, usually by empathizing with the stakeholders that the team is designing solutions for. An example of this is exploring a stakeholder’s experience through a journey map, which is a visual way of showing the stakeholder’s experience. The journey map captures stakeholders’ pain points and opportunities at various points during that experience. Once the team has explored the problem space, it defines alternative problem frames to decompose the complex challenge into a more manageable set of problem areas that the team can try to influence.

The different problem frames lend themselves to structured brain-storming sessions to identify a large number of ideas. While the term brainstorming has been overused and often signifies people being put on the spot to share ideas that are then judged, design thinking emphasizes a series of rules and methods for brainstorming that engages the full team in a less threatening manner. Examples of these rules and methods are visualizing the process, such as by using sticky notes or pictures, and deferring judgment for others’ initial ideas, instead focusing on quantity. After the team has identified a large number of ideas, it selects which ideas to explore. Teams are encouraged to think of individual ideas as puzzle pieces or blocks that can be combined into different configurations, as some of the best ideas are often the combination of two or more disparate ideas.

Once the team has identified a handful of alternative ideas to explore, it needs to find a way to surface and test the assumptions behind those ideas. This is where experimentation and piloting come into play.

CONDUCT RAPID EXPERIMENTS AND PILOTS

Leaders are often challenged with implementing innovative solutions in uncertain environments given a number of variables that they must account for. Assumptions is another term for these variables. Think of assumptions as a series of constraints that you must operate within. As agile leaders, however, you can lean into these assumptions to create flexibility.

That flexibility comes from your signals to your teams to conduct rapid experiments and pilots and to explore the assumptions inherent within current and potential problems. Experimentation and pilots allow your teams to iteratively uncover the best solution before the change or problem affects your organization.

Experimentation entails designing and executing a series of controlled investigations to systematically test the essential assumptions behind possible solutions. By definition, an experiment will not require a complete solution. Instead, you will want to design an experiment that enables maximum learning with the least amount of effort. With some creativity and planning, a team can often find quick, safe, cost-effective ways to test whether a solution will work. Before you try to implement an expensive, complex automated solution, for example, you can test the process manually to see whether the capability produces the desired outcomes. Because automation often impacts multiple processes and requires workflows to be redesigned, we suggest that you test out the redesigned process before implementing automation; this will help your team understand how the automation works as well as identify unanticipated effects.

Another approach to experimentation is to use a control group as a baseline against which you can compare possible solutions. Rather than roll out a solution across the organization, try testing it with a small group—perhaps a project team, office, or region. Then refine the solution with that group before rolling it out to the next one. For example, if a process needs to change as a result of a new policy or technology, experiment with two or three ways of modifying the process. Then try each option with a few simple cases. Review the results together, refine the options, and try again with slightly more complex cases. Keep experimenting, learning, and refining until the team settles on a solution.

Piloting means conducting a practice or trial run of a solution with the goal of learning what aspects of the solution work well and what aspects don’t. In response to this learning, changes and improvements to the solution can be made, and another pilot can be conducted to test out the refined solution. The cycle of pilot, refine, repilot should continue until the final version is agreed upon. At this point, you and your team can roll out the solution. There’s no correct or ideal number of pilots to conduct before deciding to make the solution final, and while some of the final versions may become well-defined processes (or integrated into well-defined processes), other versions may be intentionally flexible.

Let’s say you want to implement a mentoring program for new team members. You could start with a small pilot where you train two or three mentors and have them start to work with the new team members. Ask the mentors and new employees for feedback and ideas for improving the program. They might have ideas for how to improve the program itself, such as implementing a process for signing up to be a mentor or for assigning mentors to new employees. They also might have ideas for how to improve mentoring, such as ways that mentors can build rapport with new employees. Incorporate one or two of these ideas into a slightly more expanded pilot, continuing to iterate until a full-scale mentoring program is underway. At that point, you know that the program is working well, and you’ve developed it with an initial minimal investment.

Experimentation and piloting help you work efficiently because you’re not investing large amounts of resources up front for a program or solution that turns out not to work perfectly. In the past, some organizational leaders tried to solve problems or put programs into place all at once, often requiring large multiyear investments. That approach worked well when situations changed slowly and when those leaders had near-perfect knowledge about the organization. However, most organizational changes now should be addressed iteratively because no one person has enough of a grasp of an issue to solve it. For example, organizations can develop clear organizational policies by implementing a few straightforward rules, seeing how they influence employees’ work and decisions, and then adjusting the policy statements appropriately.

IDENTIFY FLEXIBLE PROCESSES

Sometimes it is not possible to specify a detailed series of steps or create contingency plans. Agile organizations respond to such situations by identifying processes that need to be flexible. Flexible processes are necessary when the situation drives how the work is carried out and when that situation is ever-changing in complex and unforeseen ways. In some cases, you might not be able to predict when the situation will change, but once it does, you can be prepared by having an alternate approach. In other cases, complex factors might interact in new ways, resulting in one-time solutions. For example, redesigning an organization’s financial systems depends on many factors, including the organization’s finance needs, the accounting and budgeting software and systems that employees rely on, information-security details, and finance regulations. Although a solution architect might follow the same general steps each time she designs a new financial infrastructure (e.g., review the current infrastructure, identify future needs, and design the new architecture), the architect also relies on expertise and experience to create a final solution that’s specific to the organization’s requirements.

Yet another part of your role as a leader in an agile organization is to contribute to this norm of making intentional decisions about which processes are well-defined and which are flexible. To do so, you can get input from other knowledgeable people. You can make sure that flexibility is not misapplied or used as an excuse for not taking the time to define and document processes that need to be stable. You can also help employees distinguish between situations requiring well-documented or flexible approaches, emphasizing that neither is inherently right or wrong but that both approaches serve customers equally well in specific contexts. For example, people working in different geographical locations or serving customers with slightly different needs may need to customize processes according to stakeholder needs, the physical layout of their offices, location-specific policies and regulations, or other unique circumstances.

To distinguish (or help your team distinguish) whether a situation might warrant more flexibility, keep in mind that well-defined processes allow your team to get work done quickly and efficiently because the steps are clear. It’s okay to allow for differentiation from the steps, of course, but consider carefully before customizing a well-defined process; you don’t want people reinventing the wheel so that it detracts from focusing on work and wastes resources. Also know that one-off processes make it more difficult to train, cross-train, and rotate employees across units as well as to improve processes. That said, there are situations (as mentioned earlier in this section) where flexibility is not only warranted but necessary.

Finally, after deciding which processes (or parts of processes) are stable and which are flexible, organizations should specify these and communicate them with those actually carrying out the processes. And remember that all processes—both flexible and well-defined—should be periodically reviewed in order to identify where improvements might be made, either through refining steps, making parts of a process more stable or flexible, or even eliminating processes that are unnecessary or add little value.

STAFF FLEXIBLE PROCESSES WITH FLEXIBLE ROLES

When work must be carried out in a different way each time or when it’s impossible to define work as a series of distinct steps, you will need to rely on your expertise and experience, along with that of your teammates, to find the best flexible approach. For example, organizations with complex computer systems running multiple applications may find it difficult, if not impossible, to create step-by-step plans that will cover every possible set of problems, so they must rely on computer-systems experts to diagnose and solve non-routine problems.

In some cases, well-defined processes can be combined with flexible processes. For instance, a computer specialist might analyze a system crash by drawing on her expertise to decide which tests to run or system logs to review to pinpoint the cause. Upon finding out that the system crash was caused by a specific software application, she might then use a job aid, perhaps a reference manual provided by the software vendor, to walk through the specific steps her team should follow to bring the software back online.

Flexible processes are best staffed with employees who thrive on ambiguity. These processes may also be staffed with a mix of technical or functional experts with some degree of creativity who can draw on their expertise to quickly find and test possible solutions. Role descriptions for employees supporting flexible processes should focus on responsibilities and broad outcomes rather than on compliance with defined steps or actions. Such flexible role descriptions allow employees the latitude they need to respond to the wide range of situations they may encounter. Note, however, that employees supporting flexible processes will likely also perform tasks that intersect with well-defined processes by helping to identify and test improvements to those processes.

MYTH: WE HAVE TO BE A WELL-FUNCTIONING ORGANIZATION BEFORE WE CAN BE FLEXIBLE

We often hear employees and leaders say that they need lots of standardization before they can begin incorporating agility. Not so. These organizations are usually not getting the results they want and are incorrectly assuming that they need to define processes before enacting changes to them. The range of obstacles to flexibility cited by these organizations include the following:

• We need a few more months (or years) to define and standardize how we do things.
• If only things would stop changing for a while, we would have time to get everyone on the same page.
• We are short-staffed or underfunded right now—we hope to hire more employees or get more funding next fiscal year.
• We just need people to work a few more hours each day to get everyone on the same page, but they are already overworked and responding to urgent situations.
• We formed a task force to document our processes, but the task force was overtaken by events beyond their control; task force members lost focus when they were pulled off to fight fires (i.e., deal with more pressing issues).

You may think you don’t need to prepare your organization to handle all of the demands and evolving situations that you will, in fact, face. We recognize that you are doing your best and have good intentions. And we know it is not easy to get an organization to adopt agility principles while having to carry out work in the face of rapid change—and usually with an understaffed and underfunded organization. However, it’s unlikely that your environment will ever get back to a state of stability and certainty, especially if you don’t consider ways to achieve the right balance between stability and flexibility. That isn’t necessarily an easy thing to do, but the truth is you probably don’t have a choice due to the constant state of flux confronting us all right now—that state where what needs to be stable today may need to be flexible tomorrow. Becoming more agile means finding a new way to approach work, starting with acknowledging that some processes may need to be flexible while others may benefit from being well-defined.

MYTH: DEVELOPING INNOVATIVE IDEAS IS A MYSTERIOUS PROCESS

Sometimes people see innovation as something that only a few creative individuals can carry out. Other times, people think that you have to have “innovation” in your job title to come up with new ideas. The truth is that all individuals and organizations can both learn and practice innovative behaviors, helping them to identify and explore new ideas. Design thinking and lean startup are examples of repeatable, proven approaches that can be used to explore unmet customer needs and ideas to meet those needs. Leaders who recognize that many different innovation techniques exist and can be used by anyone will help further innovation; using these innovation techniques helps employees become familiar with the approaches and unlock their creative ideas. Perhaps more importantly, using innovation techniques regularly allows employees to come up with unique ideas that can be tested and put into practice—and this results in the “I’m not creative” mindset retreating with visible, tangible impact.

A related misconception is that innovation can be carried out by simply trying a bunch of ideas and then seeing what works. Some organizations use terms like pilots and prototypes to refer to different ways of approaching a problem, but many times, they don’t invest time to define the problem first. Instead, they jump into identifying possible solutions. They view the pilot or prototype as a way to try out multiple ideas at the same time without defining what success really looks like.

To prevent this from happening, we recommend that you and your organization take a structured approach to experimentation by defining the success criteria ahead of time and then identifying and testing one idea at a time, in short iterative cycles. Knowing what success looks like will help you assess the results at the end of the experiment. And if you are a leader who is trying to promote organizational agility, we encourage you to not be afraid that an experiment will not meet the stated success criteria—whatever happens will provide useful feedback and allow you to refine the ideas and eventually find a solution that works.

Blair calls in to her meeting with Ms. Barton. Among other updates, Blair lets Ms. Barton know that the team is creating a separate, more flexible process to use for programs that need smaller, more frequent contracts. Ms. Barton seems to appreciate the update, saying, “Let me know if I can introduce you to any contracting experts in the other divisions.”

With Vincent and his team working on documenting the standard process, Blair asks Hari and two other team members whose programs are in a lull to help out another division experiencing the typical October surge of contracts. “Not only will this help out the other division, but it will give Hari and the others a great opportunity to learn about contracting for products as opposed to our team’s focus on services,” Blair explains at the weekly meeting. “What they learn might come in handy and continue to build our relationships within the agency’s contracting community.”

In the interim, two additional teams formed on their own. Barb didn’t have time to look into new acquisition tools, so Hank and Kyle volunteered to help. And when Maya attended Blair’s learning hour on changing laws and policies, her eyes lit up, and she offered to get involved; it turns out that Maya’s minor in college was public policy.

It took a couple of months for Hank and Kyle to narrow down the acquisition tools to a manageable number, especially given their current workloads. But they managed to fit in their research along with a few calls to acquisition experts inside and outside their agency. After some short initial conversations with the tool vendors, Hank arranged for a few vendors to provide tool demos for the entire team. Several team members, including Vincent, posed some very insightful questions that helped the team understand which tools would work best. And by involving everyone, the team seemed to take ownership in the decision, while Blair started talking to Ms. Barton about how to fund the new tool. Blair told Ms. Barton that it was Kyle who realized that the current system might cost them less when they start transitioning quick-turnaround work to the new tool, which would free up most of the funding they needed to buy it.

Blair asks Hank and Kyle to start thinking about how to experiment with a new process and run a series of pilots with the new tool. To help figure out what to pilot, Blair puts them in touch with an expert in the agency’s innovation center. The expert helps them run a design-thinking workshop where acquisition team members across the agency try to reimagine what the process might look like as well as identify certain assumptions that they’d been making. The assumptions, along with a vision of a smoothly running, yet flexible process, help Hank and Kyle plan a series of experiments. Hank is able to get trial versions of a couple of tools so that they can experiment with an outline of a possible new process.

Kyle suggests, “Could you pull up a set of previous quick-turnaround contracts, strip out sensitive information, then practice routing them through the new tools? We could start with three or four test cases. I’m sure we’d learn a lot as we went, and we could even start to pull in other team members to help. That would give them a chance to learn the new tools and be in a better position to decide which one works best.”

“That’s a great idea!” Blair responds. “Several team members have been asking for a chance to brush up on their technical skills. Just last week, Barb mentioned that her friends at other agencies are already familiar with some of these tools, and she doesn’t want to be left behind.”

Hank adds, “Once we learn which tool works best, we can pilot the process with some easy contracts. Kyle and I can then work out the details of the process and expand the pilot to a few more team members and contracts. I’m sure they’ll have some good insights into where we need to define clear steps and where we need to give them flexibility to address the program’s unique needs. And some of these tools are using artificial intelligence that learn as they go along; if we used those tools, we would need to pull in some past cases anyhow.”

Blair agrees, thinking, “This is working well. In the past, the decision about which tool to buy would have come from several levels up. The team would have resisted because they would have thought, correctly so, that those decision-makers are too far removed from the day-to-day contracting work to pick the right tool. Keeping Ms. Barton in the loop, though, has paid off, and she’s been really supportive. And she seems to appreciate not having to spend her time making this decision.”

However, at her next check-in with Ms. Barton, Blair learns that Mrs. Banks has expressed concern about Blair’s team taking so much time to run experiments. Blair and Ms. Barton discuss how to address this concern, focusing on the productivity improvements that they have already seen.

Ms. Barton notes, “It will be hard for Mrs. Banks to deny that you’re making progress when she sees how the team is turning around standard contracts much faster now.”

Blair adds, “I expect that we will continue to improve, especially when we tackle the incremental contracts we’re seeing so much of. And we think our quality will go up. By drafting a contract right the first time, we reduce our rework time and are less of a burden on the programs. Another way to explain why we’re changing the way we work is to share all of the factors that impact our work—I know you remember back when I first took the job, how we documented all of the changes going on. That might help her see that we can’t keep doing work the same way if everything around us keeps changing.”

A few weeks later, Hank updates Blair on the experiments: “When we explained the new process, we hadn’t accounted for needing to route work requests into the right workflow—either the typical or new process. When we started the experiments, we realized that people were getting confused about which workflow to use. We had to spend time creating a routing process, but it’s a good thing we caught that early. We hadn’t even thought about that until we started running a test! It was one of the testers who came up with a really creative, yet effective, way to route the work into the right workflow.”

Blair realizes that pilots and experiments do take time and mental energy but will lead to the results that her team ultimately needs. Now that the team has started to implement the guidelines in the playbook, Blair is already seeing that they will need fewer team members working on routine work; this means that more of the team will be available to handle the non-routine work.

Ms. Barton sends Blair a quick email to fill her in on the meeting with Mrs. Banks, saying that it went well and that the hard data on their productivity was hard to argue with. That said, Mrs. Banks was still not completely convinced.

Blair jots down a quick reminder for her next check-in with Ms. Barton—they’ll need to figure out how to get Mrs. Banks on board at some point. In addition, Blair begins to realize that her team’s progress can only go so far without other parts of the organization being on board too. So far, her team had been the only one in the organization to become more agile in response to the programs’ becoming more agile. To help other parts of the organization—finance, accounting, human resource management, and IT—to become more agile will require a higher-level leader to start them down that path.

1. Awais Sheikh contributed to this chapter.