CHAPTER 3

Give It Away

I have observed, throughout life, that a man may do an immense deal of good, if he does not care who gets the credit for it.

—Father Strickland, Jesuit priest, 1863

Randy was ready to make an impact.

A large 100-year-old manufacturing company was struggling to keep pace with the market, and recent layoffs would only serve as a temporary Band-Aid. In the wake of those moves, a newly installed CIO was determined to help turn the tide. She challenged her IT group to introduce more innovation into every facet of the organization. “We need more ideas on the table, and once those ideas are validated, we need them out to market faster than ever before. This is our number one priority.”

The key strategy for this initiative was to “go agile,” and Randy Angiel was hired as an external consultant to facilitate some training and chartering for the first pilot. This was a famous company, and they were ready to do some serious work. Randy was amped up about the opportunity.

The day of the pilot launch started off solid. The room was filled with the full representation needed to deliver the project: project managers, product owners, designers, technology, and operations. Granted, most of them had very little exposure to agile methods. Fortunately, the engineering group had some experience and could help spur discussion about textbook techniques. Randy had spent the morning level-setting everyone on techniques like sprints, shorter delivery cycles that would cut down timelines from months to weeks. To illustrate the concepts, they played an interactive game with marshmallows and spaghetti that got everyone laughing.

The room was energized. People were engaged. Randy was in his element. The next item on the agenda was to hear from the engineering group.

And that’s when it got weird.

Randy transitioned: “Lisa, I hear you’ve been experimenting with these techniques for a while. Perhaps you can share how you’re trying them out.”

Engineering manager Lisa corrected him: “Oh, we’ve been sprinting for well over five years. We’ve got an established process.”

Randy was intrigued. If engineering had been using agile techniques for years, then why did the CIO mandate an agile transformation? He probed further: “Interesting. Give us some examples.”

Lisa: “The engineering teams are fully autonomous, within established guardrails. They pick assignments from an ordered backlog, working in two-week cycles. We also incorporate a high degree of the automation you mentioned this morning, which has reduced defects to near zero.”

Randy: “Wow, that sounds like a well-oiled machine, and a real asset to get our initiative going. How soon will the teams be mobilized to work on this pilot?”

Lisa, nonchalantly: “Two months.”

Randy: “But the CIO said this was the highest priority pilot of the highest priority initiative, to keep the company alive. We are authorized to drop everything and get started.”

Lisa: “Those are fair priorities, but there’s a ton of setup we need to do before the teams can start working. We need to convert the project charter into a use cases document and then into a design document. We then convert that into a list of specific features and an MVP. Finally, we convert those features into a proper backlog using the given-when-then format. Only then can we use those details to estimate all the work items and build out a release timeline. Those activities take two weeks. Each.”

Ugh. They had overloaded their modern practices with a lot of other rigid documentation and planning steps. Randy knew the two-month delay was not going to fly, so he tried sparking more dialogue with an idea. “What if we replace your product backlog with the project management charter, and use that as input into engineering? That would cut out three steps and get things moving faster. We get them working right away on the most obvious work items, and do all that elaboration in parallel.”

Lisa was unmoved. “Oh no, we don’t do that. That would involve the project management office, which we won’t do, because they would undermine our autonomy. Besides, the teams don’t like their format. They like it their way, and it works for them.”

Remember, the project managers were in the meeting as well. The room started to get a little tense. As the facilitator, Randy decided it was best to deflect the tension by changing the topic. “Well, let’s go back to those teams and sprints. I’m impressed to hear about your two-week cycles. Does that mean once we get through the two-month upstream process, you can release every two weeks as well?”

Lisa waved her hand dismissively. “Oh no. Our engineering teams hand their work over to the quality department, which manually revalidates the validation we’ve already done. When they’ve done that, they organize a group of employees to review the release and sign off. Then a security scan is performed, and then we can roll it out. All of those things are done by busy people, so it takes a while.”

“So how often do you release new technology to the company?”

“Every six months.”

“What?”

“Yep. That’s how it works. That’s the benefit of our agile process.”

