Harnessing vs. Resisting Change

Agile Principle #2: 

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”  

OK, yes, everyone talks about harnessing change. There is even a book on Amazon with the title, and it’s just one of hundreds of books about change and change management. But talking is one thing, and doing is another. Do today’s modern organizations really do it? Do they harness change in a way that delivers competitive advantage to their clients and customers?  

Our answer is “No, probably not.” But we also recognize that most other people’s answer is “Um, what exactly do you mean by ‘harness change’ here?” And that’s a perfectly appropriate question—one worth answering, as it is at the heart of one of the core principles of Agile. 

Traditional Businesses Were Built to Resist, or At Least Tame, Change 

The kind of management practices we see in wide use today are not cast in stone. They grew up during the industrial revolution as a response to inefficiency and growing labor pools (check out our article, Is Management Just a Relic of the Past?). And while there is a lot of good that came from those practices, it is not the “end all and be all” when it comes to management.  

Specifically, there are some practices that have evolved to rein in anything that has the faintest whiff of unpredictability or change:  

Extended discovery processes. Companies will have multiple meetings and deploy a number of tools to try to understand everything they can about a client and their situation as a means to avoid failure. Traditionally, not a single bit of work is done until discovery has finished, which can delay time-to-market. 

Lengthy written contracts. Companies will try to anticipate all contingencies and get the customer to sign on the dotted line as a way of protecting the sale. Chances are that the only people who read the contracts thoroughly are the people writing them.  

Scope documents. Part of those lengthy written contracts are specific details about what is going to get done, and what is not. When changing market requirements or further learning make it clear that something else is needed, “scope creep” happens, and it triggers either another round of discussion or additional unanticipated charges to the client.  

Change Orders. Additional work is requested and recorded through change orders. These accumulate as a project moves through time. Customers try to minimize change orders, while developers use them as a way to justify the time they spend on a project. Management is caught in the middle of this tug-of-war. 

These practices are an inherent part of the way most companies do business because today’s businesses are themselves built to resist, or at least tame, change. 

But if change is supposed to drive innovation and bring competitive advantage, these practices are actually getting in the way. 

The Downside of Classic “Change Management” 

Are the practices above in any way outdated, cumbersome, or otherwise bad? That’s a question that each organization has to ask itself. But note what these practices require: 

• Large amounts of time (and human capital) spent in non-value-adding activities: discovery, estimation, and document preparation 
• Extensive company history and/or tribal knowledge to anticipate all contingencies 
• A fair amount of client education 
• A firm understanding of project requirements available up-front 
• Unbelievably stable market conditions (i.e., competitors are not changing or releasing new products, customer demand does not change or waiver, etc.) 

It’s worthwhile asking of your company: Is the safeguarding of our workflow and project parameters worth all the human capital and client education required from the start? Do our teams really have the ability to anticipate every contingency? (What if something comes up that was not present in discovery?) Does the client have a firm understanding of what they want and why? Is their market really so stable that all of this makes sense? 

My guess is that, if companies really did this kind of soul-searching, they’d realize that these practices aren’t doing it for them. Which only raises the questions: “What now? How can a company both satisfy the need to change and protect itself?” 

What Change Looks Like in Agile 

Let’s start by looking at a different way of doing things—let’s look at a company that doesn’t just tolerate changing requirements but embraces them, even late in the game. What would that organization look like? 

• There would be a huge difference in how projects are conceived. Teams would be fully invested in the idea of “Build Small, Deploy Fast, Learn Quickly.” 
• There would be fewer presentations and more “test drives.” 
• There would be much less red tape involved in requesting, accepting, and finalizing changes. 
• Instead of formalities…collaboration, communication, and common sense would be used to assess changes and determine their impact on product functionality, cost, team resources, and risk. 
• Budgets would not be tied to project completions, but to development capacity of a product. ROI would be achieved through faster time-to-market, higher-quality products, and higher customer satisfaction.

I will be the first to admit: It takes discipline to apply this Agile principle in any sort of sustained, meaningful way. Too often, the whole idea of change (and “harnessing change”) gets diluted to the point where it is either toothless, or it actually does damage to teams and deliverables. No one wants that, right?  

So, to be clear, embracing changing requirements is not:  

• Changing routines or practices for the sake of change 
• Adding every new or novel feature someone can think of 
• Delaying product release until it makes everyone happy 
• Creating an ever-expanding list of change orders 
• “Gold-plating” working products (i.e., adding unnecessary features to hike the price) 
• Reading five books on change management and feeling accomplished 
• Permission to be indecisive 

Harnessing Change 

OK, so you’ve accepted the above principle. You’re ready to start restructuring teams and workflows to accept and embrace changing requirements. What’s the end game? How do you go about the whole “harnessing the change for the customer’s competitive advantage” thing?  

The end of “scope creep.” The concept of scope creep is that the feature set is established at the beginning of a project, and new features and enhancements “creep” in as the project progresses. It’s almost always used with negative connotation. But if we’re truly harnessing and welcoming change, isn’t scope creep a good thing? And if we’re delivering working features continuously on a short time horizon, is there even such a thing? Keep an ear out for usage of the term; you’ll usually find it in areas where change is being resisted.  

Enhanced stakeholder control. Stakeholders—specifically, external and internal project owners—have more control over the evolution of the product. This means fewer blind alleys and the elimination of those ever-expanding change-order lists. It also means better control of the budget: Clients can accept the product as-is after any sprint, knowing they’ve paid a fixed rate for developer time, and companies can rest assured that they are getting an ROI from their team members. All of this is not only psychologically satisfying; it means a healthier, more predictable business, as well.  

More frequent and more successful innovation of products. Agile teams have room to innovate. Teams can pivot on requirements as needed, and so there is room for trying out new features and approaches. Customer feedback is regular enough to help guide this process. Give your teams permission to try new things and encourage their creativity—but also make sure they understand that the customer’s feedback is the ultimate guardrail.  

Sensitivity to market conditions. The failures of many big businesses are almost legendary: Kodak failed to see the rise of digital photography; Blockbuster did not invest in streaming technology until it was too late; Borders flailed about not knowing how to compete with an upstart Amazon. Imagine how different these stories would be if these companies had kept their ears to the ground and modified their offerings in light of what they were hearing. We might still be seeing Kodak cameras today, and they would look very different from the cameras of past generations. So, make sure that your team and your client have their ear to the market, and be ready to change things up if sentiment changes, the competition springs a surprise, or a new opportunity arises.  

So here are my two questions for readers: What are some other ways to “harness change” that go beyond mere lip service? And what is more costly for your organization: Rolling with changes, or trying in vain to manage them from the beginning?