Chapter 6

Inspect and Adapt: How to Correct Your Course

IN THIS CHAPTER

Needing certainty

Understanding the feedback loop

Maintaining transparency

Dealing with antipatterns and external forces

Correcting the course and testing in the feedback loop

Establishing a culture of innovation

Often during product development, you find your product in a different place from what you expected. This chapter explores how scrum facilitates continuous learning and improvement. It also looks at how you can work in the presence of uncertainty instead of hoping that you can plan it away. After all, being agile is being able to learn and adjust as you go — being flexible enough to build the best product with the right features and with the best quality.

The Need for Certainty

Management’s need for certainty of outcomes may well drive the downward spiral or decay of many projects and great ideas. They could refuse to accept the basic reality of uncertainty, settling for the relative safety of the known at the expense of the better. The power of the empirical approach is being okay with uncertainty until you’ve learned the information you need to have more certainty about the outcome of your project or goal. For example, six months from now, it will be difficult to know for certain if a needed component being built by another team will be finished on time if the other team won’t begin development for three months from now. But two weeks before its expected delivery you can have a much clearer expectation of its readiness.

Empirical means to learn or verify by means of observation. So, scrum is considered an empirical approach because each step of the way, you inspect your results and adapt immediately to a better outcome.

Figure 6-1 depicts the forecasting tool known as the Cone of Uncertainty. The basic principle is that outcomes are hard to predict across a span of time, but as you arrive closer to your goal, certainty increases.

© John Wiley & Sons, Inc.

FIGURE 6-1: The Cone of Uncertainty.

Weather forecasters use the Cone of Uncertainty to depict the path of hurricanes over the course of several days. The empirical approach embraces the reality of some uncertainty and provides a framework for managing the associated risks by continually improving and adapting.

The Feedback Loop

In economics, a feedback loop is defined as the outcome or results of one process or one cycle used to inform the next. This feedback loop is what feeds the data to the empirical inspection process. Figure 6-2 looks at the feedback process of scrum teams.

© John Wiley & Sons, Inc.

FIGURE 6-2: The feedback process.

The idea behind a feedback loop is that you can continually improve from the information learned from experience if you have a way to apply the lessons learned to future situations. An inherent part of the scrum process is recognizing that the knowledge and experience gained during each sprint need to be reintroduced in later sprints to inform the evolving plan. At the outset of a project, product roadmap and sprint plans are always made with the best information available at the time. The plans are accepted by the whole team and socialized throughout stakeholders. Rigid adherence to an exhaustive initial plan can ignore lessons learned during the process and stifle innovations from within the team. Instead, scrum uses customer and team feedback to continuously improve the plan.

You may wonder why you should plan at all if you know that an initial plan is likely to be flawed. You establish a plan as the first step in your learning process. Much as a flight crew files a flight plan based on the expected conditions so that crew members and air traffic controllers know what to expect, product roadmaps lay out the scrum team’s preflight expectations. After a flight crew takes off, the members evaluate actual conditions such as weather, winds, and scheduling to adjust the flight plan as needed. Likewise, in scrum, you provide feedback throughout every day, and as you learn more information, you adapt your ideas and plan.

Feedback loops can be positive (resulting from successes) or negative (resulting from failures). Success can breed success, but failure can inform success if you learn from it. This concept is why you should ask both what worked well and what can be improved during each sprint retrospective. It’s important to continue to support scrum successes and look for changes that can have a positive effect.

Transparency

Transparency is pervasive in modern society. In everything from open-source software to open collaboration on ideas, transparency is a broadly interpreted term. In scrum, transparency is a basic pillar of improvement. When channels of communication are clear and accessible, information is radiated throughout an organization. The entire organization knows what’s been done, what’s being worked on, and what’s left to work on and any impediments blocking the way. Right from the start, you produce real results that are tested and then approved or sent back for adjustments. The lag time between the start date and usable results is now days rather than months.

Transparency isn’t just about quickly seeing results. Everyone needs to look through the same lens. A framework (such as scrum) is shared, along with an agreed-on definition of done. Both observers and participants can see what’s being accomplished and interpret the results in a common language.

It’s important not to miss the critical value of transparency within the inspect-and-adapt process. Without a transparent culture, decisions are made with inaccurate data. Far too often we see organizations value fake good news over truth and end up making decisions based on bad information.

Following are some basic principles of employing transparency in your projects:

• Just the facts. Display what is fully true to stakeholders specifically by only showing as complete work that is fully done according to your definition of done.
• Be open and clear about the plan, design, process, and progress.
• Make all information easily accessible to everyone.
• Post the roadmap, the release plan, and the definition of done on the wall where everyone involved can see them.
• Encourage an environment of factual measurements and outcomes.
• Have potentially awkward conversations early.

It’s common to want to avoid having honest and awkward conversations, but avoiding uncomfortable situations can cause problems. (In fact, whole books and courses have been written to teach people how to deal these situations.) You should understand the importance of knowing the hard costs associated with avoiding or delaying awkward moments. The most direct of these costs is time wasted going in the wrong direction and delaying a better course of action. Don’t put off having those uncomfortable conversations; have them as soon as you realize that something needs to be addressed.

Antipatterns

