CHAPTER 4

Throw the Textbook Away

In theory there is no difference between theory and practice, while in practice there is.

—Benjamin Brewster, 1882

Mike knew a big move was needed.

The transformation at a century-old publishing company was stuck. Mike Anderson was asked to take it over and evolve it to the next phase. When he joined the firm, he started his discovery with several conversations, meetings, and reviews. He noticed some very helpful things had already been done. The technology group had reorganized into small multiskilled teams. They had aligned to an organizational cadence of working in consistent two-week cycles. They had even flattened the organization over several years, removing several layers of bureaucracy. But one problem was popping up over and over: The agile job titles got in the way.

Over the last twenty years, the strangely titled Scrum Master role has emerged as an established position in organizations wanting to accelerate team delivery and improvement.¹ It was envisioned as a facilitative master of ceremonies for a given work team, encouraging collaboration and focus. The official definition says,

The Scrum Master is a servant-leader for the Scrum Team. … The Scrum Master helps everyone change [their] interactions to maximize the value created by the Scrum Team.

It could be described as an empowerment and improvement specialist embedded on the product team itself. The good news is that the industry has seen enough value in the role to where there are thousands of “Scrum Master” job postings the world over.

Yet, ironically, many in the industry misunderstand the role to be the process policeman for an organization. Many of these facilitators would judge their value on the degree of textbook perfection with which the team performs the Scrum framework. They would focus their energies on the process checklist (fifteen-minute stand-up, lessons-learned meetings, well-formatted backlogs), rather than how well they were thriving or evolving.

This was Mike’s problem. He saw a lot of process policemen at his office, where dogma prevented experimentation and improvement. In his role as the transformation lead, he would intervene with some powerful questions: “After the process audit, what do you do next? You’re holding these stand-up and retrospective meetings, but you’re never teaching people why we actually hold them. How are you really improving these teams?”

His tough-love challenges would inspire some initial agreement from them and a commitment to change. But very quickly those empowerment specialists went back to old enforcement habits. It was time to shift perspectives by eliminating the distraction. No more Scrum Masters. Mike decided to keep the people and eliminate the old titles. Keep the team-level change agents but radically deviate their role from the established definition.

It worked. A few months after removing the job title associated with fostering collaboration, he was seeing more collaboration on the ground.

The Problem with Practices

In this chapter, we will explore a recurring pattern leaders experience on their path to agility. We will learn that much of what you’ve been told is hype. We will systematically deconstruct and debunk the most conventional advice about building high-performing, innovative, collaborative organizations. Specifically, the pattern goes like this:

• The Boost. Yes, it was good to install best practices.

• The Barrier. And yet, they’re doing it wrong.

• The Rebound. So throw the textbook away.

The Pattern of Untapped Practices

The Boost: Yes, It Was Good to Install Best Practices

Good decision—let’s use some practices that are out there in the industry. They’ve been proven by thousands of organizations and come with a corpus of literature and tools to support their use. Moreover, we gain credibility by using a modern management approach that didn’t involve reinventing the wheel. Put simply, best practices are a good idea.

Leaders Install Best Practices

The Barrier: And Yet, They’re Doing It Wrong

We get frustrated because our teams are not rising to the challenge. The process or framework should be yielding more benefit, but our staff are either struggling with them, resisting proper execution, or just plain confused. It’s not sticking. Why is this so hard for them?

If you’ve tried these modern practices, then maybe you’ve run into one of these examples of poor agility:

• The daily stand-up takes forever, disrupting productivity.

• That “empowered” team still defers to their manager, who serves as a bottleneck.

• The work items are too big and keep slipping to the next deadline.

• Teams are interrupted with work that sneaks in through back channels.

• People incur double overhead by practicing new methods on top of the legacy practices already in place.

• Lessons-learned meetings repeat the same problems each month, with no meaningful change.

• The teams don’t understand how to format their backlog or documentation, so you do it for them.

Leaders Struggle with Poor Practices

This happens because you have what I call “right team, wrong agile.” Just because it worked in your last environment doesn’t mean your current environment is similar enough for it to work this time. Just because that case study highlighted a fancy technique for your sector doesn’t mean your team is ready to try it.

The Rebound: So Throw the Textbook Away

So what do you do? You explore how to modify those sacrosanct systems to address the reality on the ground.

• The data does not match the dogma. A little digging reveals startling secrets that debunk some common convictions about agile practices.

• Find your legs. We will introduce a set of simple questions your team can use to figure out how to get past the confusion and difficulty of agile mechanics and get started.

• Find your own agility. It turns out we can adjust our practices with intent. Doing so avoids diluting their value and better fits the context.

The Data Does Not Match the Dogma

Earlier in the book, we saw that agility generates improvement more often than not. So the next question would naturally be “What did you do to achieve those results?”

