Three Keys to Being Responsive and Adaptive

August 7, 2013

A key benefit of being agile is the ability to adapt to rapidly changing conditions with minimal disruption and effort. As the leading agile framework in use today, Scrum provides the necessary guidance to make this happen from both a product planning and implementation perspective.

However, “It’s in the way that you use it,” as Eric Clapton’s song puts it. To be truly responsive and adaptive we need to make sure that we have all of the enablers in play, leveraging the Scrum framework for what it is: an agile framework.

Enabler #1: The people. There needs to be the willingness to operate in ways that support being productively responsive and adaptive. This is not about speeding up existing approaches or adopting the Scrum framework in ways that keep an organization deeply rooted in what it does today (such as executing Sprints as mini-waterfall projects with functional hand-offs of work).

We need a disciplined approach to responding to change without excess overhead and delay. An agile, Scrum approach requires localized decision-making by the Product Owner and the development team, both of whom have a collective responsibility for producing the best possible outcome for the customer. This allows key decisions to be made in real-time with a discussion without having to document a change and wait for approval.

We must also operate using short delivery cycles, delivering small, well-defined features that allow us to demonstrate working software and adapt by through a series of decisions based on the realities encountered on the ground and continuous customer feedback. Short cycles (Sprints) also allow teams to try new practices and techniques to improve their performance, receiving fast feedback on whether a new technique or practice is actually improving things or not.

Risk will be reduced using this approach because the decisions made will be both small and time-bound to each Sprint. For teams using something like a two-week Sprint, how much trouble can they possibly get into?

Enabler #2: The Product Backlog. The Product Backlog is a fundamental component of the Scrum framework, and it should be DEEP, as in Detailed appropriately, Estimated (using relative sizing), Emergent, and Prioritized (or ordered, as the Scrum Guide now states). The goal is to maximize value delivery while avoid wasting time and effort on defining everything in detail up front.

Generating every detail up front creates excess inventory with a high probability that at least some of that effort will be wasted because we are piling assumptions on top of assumptions. Instead, we want to elaborate requirements on a just-in-time basis, using the most up-to-date information available to make more informed decisions.

A good product backlog supports emergent requirements that surface as we learn by doing along with the ability to adapt to changing business conditions and opportunities by allowing us to quickly and easily re-prioritize our work.

Enabler #3: An adaptive product. Software teams produce software products as a result of their efforts, and the product itself must be capable of being quickly adapted by adding or modifying features. The adaptive state of a product greatly influences how quickly and easily that product can be modified.

To be adaptive, the product must be actively managed to keep technical debt at a minimum. If we don’t keep technical debt under control, features will take longer and longer to implement because the code base is becoming complex and unwieldy, with the likelihood that we will break other things as we adapt the product.

Automated tests play a strong supporting role in product adaptability. While automated tests aren’t part of the final executable product, they provide confirmation that new adaptations haven’t impacted other areas. While writing automated tests typically won’t speed up the delivery of the current feature being added, automated tests provide both confidence and ability to quickly modify and refactor the software product in the future, as we continue to modify the product.

In summary, being responsive and adaptive is a quality of the organization and its people coupled with adaptive state of the product(s) that they work on.