The engineering manager was quite straight-faced, but Randy was dumbfounded. On the one hand, he just surfaced a lot of improvement opportunity. On the other hand, the company was failing, despite already practicing for years the very techniques he was hired to help them adopt.

They had a ton of agile but no agility. And there was no indication their most agile leader was interested in changing that. Tragically, the evolution ended right there. A year later, Randy saw the pilot finally crawl to a finish, well after the new transformation was canceled, and another series of layoffs hit the news.

The Problem with Impact

The paradox of going it alone is that you get going, which is virtuous. But you go alone, which is limited. Here is the pattern that proactive agility champions face over and over:

• The Boost. Yes, you took the initiative.

• The Barrier. And yet, the impact is only in your silo.

• The Rebound. So now, give it away.

The Pattern of Untapped Impact

The Boost: Yes, You Took the Initiative

It turns out that Lisa the engineering manager had launched her own engineering transformation years ago. She was the only one who knew about modern work methods, and waiting for other leaders to come on board would take forever. So she started a mini-transformation on her teams, and they’ve gotten really good at it. It makes sense. She did something to get things moving.

Leaders Take Initiative

The Barrier: And Yet, the Impact Is Only in Your Silo

Despite all the growth your team has made, they’re still only one part of a larger ecosystem of dependencies. You’re all agile, with no agility.

Leaders Struggle with Impact

The good news is you’ve built some internal competency. The bad news is you’re the only champion. For the organization to achieve more, it will need that competency to scale to other leaders beyond your sphere of direct influence. Moreover, those leaders need you to show them how to do it and how to do it in their own way.

The Rebound: So Now, Give It Away

Yes, the beginning was the right time to move unilaterally. Now is the time to do the opposite—to open the change to other leaders, despite the alterations and modifications they will make to it. In this chapter, we explore the underlying problems with limited impact and how to overcome them.

• Expectations versus reality. Leaders have an idyllic vision in their minds, but we will discover the road to change is not paved in gold.

• Give away your agility. By inviting others to the table, more ideas and changes will mess with your vision, but it will expand the momentum further than you could have expected.

• Give away your position. Allowing your role to change will feel frightening and different, but it will solidify your legacy and your value to the organization.

Expectations versus Reality

To understand the expectation leaders have for the journey, let’s use a classic software example:

Expected Transformation Journey

1. First we are waterfall. The waterfall model is a linear sequence of system development. This is the assembly line applied at scale. First we plan all the requirements, then we do all the design, then we do all the building, then all the testing, then all the release to operations and market. We do each project phase in sequence. You only get something when you get everything at the end. The term is a metaphor of water flowing downhill, describing how work is designed to flow downstream, one way. The metaphor emphasizes the noniterative, nonreflective nature of the sequential work cycle.

2. Then we become mini-waterfall. After some training and coaching, we’re starting to transform into the sprints we mentioned earlier. Same life cycle, faster cycles, where we do some of the requirements, then some of the design, then some of the building, then some of the testing. We just did the exact same life cycle for a subset of the project scope. This stage is often ridiculed as a faulty mash-up called “Scrummerfall,” because the firm handoffs don’t look like the collaborative end state we want. It’s not great, but it is progress. Rather than deliver the whole thing later, we deliver something sooner.

3. Soon we are agile. After more improvement, we’ve achieved nirvana. Project scope is decomposed into mini-deliveries, where we all work together iterating on those deliveries. Collaboration gurus call this “team swarming.” We can focus on exactly one deliverable and do the messy teamwork that makes it bulletproof.

That’s the promise. To make this happen, you just need the buy-in from the leaders of all those departments, and we’re off to the races. But that’s not how it goes.

Water-Scrum-Fall

Let’s say agile catches the interest of the develop and build manager. He’s intrigued by the idea of only doing one thing at a time. So he takes initiative and begins a private agile journey. Within weeks, his department is split into teams—Scrumming and sprinting.

But the requirements manager is not willing to ask his staff to break down the scope statement into smaller subsets, let alone mini-deliveries. Her team is already overworked, and that would be unneeded extra effort.

Water-Scrum-Fall

Moreover, the design manager is not willing to compromise on the quality of his team’s design work. To generate the best possible design of the product, his team demands all the scope be considered and incorporated at once.