The experts, champions, authors, and consultants would all say those successes are wholly contingent on the proper implementation of best practices, proven frameworks, and robust technologies. However, the latest survey from practitioners across the world says something different.²

• Unconventional speed. While 63 percent report better speed of delivery, barely half of the same group are doing so with frequent releases. A meaningful number of organizations are somehow delivering faster without delivering frequently.

• Meetings are not enough. More than 80 percent practice a full suite of formal collaboration meetings, from daily stand-ups to short-term planning, to public reviews and retrospectives. But only 69 percent are experiencing any organizational benefits at all. For many people following the most common practices, something else is missing.

• Customers not required. The standard advice for improving customer satisfaction is to embed a dedicated customer, sponsor, or product owner into a delivery team. Yet somehow nearly 64 percent of teams experience improved alignment between sponsors and teams, when only 57 percent of them have that required role in place. Apparently, when it comes to making customers happy, their involvement is helpful but not mandatory.

• Poker isn’t the point. Among the most hotly debated practices is that of team-based estimation of work assignments. Referred to as “planning poker,” it may take more time, but asking the whole team to assess their workload will be more accurate compared to the sole expert judgment of a senior team member. And yet, while nearly two-thirds practice the technique, only 52 percent experienced the increased predictability it was supposed to yield.

We see there are both hits and misses that happen, despite the use or non-use of the very agile methods we advocate for. How is this possible?

Find Your Legs

The seduction of best practices comes from the very real fact that they’ve worked so well for so many people. There is value and substance to them. However, my reality often doesn’t cooperate with your history.

Let’s say you do believe in the power of more collaboration, more creativity, more engagement, more flexibility. Let’s say your boss approves of you inserting Scrum, Kanban, or DevOps to achieve that vision, but he wants a roadmap for what this initiative will look like. So you do some research and come up with a plan that shows concrete milestones. It even comes complete with a hockey stick chart that shows performance moving up and to the right.

It turns out the path to excellence is a bit bumpier than that. In fact, most change journeys follow a reliable pattern of pain before we get to the promise of a better tomorrow. The truth often looks less like a hockey stick and more like what scientists call the J-curve. It describes a phenomenon we all know simply as this: it gets worse before it gets better.

The J Curve of Change

Here are some fields where the pattern has been identified:

• In economics, the curve plots financial returns over time. Whether it’s the profitability of a product or the capital gains of an index fund, the short-term costs run pull the curve down. It’s only over time that gains are recognized.

• In geopolitics, author Ian Bremmer discovered the pattern describes the fluctuation of nation-state stability (Y-axis) over a progressively increasing degree of openness (X-axis).³ When relatively stable totalitarian regimes explore certain human virtues like democracy, freedom of the press, and civil rights, things initially get worse (e.g., the Arab Spring). It’s only when those societies move further into those virtues that hope begins to emerge.

• In family therapy, author Virginia Satir used this to illustrate how change impacts personal fulfillment over time. She follows the “change curve” through four sequential stages, from status quo to resistance to chaos to integration.⁴

If this pattern has economic, social, and emotional elements, then it’s no surprise that we see it appear in organizational transformation as well. As we venture into our transformation, things get awkward, different, frustrating, even painful. Only over time do the changes settle into a new stability. When it comes to injecting positive change into the status quo, be prepared for the roller coaster.

It’s Easy to Blame the ScrumButs

Let’s go back to that Scrum framework. It is easily one of the most popular frameworks in the innovation, DevOps, and agile movements.⁵ Unfortunately, beginners tend to make mistakes. Lots of them. Either they don’t fully understand the method or they flex some of the guidelines intended to be very fixed. Instead of just letting beginners go through their growing pains, some thought leaders have succumbed to their frustration, and refer to these beginners by a handy epithet, the ScrumBut:

[Scrum] is designed to provide the desired benefits and address predictable recurring problems. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.

A ScrumBut has a particular syntax: (ScrumBut) (Reason)(Workaround)

ScrumBut Examples:

“(We use Scrum, but) (having a Daily [stand-up meeting] every day is too much overhead), (so we only have one per week).”

“(We use Scrum, but) (sometimes our managers give us special tasks), (so we don’t always have time to meet our definition of done).”⁶

The implication is that those who modify the framework reveal less of a genuine wrestling with a different way of working and more of a flaw of personal character.

But what if we begin daily stand-ups the only way we know how? With formal agendas, too many participants, and a cumbersome teleconference system? Are we weak in the knees or just getting started?

But what if we haven’t figured out the bottlenecks in our delivery process? Does extending the maximum one-month work cycles into two-month cycles reflect a commitment to the past or just a symptom of problems we’re figuring out?

