Plan vs. Change in an Agile Environment

As a venture capital fund providing growth equity to software companies, we want all our portfolio companies to scale rapidly while responding to changes in the market. In short, we want our companies to be Agile, and we want to be Agile in helping our companies.

Therefore, one of the key goals of our business development services is to help each and every portfolio company become Agile in its product development processes.

So, what does that mean? What are the challenges we and our companies encounter while trying to become Agile? And what are some misinterpretations of what it means to be Agile?

In this post, I will attempt to address one misinterpretation of the meaning of Agile and the challenges it causes. It has to do with the tension between following a plan and reacting to change, and how this tension can be healthy versus how it can lead a product team down a black hole.

First, to get a general overview of the term Agile, let’s check out the Agile Manifesto. A few yeas ago, a bunch of very bright leaders of the Agile community got together and tried to define what it means for software development companies to be Agile. They had a tough time finding things they could all agree on, but they were able to reach a consensus on this:
http://agilemanifesto.org/, supported by this: http://agilemanifesto.org/principles.html

Reading through the 4 values and the 12 principles, it is easy to see how some managers take away the mindset that change is always good, in an Agile world, planning is less important, and we should be reactive on a regular basis (the implication is that we’re less pro active). Taken to the extreme, not only is it OKAY that we’re making 90 degree turns every several weeks, but it’s actually GOOD, because it means we’re Agile, and that’s what Agile companies do! Furthermore, because I have working software at the end of every sprint that I can release, I can keep changing but always have finished product.

Wrong.

In practice, unless you’re in a highly competitive market that changes at a ridiculous rate (not typical in our venture capital investment portfolio), or you’re going through an early innovation/exploration product development phase, taking the above approach over a prolonged period of time is likely to cause the following:

• You have trouble getting complete products that solve robust problems out the door, releasing incremental products that partially solve problems and never quite nail anything. Sure, you have working, releasable product, but it tends to take more than a sprint to build a product that can really win a customer segment.
• You are a follower in the market, not a leader.
• If your changes are so radically that you’re changing focus on different customer segments or market problems, then you never get anything done.

And it is indicative not of your being Agile, but of you having a poor planning approach that’s not robust.

Yes, Agile says you need to be flexible, and react to changes or new information or new ideas, at any point in the product development process. You need to meet customers’ needs, and those change, or you learn new things about them. The competition’s offerings change and you may have to react. And sometimes, you realize that after building a fraction of the planned functionality, it turns out you’ve delivered all the value the customers need.

But that’s just one component of it. The reason Agile is so hard is because it is not one idea, not one concept.

Rather, being Agile is like playing in a large symphony orchestra, playing a very complex music piece. Focusing on just one or two aspects of the overall concept of Agility does not work. In fact, if you focus on certain parts and not others, you may end up being worse off than you were on waterfall.

Let’s go back to the Agile Manifesto (http://agilemanifesto.org/) It’s all about tension and balance between opposing values.

The value that relates to this post is: 
“Responding to change over following a plan “

There’s a sentence written at the end of the 4 values. Many people trying to become Agile neglect it: 
“That is, while there is value in the items on the right, we value the items on the left more.”

A good plan is valuable.

In practice, to me this means that Agile doesn’t say: “Don’t plan, just react and change your direction as much as you want to as often as you want to.”

Instead, it says:”Plan well, and execute against that plan, but don’t follow the plan just to follow the plan. Value to the customer comes first. So continue to re-evaluate, and change the plan if it makes sense. Don’t shy way from change.”

Furthermore, I’ve found that in practice, small changes to the plan are typically unavoidable, even when you have a good planning approach.

Radical changes once in a while may be necessary.

Radical changes every sprint over a prolonged period of time (i.e. not just in an early period of rapid innovation and exploration) not only wear down your team, but they’re liable to prevent the product from becoming great at solving any one problem set for a given customer segment.

In most cases, you want something like the following:

• You have a robust, deliberative customer interaction and research-driven planning process, that gives you a roadmap and release plan
• Every sprint, your team delivers working software that can be released to customers, and that allows either incremental iteration in the next sprint, or a radical change IF necessary
• Minor changes are made to the requirements as necessary from sprint to sprint
• Most of the time, the only significant changes that happen are those made in a quarterly or annual planning process
• Once in a while, a significant change is made intra-planning due to a change in the market, new data, or new insight. 

This idea of tension and balance applies to all the Agile values, and in implementing Agile, it is important to think of it as a holistic multi-component symphony, rather than a simple tool or approach.