Finally, the test manager is okay with testing only a subset of the product at a given time. The problem is that any subsequent change may corrupt all of the previously tested items. The more often we deliver, the more often we have to retest everything we’ve already tested. Early delivery be damned. Agile requires rework, and rework is inefficient.

The develop and build manager has transformed, so we’re no longer waterfall. But no one else has moved, so we can’t be agile. Instead, we’re at the intermediate limbo called “water-Scrumfall.” The result is a modernized develop-and-build department but no change in the end-to-end delivery. A whole lot of agile but no agility. And it gets worse.

The Modern Waterfall

Now that design and build manager is getting some attention. Smaller work items means progress is more trackable than before. His teams are holding public demonstrations of incomplete work; they are buzzing with activity. Then the requirements manager thinks there might be something to this. She learns about customer-oriented techniques like Lean Startup, journey maps, personas, and user stories. She challenges her team to experiment with those techniques and gets some internal momentum. Eventually, the design manager feels jealous of the cool factor he sees in the other two. He buys his team training in design techniques like Design Thinking.

The Modern Waterfall

Finally, the test manager gets nervous about being the only one not on the bandwagon. She goes to an agile conference and brings back to her team several exciting new DevOps automation ideas.

All said, the transformation was leader-led, a complete success departmentally, and a complete fallacy organizationally.

And then one day the COO comes in yelling, “I just spent one million dollars on coaching and training. All of you are bragging about your transformation, and it still takes a year for us to get anything done around here. Where’s all my agility? Where is it?”

This tragic story happens quite often. In 2018, Robin Dymond called this out as the “modern waterfall.”¹ We have transformed every department to use modernized best practices, but by failing to work together, we’ve iterated our way right back to the status quo.

Give Away Your Agile

The root cause of these localized transformations is twofold. First is the frame of reference of the leaders in the organization. Most professionals will view the agile movement through the lens of their departmental function. It’s natural. It’s literally their job to assess reality from the perspective of what their organizational unit does. Are you a magazine layout designer? Then you will view agile from the perspective of how it relates to that.

The second root cause is perfectionism. As talented professionals, leaders like getting things right. It’s how they earned their leadership roles in the first place. So when it’s time to jump on the change train, we want the comfort and confidence of building excellence with the new ways of working before we involve anyone else. Involving others will distract our team’s efforts to figure it out, invite unwanted suggestions and changes, and create embarrassment for our mistakes. Moreover, we learned earlier in this book that some company cultures emphasize getting it right over going fast, even for low-risk projects. That becomes a reinforcing dynamic and sustains the pattern of siloed improvement.

The asset? You took initiative to build momentum. The problem? You took initiative but didn’t bring anybody with you. You didn’t ask for help. Fundamentally, the degree of agility you have is determined by the degree of collaboration among your leaders, and between you and your peers.

Overcome the Dependencies

In his 1984 novel The Goal, management theorist Eliyahu M. Goldratt introduced the theory of constraints.² The theory asserts that any manageable system is limited in achieving its goals by a very small number of constraints. Any transformation should focus on finding the most limiting constraint and then reorganizing around that constraint. It’s a fancy way to operationalize the concept that a chain is only as strong as its weakest link, so find the weakest link and fix it.

The theory was a pivotal elaboration on existing management theory. However, it can feel a bit ethereal and vague. Ironically, the book itself described its protagonist as consistently confused and frustrated that his management coach won’t simply explain how to find the problem and fix it.

Thankfully, thought leader and consulting CEO Mike Cottmeyer translated the fancy theory into real-world transformation advice. He explains that dependencies are the problem. Dependencies are the biggest constraint in high-performing modern organizations. Moreover, these dependencies are self-inflicted wounds based on our assumptions. He explains it this way:³

• Labor dependencies. “We assume that we must optimize for individual performance and therefore we matrix team members across [multiple] projects. This creates resource dependencies between projects that did not have to exist.”

• Skill dependencies. “We assume parts of our solution are just too complicated and must be handled by specialists. We choose to assign certain people to specific components. By default, we create dependencies between products that share the same components.”