But what if it takes me more than a year to unlearn twenty years of habitually interrupting my staff? Am I an evil supervisor or merely beginning my journey of self-awareness?

A Google search for “ScrumBut” yields well over 100,000 results for such a funny word. Apparently, it’s quite common to get frustrated with imperfection. The problem is that frustration can turn into judgment. By using a humorous label to highlight noncompliance, we may actually be discouraging people who need help, not criticism.

But Isn’t Growth the Whole Point?

If you feel, like me, that this is a bit judgmental, the good news is we are not alone. Blogger Cliff “The Clever PM” Gilley makes the point that the concept of growing into high performance means not starting at high performance:

“ScrumBut” implies perfection at the start. … If the direction that these people are getting is that Scrum is an all-or-nothing proposition (which is precisely what “ScrumBut” does), then the change agents who are trying to make incremental changes have yet another hurdle to overcome, one tossed into the fray by the very people whom we want to provide support to our efforts.⁷

He makes the fairly obvious point that, in order to something well, we must first do it poorly. Not merely doing the practices themselves poorly but also doing the learning, the evolution, the incremental improvement poorly.

Moreover, the end state of high performance often ends up looking quite different from the textbook set of practices we’ve all come to admire. This is the additional point made by Jurgen Appelo, TEDx speaker and author of the breakthrough book Management 3.0:

A process or method is a description of behavior. Scrum describes how a development team might be able to successfully deliver software to its environment. But because optimal behavior is a function of internal structure and external environment, the real optimal method always depends on the team’s structure and environment.

In short: the optimal method will always be an adaptation. …

It’s OK to say, “We do Scrum, but we don’t do stand-ups because there are only two of us, and we already communicate all day.”⁸

Given that most professionals will already have exposure to so many established techniques, a strong case can be made to just use them. In fact, several of your team members will already have deep experience using some or all of the techniques out there. Meanwhile, with so much literature already available, doing anything else might inspire blowback from your teams:

“Why is there no automation in this department?”

“Why are these requirements not written in the user story format?”

“Why do we not have a Scrum Master running this meeting?”

So how can we take advantage of those tacit assets without the inevitable judgment, frustration, and pain of some people and some teams just starting out?

Crawl, Walk, Run

We’ve already discussed the dynamics of growth on a personal level and a team level. There is a rich body of research on adult development and team maturity, but it’s not necessary to read it to understand this commonsense principle: you can’t be perfect the first day you do something.

• Crawl. Initially, we try a technique as best we can. We will violate several recommended guidelines and get only marginal benefit from the technique. It feels awkward but doable.

• Walk. Gradually, we get better. We remove the barriers, the overhead, the confusion that held us back in the beginning. As we get better, we get more benefit. It looks and feels good, but we know it’s not ideal yet.

• Run. Eventually, we get pretty good. We meet or exceed the recommended guidelines and thrive together.

Crawl Walk Run

That’s it. We give ourselves permission to start with what we can and make a commitment to grow into it. Here are two examples from real teams in the real world of how violating best practices can actually represent growth.

Find Your Own Agility

We’ve been told that if you want to create empowerment and engagement on your teams, you follow a specific proven set of steps:

1. Form a team.

2. Tell them they are empowered.

3. Watch the magic happen.

Empowered self-organizing work teams are the center of most agile methods. If you want high performance, you ask your people what they think we should do to help them get better.

But one submarine commander did something completely different. He didn’t ask staff. He asked the middle managers instead.

In his book Turn the Ship Around! former U.S. Navy captain L. David Marquet shares an inspiring case study.⁹ He walks us through his messy journey of transforming the worst submarine in the navy into the best in the navy.

So how did he do it? He had to find his agility, a collaborative operative system specific to his boat. So he asked all his noncommissioned officers (NCOs, whom he calls middle managers) what control meant to them. They said it was about paid time off (PTO). Apparently, at the time there were four layers of PTO approvals. If anyone wanted to take a day off, and the team lead approved it, that wasn’t enough. It had to go to the junior officer, then the executive officer, and then the captain himself.

But if the original team lead’s decisions were supported by the officers, then he could now control who was going to backfill, who was the backup, who was going to cross-train the backfill and the backup. The authority to do one thing sparked the freedom and creativity to do several other things. Rather than just follow the literature, Marquet found their keystone, their linchpin, their agility.

Agility Requires Tailoring Practices

Much has been written in the project and product worlds about “tailoring” processes and practices, based on the work being done. Let’s pause for a moment to take a look at some key points. The 2017 ANSI standard for project management defines it officially as follows:¹⁰

Determining the appropriate combination of processes, inputs, tools, techniques, outputs, and the life cycle phases to manage a project is referred to as “tailoring” the application of the knowledge [of project management].

