The Ultimate Expression of Adaptability

June 26, 2013

My recent Timeless Agility post prompted my friends at Ephlux to reach out to last week to explore the post in greater detail on a recorded Google Hangout session. I talked with Regional Director Martin Harvey for a little over twenty minutes, expanding on some material and answering questions that my post prompted.

Martin asked a really great question on why the rest an organization needs to understand agile, above and beyond the fact that stakeholders could see working software much more often. My response was that seeing working software being delivered on a regular, incremental basis was the easy change when it comes to adopting agile.

You can view my entire conversation with Martin below:

Or click here to view it on the Ephlux website.

If you viewed the conversation, you noted that my response also talked about how things like elaborating requirements on a just-in-time basis and progressive, adaptive planning with agile can create conflicting expectations within an organization. To organizations with a long-standing use of traditional, plan-driven approaches, the lack of detailed specifications that are signed off up front along with an accompanying detailed project plan doesn’t qualify as planning. This is a major organizational mind shift that needs to occur.

As an industry, we’ve proven that software plans are notorious for being wrong, particularly those initial plans. But we persist at thinking that “If we only…”

“…work harder at nailing those requirements, invest more time up front with experienced developers to get realistic estimates, be more rigorous at identifying dependencies and managing risk and change, etc. – then we’ll be successful.” Except that things rarely work out that way. Traditional planning approaches tend to fail miserably at scheduling software development because we’re contending with complex knowledge work.

It’s not that software development is unmanageable; it’s that we need to manage it differently. We are wasting effort attempting to organize knowledge work like a manual production line, imposing great deal of structure and limiting the amount of decision-making. And once we do, we constrain our options and impact what is usually near and dear to everyone: predictability.

We plan for certain features to be delivered, in certain ways, within an estimated amount of time. What happens when we discover that work is going to take longer than expected? I’m sure that you can think of a variety of responses, such as reexamining the requirements to make sure that we aren’t adding little “extras” here and there or misconstruing estimates as commitments and demanding overtime to “get back on track.”

The main point is that by the time that we have a detailed project plan, we – organizationally speaking – have become vested because we’ve invested a lot of energy into creating that plan. Our focus becomes one of conforming to the plan, at the expense of examining other options.

In my experience with traditional planning, I never witnessed a feature get smaller. Not unless the schedule was challenged in some way and we had to have some difficult conversations with the customer so that we could pare down remaining work to pull in the schedule. But I have seen it happen with agile development.

This is because agile development wants a genuine partnership with the business. The development team works with the customer (or proxy, such as a Product Owner) to create the solution as opposed to being implementers of locked-down functionality. I’ve seen features get smaller and simpler much, much more often with agile development than I ever did using traditional approaches. And this has a huge impact on schedule predictability.

Traditional approaches typically keeps us focused on implementing features in pre-determined ways, conforming to spec unless the customer decides that they need more. And more translates to more time, with approvals for scope changes and re-calibrating the plan before we begin to make those changes.

I’ve worked with teams that have been able to design simple, yet effective solutions because the development team was equipped with a greater understanding of the desired benefit that the customer wanted, courtesy of the User Story format (AS A [type of user] I NEED (OR WANT) TO [perform some task] SO THAT [benefit]) that outlines what a user wants to do along with the anticipated benefit of performing that task.

But the real advantage is derived from the conversation between the customer and the development team. The conversation not only yields a much deeper understanding among the development team about the customer’s needs, a huge gain comes from the ability for the team and the customer to discuss options and tradeoffs about a proposed solution.

When we do this, we aren’t just “Responding to change over following a plan” as one of the values of the Agile Manifesto states. First, we avoid putting ourselves through a cycle of building to spec and then making a change. Instead, we discuss a lightweight User Story, collaborating with the customer to design the solution, leveraging all of the information and understanding generated from the work performed up to that point in time. In effect, we are responding to change in real-time.

A traditional approach to software development eliminates key conversations – and the timing of those conversations – that are critical.

Being adaptable in an agile sense is not just about accommodating change. Sure, we need to be able to adapt rapidly, with as little overhead as possible. However, the ultimate expression of adaptability is the ability to adapt in the moment, as we are working with the customer. And this is enabled through real-time decision-making.

We can’t make this happen with structures and processes designed to limit decision-making. We need simpler structures designed for autonomous teams to make decisions for themselves. Granted, boundaries and constraints need to exist, but these can be established intrinsically by defining small features that are delivered in small increments; these smaller, quicker deliveries translate to smaller decisions each sprint or iteration, which also reduces risk.

If we leverage adaptability correctly, we can achieve two important goals:
  1. Adapting the features to better meet the customer’s needs.
  2. Adapting the implementation to achieve greater predictability.
The key is to enable decision-making by localizing as many decisions as possible to the people performing the work. This approach is really not all that new; it’s the preferred way to manage knowledge work and knowledge workers.

As my conversation with Martin suggests, there still will be times when a customer utters the phrase, “Now that I see it…”, but these frequent conversations that agile development utilizes will reduce the amount we will hear it. And even when we do, the smaller, frequent deliveries aid in reducing the amount we need to change after the fact, plus agile planning provides us with a way of accommodating change that is managed efficiently and effectively, using a minimal amount of overhead.