• Knowledge dependencies. “We assume that our product owners are too busy for the team so we assign someone else to proxy for the business. We create a dependency between the team and the business that results in a tendency to over-document and over-manage the relationship between [those asking for work and those doing the work].”

It’s a compelling bit of analysis, but it leads us from one unanswered question (“What is the key constraint?”) to a different unanswered question (“How do we find and resolve the dependencies?”). For that, the answer is simple: Get everyone in a room together and talk about how to deliver a given product faster than you have ever delivered anything before. Immediately, people will start to freak out. Bingo. You just found the dependencies. This practice is called big room planning and was popularized by many of the various agility methods in the industry.

If you have a collective will to invite people to the table, find the dependencies, and then transform the organization to overcome those dependencies, you will be well on your way to high performance.

Decentralize the Transformation

If you were to take a look at the transformation backlog for most agility champions, it would probably include one or more of the following:

• Charter a center of excellence, so that experts are easy to find.

• Design and deliver a standardized training curriculum, so that we have consistent messaging.

• Run several pilots, so that we focus on early wins.

• Go big, so that the transformation yields results faster.

These all make sense. And yet, strangely, the data tells us these conventional strategies are actually the least effective. According to the latest DevOps research, there are consistent patterns that differentiate the highest performing digital organizations from the lowest.⁴

Organic over Organized

The temptation for a well-managed organization is to conduct a well-managed and efficient transformation. After all, isn’t good leadership about keeping the organization from suffering unneeded churn? But the data says something else. Specifically, higher performers were half as likely to go with a big-bang transformation with top-down direction. Moreover, they were less likely to form a transformation center to draft and roll out an official playbook.

High performers don’t go for a well-organized rollout of new ways of working. Instead, small teams are authorized to pull whatever resources they need to improve their results. Then they let those results draw support for spreading new practices further across the organization, one step at a time.

The more you think about it, the more it makes sense. Consider that the old way of doing things is what got us into the kind of mess that merits transformation in the first place. A habit of running fast, efficient projects means we avoid the creative exploration we need for more innovation. A tradition of defining the new official universal process means we don’t get that culture of highly engaged productivity.

To generate new levels of impact, we need to consider that the next level of answers will not come from us. It will come from them.

Communities over Centers

A key question around change is how to spread knowledge in a way that is both scalable and sustainable. It turns out those conventional approaches of classroom training programs and formal centers of excellence are more associated with the lower performers.

There are a few reasons for this. First, the center of excellence (COE) becomes a bottleneck for deploying needed expertise. You can add more people to the COE, but that doesn’t scale nearly as fast as you need the transformation to happen. Second, it moves expertise away from doing work to merely advising work. The closer expertise is to work being done, the more likely staff are able to physically see what good looks like. Finally, a COE formalizes the divide between those who know and those who don’t. This can create an unhealthy us-versus-them dynamic, undermining the culture aspect of a transformation.

Instead, high performers disseminate knowledge through informal communities of practice. These are meet-ups or chat rooms or webinars, where relevant examples, tips, and practices are swapped among the staff most motivated to spread them. These communities are authorized and supported by leadership, but the content, format, and audiences are wholly self-organized by staff on the ground. As a result, the change is magnetically attracted to those who are most motivated to adopt it.

Intentional over Incidental

It might be easy to misread these patterns as a directive for leaders to “get out of the way” and “let them fend for themselves.” However, researchers make a very clear distinction: “Transformation is not a passive phenomenon. … High performers favor strategies that create community structures at both low and high levels of the organization.”⁵ This implies successful organic grassroots transformations are informed with a clear vision of what success looks like, rather than an ad hoc hope and a prayer.

For example, most organizations use pilot projects to generate momentum. However, a key difference is how the pilot projects are framed. Higher performers were much more likely to design their pilots either as a template for other teams to follow or as a breeding ground of new change leaders to deploy further into the organization. By contrast, lower performers were 156 percent more likely to see their pilot projects stall out and die, because they were merely tactical in nature.

That means pilots should be chartered to answer specific questions (“How do we, at this company, slice our project into smaller incremental deliveries?”) and build new skills (“Let’s learn ways to get our sponsors more actively engaged in these projects”), which can be leveraged further in the organization.

