The Dolphin and the Tortoise: How Self-Awareness Impacts Agile Transformations

By Jason Wrubel

ADAPT or else…

When companies reach the peak of their growth, they tend to hide in their shell, like tortoises, and stagnate. Leaders have to realize that the first step to transforming into a forward-thinking organization is to become self-aware like dolphins. Companies must know where they’re starting from, their strengths a

• Language: English
• Publisher: Wrubel Consulting, LLC
• Release date: Jan 14, 2020
• ISBN: 9781734258301

Jason Wrubel

Jason Wrubel drives large-scale agile transformations for public and private companies across industries. He combines the foundational skills he has developed over the last twenty years working at consulting firms with the operational and technical know-how he gained at high-growth start-ups. Jason is the founder of Wrubel Consulting, and enjoys working with a range of large and small companies to drive the delivery of value to their customers with greater speed, efficiency, and predictability. He grew up in New York and studied economics, history, and business at the University of North Carolina Chapel Hill. He currently lives in New York City with his wife, daughter, and son.

Book preview

Introduction

DOLPHINS AND TORTOISES

Galapagos tortoises have a lot going for them. They have one of the longest life expectancies of any animal, with some living up to 150 years. Generally, they weigh a quarter of a ton but don’t require a ton of food to sustain them. Perhaps most appealing is that they’re by and large impervious to harsh weather and would-be predators: their shells create an insular fort; they merely have to dig in and hide behind that tough exterior, ensuring that they’ll live another day.

Dolphins also have a lot going for them. They’re incredibly social creatures, not unlike humans, forging bonds with others, caring for their injured, living in groups of around twelve members, and communicating by unique verbal and nonverbal means. They can learn, they can teach, they use simple tools such as marine sponges, and significantly, they can cooperate. They have very complex social networks. Dolphins are also one of a handful of animals who are self-aware: they can see themselves in the mirror and understand what they’re seeing is their own selves. This kind of self-awareness is a precursor to advanced intelligence. They use their reflections to investigate and figure things out about themselves.

Companies have to know themselves and take part in an investigative process to adapt to a new framework.

Both of these animals enjoy popularity with marine animal lovers, and both have thrived in one way or another. But if you were to bet on one of these creatures lasting far into the future with the various threats facing the seas, the climate, and their ecosystem, you probably wouldn’t take the slow-moving tortoise, with its reproductive issues and placement on the endangered list. Thanks to their complex social networks, self-awareness, and adaptability, dolphins represent how a twenty-first-century company should strive to be: cooperative, communicative, and agile.

It’s the self-awareness that makes the dolphins so advanced, and continually investigating. And it’s the lesson that I like to impart to businesses in which I embed myself as a consultant. Companies have to know themselves and take part in an investigative process to adapt to a new framework. In order to deliver value more quickly, more predictably, and with higher quality if you’re undertaking or fixing an agile transformation, you need to be self-aware enough to know where you’re starting from, what your weaknesses and strengths are, how you operate, and what you want to accomplish.

When companies reach a level of growth and age, they have a tendency to dig in and entrench themselves in what seems comfortable—what they’ve always done. Forward-thinking organizations recognize that the landscape is continually changing and self-evaluate a lot; they communicate, intermingle, and adapt. This is all to say that if you want to succeed with your agile transformation, don’t be a tortoise. Be a dolphin.

Chapter 1

A BETTER AGILE IS CLOSER THAN YOU THINK

Stop me if you’ve heard this one: Months ago, company X had agile thrust onto it by a senior executive, and in a whirlwind week and a half, an army of besuited outsiders swooped in and presented a So You’re Going Agile! workshop, designating former project managers (PMs) as champions, despite the fact that nobody really knew what was going on. The response was underwhelming at best. Now some team members are quietly acknowledging their frustration in the new world of agile while others are a lot more vocally expressive about it. What’s more, the company that promised a big return on the investment in agile thought leaders came with a pretty hefty price tag … and yet nothing’s changed.

Managers have been barking orders to software engineers, telling them how important it is to follow preexisting steps. The engineers could not care less about the transformation. Morale is down, and designers feel disconnected from the product. Retrospective meetings are actually hour-long venting and finger-pointing sessions. Upper management is concerned with metrics, and executives consider themselves separate from the entire process. Valuable work time is spent on coming up with story names and templates, people are drowning in burn-down charts, and the 850 scrum rules are getting on everyone’s very last nerves.

If any of these obstacles sound familiar, don’t worry. You’re not alone. While agile is an incredibly useful and productive approach for our day and age, it’s being implemented poorly—and in many cases flat-out incorrectly—at businesses across the world. In fact, often, the main beneficiary of an agile implementation is the fancy company that set up the training schedules and doled out certifications in scrum, Nexus, LeSS, and everything in between. Unfortunately, these courses are taught in a vacuum, often in ignorance of the workplace and the people they will impact. And a two-day seminar wouldn’t be able to automatically create product owners (POs) who can help transform a decades-old internal methodology. There’s no one-size-fits-all approach when it comes to agile. Every situation is unique, every company is unique, and every employee is as well.

I get this question a lot: How can I, as an individual, compete with a company sporting a fifteen-person, $3 million engagement, offering quick and easy agile implementation? After all, I don’t have training in product management, or software engineering, or design. I’m a guy from Westchester by way of North Carolina who thought the only way to fix the Nintendo Entertainment System (NES) gaming system was by blowing on the cartridges and furiously hitting the reset button. But corporations looking for an agile transformation are seeking out my services because they understand that what I’m preaching isn’t shortcuts and easy certifications and nicknames.

