Agile - Responding to Change

Agile – Responding to Change

This is part 4 of 4 of my continuing series that looks at each of the high-level principles from the Agile Manifesto, today we tackle the concept of responding to change over following a plan. My position on this may be a bit outside the purist agile teachings. I like plans and predictability and I don’t think they are necessarily in conflict with agile software development or organizational agility.  Keep reading and I’ll explain why I say this.

I’ll use video game development as an example of why planning and plans can be important.

If you want to launch a game and generate significant revenue and profit you cannot do so without a great game but you also need considerable business savvy, excellent timing, great marketing, and a bit of luck.  You need to plan, execute against that plan, and adjust to shifting market factors and consumer sentiment during development.  That’s right. You have to “respond to change”.

See how I did that?  I took business planning, which might seem to be the polar opposite to agile development and connected it back to the principles from the Agile Manifesto.  The trick is to do enough planning to make sure people are working on the right activities in the right timing and sequence. At the same time, we need to be constantly reviewing our assumptions, testing our theories, listening to stakeholder feedback, and be willing to change the plan when new information reveals that a new direction or strategy is needed.

That said, don’t give up the dream. If you have built your team, and your plan, around a grand vision for something huge and world changing, do everything you can to protect that goal. You may have to take a different path to get there than the path you initially started with but keep the dream alive.  I’ve seen great game concepts get so watered down in compromises during development, often caused by trying to stick to the business or marketing plan, that the game released was nothing close to the vision that all involved were so excited about in the beginning.  That is what can happen when you choose to follow the plan rather than responding to change. 

Now I want to also talk a bit about predictability.  Deciding to build a product requires an investment.  Business leaders don’t like to make investments without some predictable profit (return on investment – ROI). Predictability is about our ability to predict something in the future – a product launch that results in some tangible value returned to the business.

We make predictions all the time. We predict the weather and make decisions about whether to where a jacket or take an umbrella when we go out.  Our confidence in the weather forecast for today is directly proportional to our confidence in the measures and interpretations of those measures that the local meteorologist has made.  We may even look at a 5 or 10-day forecast and make some decisions about activities we want to plan on the coming weekend. Failing to respond to change would be not checking the daily forecast as that outdoor activity gets closer and adjusting the plan if the weather forecast has changed.

So, we want predictability for our long-term weather forecasts but we know we have to monitor and adjust. There are too many variables for forecasts beyond a day or two to be reliable. Long-term business or project planning faces the same challenges.  We want to be able to predict the future, but when we are honest with ourselves, we know that things change so fast that we must constantly be vigilant and check to see what has changed. Like the meteorologists, we must have metrics.  We must understand our customers, the market, the product we are developing, the health and productivity of the team, our operational capacity to launch and support our products, and the financial health of our business.  All of these measures help drive confidence in our predictions for what will happen next week, or next month, or next quarter.  The further out we look, the less confident we are in our ability to predict with any real accuracy what will happen.  That is why we should respond to change and not just follow the plan.

In conclusion, we’ve now covered all 4 of the principles from the Agile Manifesto.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

We’ve set the stage for more articles to talk about how we put these principles into action. In future articles, I will cover topics around Scrum, Lean, Kanban, XP, DevOps, Metrics…  Stay tuned and please share or comment.  Feedback is appreciated.