We still need to discover our new way of working. It’s just that those answers should come from the cauldron of practice, proven on the ground, by passionate staff and leadership in our organization, rather than a playbook of techniques copied from some glossy textbooks. If our vision of agility is distorted and diluted in order to become more pervasive and impactful, that is worth it. Broad hybrid agility is better than beautiful siloed agility.

Here’s the question. Is it about agile? Or is it about your agile? If you want a broader impact, you have to invite other people to the table, and when that happens, it will change the agile you have—which is the point. Is it about your agile, or is it about what the organization can do? Those are two different things.

Give Away Your Position

Eventually, when we go about changing an organization, there will come a time when roles will need to change as well. Period. There’s no avoiding it. Fundamentally, an organization is an amalgamation of people, all serving in different capacities.

Consider your current organization. It’s perfectly optimized to deliver the results you’re currently getting. To change those results, you have to change the organization, which means you have to change the role definitions of the people in the organization. Here are a few considerations.

Changes to the Project Manager Role

Without question, the most common conflict around role definitions in the agile conversation is around the role of the project manager. The traditional understanding of project manager is one who defines and follows heavyweight rigid processes, serves as the center of gravity for all project activity, and guides the execution of work according to a plan that is not permitted to change according to reality.

Around the turn of the century, the rising popularity of the Scrum framework introduced an innovative reconfiguration of the project manager into three distinct roles: a product owner who make business decisions, the project team that makes all the technical decisions, and the funny-named Scrum Master who uses various facilitation and collaboration techniques to help everyone be successful.

The intent was to (1) remove a singular decision maker as a bottleneck and (2) prevent the temptation that position invites for a directive and stifling style of leadership. However, as Scrum grew into the single most practiced agile framework,⁶ the unexpected side effect was to disrupt the entire profession of project management. Today, leaders can hear experts declare offhandedly, “Agility requires using Scrum, which has no project manager, therefore project managers have no place in achieving agility.” Although we can understand the human tendency to focus on superficial details like job titles, the result is the PM role evolved.

In 2015, the Project Management Institute introduced the talent triangle,⁷ which placed a new expectation on project managers: not only are you expected to have knowledge and skill in work management processes, you are now also expected to bring a full tool kit of soft skills and a complete complement of business skills. Put simply, the role had expanded to incorporate those skills that Scrum has popularized. Project managers were now expected to fill a broader and more diversified definition. Rather than serving as process police, project managers were now asked to serve wherever they were needed.

But the changes have not stopped. At the time of this book’s writing, I am also volunteering on the development team for the latest version of the ANSI standard for project management, the PMBOK® Guide—Seventh Edition. This latest edition will be based on new research into a further expansion of the role of project manager, as one that looks beyond the work at hand and considers the context of the work as well.

One thing is sure. Any roles your organization currently has around coordinating work are now under pressure. Achieving agility means being ready to redefine any of those roles.

Changes to the Line Manager Role

In his hilarious memoir The Year Without Pants,⁸ Scott Berkun tells the story of becoming the first manager hired at Wordpress.com, the technology running the vast majority of blogs in the world. As you can imagine, this is a company that was built on innovation and resistant to any of the traps of conventional business as usual. So imagine when a career-long management author and speaker is invited to corral a group of globally distributed hotshot creatives and engineers. It’s the perfect backdrop for a sitcom, but it’s also a platform for deep learning. Some of the gems that I enjoyed in the book include:

• “For all my planning, scheming, and influencing as a team lead, sometimes talent, chaos, and chemistry are all you need for good work.”

• “Organizations become bureaucratic as soon as people define their job around a specific rule, or feature, rather than a goal.”

• “The same ego that drives grand leaders defeats them in the end because they can’t accept the notion that someone will replace them.”

• “The most dangerous tradition we hold about work is that it must be serious and meaningless.”

• “While money provides status, status doesn’t guarantee meaning.”