The term antipattern has been used to describe a well-intentioned solution to a problem that instead causes unintended negative consequences. It’s important for an organization that’s adopting or maturing its scrum practice to allow scrum to expose antipatterns as part of the inspect-and-adapt process. It’s also important not to customize scrum to match a flawed culture or practices. Instead, make changes in the culture to facilitate the success of your scrum practice.

You may be familiar with some of the following antipattern examples that occur in management and software development:

• Analysis paralysis: Being unable to move forward due to continual analysis and unwillingness to accept uncertainty
• Smoke and mirrors: Creating the illusion of further accomplishment, such as overstating quality or completeness
• Seagull management: Swooping in as a leader and making a bunch of noise and then flying away, hoping to have motivated everyone with a sense of urgency but instead causing fear and panic

Scrum teams and agile leaders need to look for the root causes and cultural antipatterns that block the feedback loop. Once the antipatterns are identified, they should be escalated to leadership as an impediment to the scrum process. Removing these cultural impediments needs to be a priority because they may hinder multiple scrum teams within the organization.

External Forces

A team can be affected by things outside the team that affect its ability to deliver the product. These forces act like a headwind or crosswind that forces an aircraft off course or behind schedule.

For scrum teams, these forces may be changing regulations, evolving architecture, or reprioritized features. A team may be powerless to change these realities, but scrum exposes the effects of the forces and often exposes alternative courses of action.

One common excuse for saying that scrum can’t work in an environment is that external forces make it impossible for scrum to be successful. But scrum can succeed anywhere as long as there are sufficient buy-in and effort from the people involved to make it work.

In-Flight Course Correction

This section goes back to the analogy of the flight crew and the flight plan to explain the dynamics at play in planning and replanning based on empirical data. A flight crew always plans the details of an upcoming mission based on parameters assigned for that mission. The crew estimates fuel use, time in flight, and execution details based on all known and expected details. On the day of the mission, the crew members gather any updated weather reports and mission changes.

When the aircraft is airborne, members of the flight crew continuously evaluate speeds and headings and compare the plane’s actual position with the flight plans. Figure 6-3 shows a planned route and a measured location in flight.

© John Wiley & Sons, Inc.

FIGURE 6-3: A flight path.

Each time crew members measure the location in flight, they evaluate why they’re moving away from the plan. They look at the data to determine possible causes for the course adjustment, such as unexpected wind directions or velocities, or a difference between the planned heading and speed and the actual heading and speed. Next, they use the new information to adjust the plan to achieve the mission objectives — all this while going faster than 400 miles per hour. The flight crew repeats this inspect-and-adapt process over and over to ensure a mission’s success.

In scrum, sprints (see Chapter 5 in Book 5) serve as perfect times to reevaluate and improve plans. In a transparent organization, new information is welcomed and applied to achieving product success.

It is important to avoid the costly overhead of redundant or bureaucratic parallel processes. Some well-intentioned organizations expend more effort in measuring status and producing status slides than they do in building products, all in the hope of maintaining control or avoiding uncertainty. Creating status reports is an unnecessary parallel activity. An organization that has transformed to being agile and that has fully adopted scrum lets go of these artifacts and embraces the new way.

Testing in the Feedback Loop

In scrum, you test during every sprint, doing things such as code tests, functional tests, and tests for user feedback. Contrast that type of project with a typical waterfall project, in which testing happens only at the end of a project. Finding errors at the last minute causes either heroic and expensive fixes or pushing out the timeline. Like an aircraft whose path goes uncorrected, a product that is not validated ends up way off course.

The feedback received during testing and customer validation as the sprint progresses necessarily informs the daily priority. Corrections in the product are usually made the same day, while they’re easiest and least expensive to fix and don’t hold up further progress.

On a scrum team, everyone is responsible for everything. It isn’t up to one specialized tester to test everything for everyone else. The entire team owns the outcome, and all members care about quality.

A Culture of Innovation

Many companies, from the newest to the oldest, say that they want to be innovative. They likely see the market advantages of creative approaches. Yet the command-and-control structures that they use to manage products and processes impede the innovations they seek. Organizations’ fundamental beliefs about purpose determines whether their teams work in a culture of innovation.

The scrum framework functions best in a culture of self-organization, purpose, and innovation. Product and process innovations are encouraged via the inspect-and-adapt model, and the idea of innovation is at the heart of working as a team. Using the feedback loop is a great way to encourage innovation.

Following are some ways that you can create an innovative culture:

• Empower teams to challenge conventions or constraints.
• Remove organizational barriers to creativity.
• Rethink how you motivate.
• Seek out creative lateral-thinking people.

Psychologist and philosopher Edward de Bono is credited with coining the term lateral thinking, which he defined as a mindset of challenging conventions and constraints. A lateral thinker can overcome his previous beliefs about limitations and conventions. A person who engages in lateral thinking doesn’t ignore the existence of constraints; instead, he searches for ideas and solutions that aren’t immediately obvious.

A popular modern narrative seems to be that engineers and developers are robotic, logic-based or linear thinkers. That isn’t the case for most highly effective knowledge workers. They’re creators with well-honed cognitive skills who can’t be replaced by the complex algorithms that they create, and they thrive in a culture of innovation. As companies trend toward replacing business functions with automation, they need to make space for lateral thinkers who can go beyond perceived constraints. Without creativity, people get stuck making the same mistakes.