My diverse background taught me that all things are about people and relationships. And managing those is what I became really good at through my experience working with product, software engineering, and operations teams at start-ups and Fortune 1000 companies. My added value is not in content; it’s not in expertise in these technical spaces. What I bring to the table is something every company needs: an understanding of what makes people and organizations tick, and a knack for getting the most out of both.

No matter how automated tasks become, and no matter how far-flung our workforces are, any company that has employees, systems, and processes—and that’s just about every company in the world—has the same needs and runs into the same roadblocks. Invariably, every company needs somebody to come in and ask the questions that have to be asked. Every company requires someone to show them how they can improve their operations, someone to be a mentor and coach, and most importantly, someone who understands people and relationships.

Before you can replace a decades-old methodology with agile, you have to do one simple thing: know yourself.

That understanding is the sine qua non for instituting agile.

Before you can replace a decades-old methodology with agile, you have to do one simple thing: know yourself. That’s my approach, and it’s something I’ll come back to. Know what your company is solving for, know how the people working for you operate, know how the executives think, know where your organization is, and know what your workplace environment is like. Let’s analyze your workforce and extract the most out of them; let’s craft positive and collaborative working relationships between somebody who’s been coding for twenty years and a PO who doesn’t know the first thing about software engineering. Let’s drill down to your company’s core values and quantify your culture.

That’s what I do, and that’s what this book will reflect.

Because so much of the internet economy is based on catching up to, and keeping up with, the Joneses, for fear of being left behind, companies are looking to adopt new technologies, policies, and structures before fully understanding what exactly they’re bringing on. People were proselytizing about shifting to the cloud before executives even fully understood the implications and requirements of that shift! And over the past eight or nine years, there’s been a rush by multibillion-dollar corporations with thousands of employees to implement Agile—with a capital A—the flashy version of it sold from a one-size-fits-all container.¹ After all, it’s hot, it’s popular, and since the rise of the flexible start-up, many companies are bending over backward to onboard the entire process. You can imagine the voices from above hurriedly making this decision: Hey! Everything’s changing! We should be like a start-up! We want to be agile. Cheetahs are agile, right? Let’s be like cheetahs! Let’s get that high-priced team to teach us the steps, let’s assign a champion, do a two-day workshop, and bing-bang-boom!

The very mention of the term agile may cause a pressured executive to break out in a cold sweat. But as with all well-intentioned dogma, it’s not the actual principles and practice of agile that are overwhelming; it’s the misunderstanding and perversion of it that has led to needlessly confused people and companies.

There are numerous ways agile can be adopted poorly by your organization if you’re not ready for it. It can be forced down employees’ throats, leaving them frustrated. It can be shoehorned into an environment that’s not conducive to change, which can lead to friction between departments. The demand for strict adherence to hundreds of rules can set the entire staff grumbling. After all, if you don’t know the principles, you’re a slave to the rules. That’s true for the Bible, the Constitution, and yep, for agile as well.

Those companies looking to teach agile in a weekend intensive or on the fly are missing these essential ingredients in their blueprint, and because of that, businesses falter with rushed or poor implementations. And that’s why the previously explained scenario perhaps rings some bells, and why you’re reading this book.

Adopting agile for your company can have incredible benefits but requires a holistic approach, which starts with truly understanding the underlying principles. And to get the most out of this workflow philosophy, you need to understand why agile works, what it is, and perhaps more importantly, what it isn’t.

We’ll explore that in a second. But as we dig into this book, unpack the philosophy, and explore these principles, and as you work on knowing yourself, put your mind at ease by asking yourself if you believe that the customer knows what she wants more than you do. And do you believe that your job is to deliver value to your customer? If you do, then congratulations! You’re living up to one of the core tenets of agile. The rest is all execution.

---

1 You’ll notice, throughout the book, I mostly refer to agile with a lowercase a . This is what we talk about when we refer to the actual underlying principles that companies can adopt for a more effective and quicker workflow. Think of capital- A Agile as the crass marketing of the form. When companies don’t necessarily know the principles that will make them agile, they end up implementing only the steps toward agile.

Chapter 2

WHAT AGILE ISN’T … AND WHAT IT IS

A 2018 survey of almost six thousand executives, directors, and practitioners in project management reported that 46 percent of completed projects at their organizations had used either an agile or hybrid agile-predictive approach over the prior twelve months. Additionally, 80 percent of federal operations and technology projects in 2017 were described as either agile or iterative.² Not surprising, considering the benefits, or that such tech powerhouses as Amazon, Google, Apple, Facebook, and Microsoft all incorporate these principles to some degree.³

But despite its increasing popularity, misinformation persists.

Maybe you’ve heard some myths about agile: There’s no commitment to dates, there’s no documentation. It’s just about making software engineers code quicker. It’s only relevant to software engineering. There’s no planning. It’s undisciplined. It’s just a new fad.

These assertions are simply not true. But how did they come to hold such sway?

Agile was a direct response to the changing landscape of product development in a world with quicker business cycles and the need for more flexibility and less arcane, less rigid practices.

From bad experiences, possibly. Any organization that believes those fabrications isn’t benefitting from a correct agile implementation. Or maybe it’s the fear of committing to something fundamentally different from what we’re used to. Change, after all, is hard.

But agile didn’t come about in a vacuum for the sake of shaking things up. It was a direct response to the changing landscape of product development in a world with quicker business cycles and the need for more flexibility and less arcane, less rigid practices.

For much of the twentieth century, the only approach to software engineering project management was waterfall, a linear flow of work that would require a set amount of time for each phase from requirements gathering to design to development to testing to deployment. Each step could only be completed after the preceding step was