Those insights are leading to an overarching trend in changes for the corporate manager. Google experimented with removing its managers, and when that turned into a galactic disaster, they brought them back and simply redefined the role.⁹ Accenture and Deloitte have joined several companies in the trend to abolish annual performance appraisals.¹⁰ Today’s workplace is seeing an unprecedented degree of change in what it means to be a supervisor, a boss, or a manager of other people. Examples include:

• Your value is no longer in your expertise. You will be asked to manage people smarter than you.

• You are no longer the single point of contact for your team. You will be asked to encourage more direct staff collaboration across departments.

• You’re no longer the only mentor available to your staff. Your advice will be augmented by various coaches from HR and other departments.

These are not absolutes, but they are very real trends. The specifics impacting your role will vary from one organization to another. The key point is to be willing to bend.

Changes to the Specialist Role

Years ago, a software engineer could get by with a very narrow specialty. “I am a Java developer,” someone could say proudly, boldly, and knowing that would give them a strong career advantage. Today, many specialist roles have expanded into multiskilled disciplines:

• Software engineers. With the advent of Web 2.0 and subsequently the DevOps movement, more and more organizations are looking for the “full stack developer.” In the past, a software engineer could specialize in database technologies versus user interface technologies versus integration technologies. In today’s world, much of the mechanics that we are used to doing by hand are being automated. They create both the opportunity and the expectation for a technologist to diversify beyond a single specialty.

• Social media staffers. When we started posting our ideas online, the only thing you needed to know was how to use a web browser. Today, content creators are expected to have the visual creativity of a photographer, the text scrolling and skimming abilities of a researcher, the performance energy of an actor, and the conversion rates of a salesperson. Today’s social media professional does much more than just type and send.

The bottom line is this: Those who work in the digital space are expected to be more versatile than ever before. Gone are the days when you could say, “That’s not my job.” In today’s fast-paced world, the expectation is that professionals can innovate their skill set just as much as they can innovate the product they’re working on.

Case Study: Reimagining the CEO Seat

The Scrum Alliance is the largest trade association in the world dedicated to organizational agility. In 2017, they were going through a leadership crisis. Board member Lisa Hershman was serving as interim CEO while an executive search committee was looking for her long-term replacement. After looking at several candidates, the conversation turned inward, and the board began asking some deeper questions. According to chairman Eric Engelmann, they started asking, “What if there was another way to think about this position? What if the job actually required more than one person? And what if that structure could look more like the [distributed leadership model in the] Scrum teams we’re helping so many other companies and organizations build?”¹¹

In September 2018, Howard Sublett was announced as the Chief Product Owner, focusing externally on the strategic vision for the organization. A few months later, Melissa Boggs was introduced as Chief Scrum Master, who serves internally on organizational growth and culture and fosters their ongoing transformation. Engelmann explains the theory, saying, “Together they fulfill the primary executive role in the organization. This approach was intended to help Scrum Alliance live the Scrum values deeply, even through our organizational design.”

But that was just a beginning. Together Sublett and Boggs have been publicly sharing their challenges, insights, and experiments on a dedicated blog.¹² Recent milestones include:

• Team Swarm Days, in which teams spend an entire day collaborating on the same goal until it is complete

• Seeking and hiring culture: add talent in one day through an all-day series of designated activities called “Agile Hiring Events”

• Reorganizing into community-centric interdisciplinary teams, each a composite of competencies in IT, Marketing, Education, Support, and Community

By reimagining the senior executive position, the organization’s transformation has hit a new inflection point.

If transformation means the most important role in an organization needs to be reexamined, that means any role might need to change in order to achieve agility. Granted, your mileage will vary. But the truth is pervasive: your role is constraining agility, whether it’s the constraints of the silo you lead or the constraints of your job description.

Summary

In this chapter, we’ve explored the problem of impact. By being the first in the organization to launch forward into agility:

• Understand expectations versus reality. The changes you’ve made may have improved your department’s professional excellence and discipline, but your localized improvements may not be having any impact on the bottom line yet.

• Give away your agility, so it can grow beyond your own physical limitations.

• Give away your position, so you can have more influence than ever before.

Is it about agility, or is it about your agility? Wrestling through that tension will allow you to find the untapped agility lying dormant in your organization.