What It Means to Be Adaptable

September 11, 2013

“Responding to change over following a plan” is one of the four values of the Agile Manifesto. Is your first reaction to think about changing requirements? This is often the general perception of what adapting means in an agile context, particularly when we refer to one of the principles of the Agile Manifesto:
“Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage”
We do need some flexibility in our thinking and approach so that we can adapt to new or changing business requirements. We can’t have the mindset that everything is cast in stone and unchanging because software development is a product development exercise where learning and discovery will take place.

We have to expect change, even if it is the old, “Now that I see it” phrase from those on the business side. The ideal approach is one where our process is designed to keep our costs of supporting change as low as possible.

This is why agile elaborates the details of requirements on a just-in-time basis and spreads planning throughout the development effort. It is a much more expensive proposition to detail everything up front and plan around those details because there are assumptions built in that are likely to change as we get involved with the actual work.

And because we will learn things as we go about what we are building and how we need to build it, we need to adapt to changing conditions as we encounter them, incorporating learning to improve our overall results. Being adaptable is about giving ourselves options:

Option 1: We can incorporate what we have learned into future work, potentially re-prioritizing work based on this new information.

Option 2: We can drop work from the Sprint/iteration or release if one or more features proves to be larger to build than anticipated. One variant to this is that we can temporarily defer on implementation of a feature while we conduct some research to determine if we can deliver that feature in a different way.

Regardless, we need to make decisions as rapidly as possible, with the people closest to the work empowered and accountable for those decisions. That is what a framework like Scrum is all about. Localizing decisions and keeping the risk small by making small decisions in short time frames, with the ability for stakeholders to inspect and adapt based on a Sprint review.

These first two “agile adaptability” perspectives are from a process perspective:
  • Adapting to changing business conditions and requirements.
  • Adapting to circumstances encountered as requirements are being transformed into working software.
But we have two more!

Agility “…is a quality of the organization and its people to be adaptive, responsive, continually learning and evolving.” – Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum by Craig Larman and Bas Vodde

This speaks to the willingness and ability to work in new ways that keep the cost of change low. An approach that embraces experimenting and reflection to discover and learn about what is being built and how to build it better.

And finally, adaptability is a quality of the product(s) being worked on. Good design – maintained through a practice of continual refactoring – is essential. If the code base becomes unwieldy, features will take progressively longer to implement because it has become increasingly complex – or less adaptable.

So, when we look at adaptability, we have four areas to consider:
  • Adapting to changing business conditions and requirements.
  • Adapting to circumstances encountered as requirements are being transformed into working software.
  • The willingness and ability of the people and the organization to quickly adapt to change, with the least amount of overhead and cost possible.
  • The adaptive state of the product(s).