That’s a fancy way of saying that each organization should customize its approach to delivering work based on the specific dynamics and demands of the environment. Moreover, these adjustments are not optional. The guide goes on to say:

Tailoring is necessary because each project is unique; not every process, tool, input, or output identified in [this standard] is necessary.

Now if you think that point is only for traditional project management and has nothing to do with Agility, then you would be mistaken.

The original Agile Manifesto closes out its declaration of values and principles with this very topic:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

That’s the conclusion, the climax, the final word. Kind of important.

So whether you come from a formal standards perspective (project management) or a more informal values-based perspective (Agile Manifesto), the expectation is the same: modify how you do your work, based on the situation at hand.

Put another way, if you believe in continuous improvement, then by definition whatever practices you are using are not optimal. If you are still using that fancy new management method strictly out of the box, then you are simultaneously neither compliant with international standards nor consistent with the spirit of agility. Not adjusting your practices is a double-fail.

The Three Ps: Pain, Purpose, Pivot

Unfortunately, there is almost zero guidance on how to go about tailoring effectively. Much of the literature in place today strongly advises that you do it but offers no filters, guardrails, or tips for doing so. That’s a problem, because if we don’t make the right adjustments we can get some very unwelcome side effects.

• We don’t change it enough and still struggle unnecessarily.

• We change it too much and lose all the benefit we’re trying to get.

How do we customize our practices without diluting their potency or even making things worse? We need to offer people a viable alternative beyond all-or-nothing. To do that, we can walk through a simple set of questions to figure out some degree of doing things better:

1. Listen to their pain. Ask the team what is the specific frustration, difficulty, challenge they would face if we were to use a given technique.

2. Explain the purpose. Share the underlying principle of why we recommend that technique. What is the intended benefit?

3. Solicit a pivot. Ask the team how might we adjust the technique so that we could get at least some of that benefit.

Here is how the process works in real life.

These are just a few examples—your mileage will vary. The point is a little agility is better than none. Regardless of where you work, there is already plenty of improvement lying dormant in your project. Take these simple steps, host a collaborative conversation, and warp those best practices to achieve a little more untapped agility.

Mike’s Success Story

Recall Mike, our transformation leader at the publishing company we learned about in the beginning of this chapter. He was frustrated by his collaboration facilitators, Scrum Masters, viewing their role as process police. His move was to keep the same Scrum framework in place but remove the formal master-of-ceremonies role that was causing so much drama. In my follow-up conversations with Mike, I asked him how his experiment was going.

Have there been any consequences of removing the established practice of a formal Scrum Master role?

One of the new frustrations I’m hearing is that the change put into limbo those who were holding the title. Despite our detailed transition plan and communication efforts, they didn’t understand the alternative roles we offered them. We said, “You have to flip into another role: project manager, product owner, technical leader, etc. You tell me what you want to do and where you think you would fit the best on your team or in the organization. You pick your destiny, and we will be here to support you, since we’re making this change.” Yet, despite our efforts to make the transition seamless, it has still been difficult. It’s because we removed what they knew. The industry says to use this method, it must be done this way, and we’ve violated that prescription.

Fair enough, but what has the change allowed you to achieve as an organization?

Firstly, we removed the false conflict with those holding “project manager” titles. A lot of the Scrum Masters do have project management backgrounds. And yet it was always Scrum Masters against project managers, bickering over where lines were drawn. But they all do the same thing: help projects be more successful. Now we don’t fight over that anymore, because the artificial distinction is gone, and surprise, surprise, the teams are still working autonomously.

Second, the business sponsors are working a lot more fluently with technology teams now. Before, teams were discouraged from interacting directly with business sponsors. Sponsors would make decisions and drive them down to the product owner, who then transmitted that information to the teams. That product owner role became a wall we didn’t even notice. The teams only ever heard a watered-down version of what their business counterparts were dealing with. So by ditching the conventional Scrum roles as they’re traditionally understood, the hope is to create more alignment. After the changes we made, it was more acceptable and encouraged for business and execution teams to interact directly.

Bottom line, it wasn’t pretty, but it removed our biggest barrier to getting to the next level of high-performance collaboration.

Summary

In this chapter, we’ve challenged the conventional understanding of modern practices like Scrum, Lean Startup, Kanban, DevOps, and so forth. In the pursuit of textbook perfection, we’ve learned:

• The data does not match the dogma. The latest research reveals that much of what experts demand as mandatory actually isn’t.

• Find your legs. Growth requires doing those practices poorly before we do them well.

• Find your own agility. Context requires tailoring and adjusting. Use the three Ps (Pain, Purpose, Pivot) to experiment with intentional modifications of established practices.

The path to higher performance often does start with proven frameworks, established techniques, and known methods. But eventually you will have to break them in order to find your untapped agility.