#51-Responding to Change

The fourth point of the Agile Manifesto, that we value responding to change over following a plan, has massive implications for the way agile teams are managed.  This podcast will introduce the issues that result, and will lead to the next series.

Transcript

Responding to change.

Recently I completed a series of podcasts on the four points of the Agile Manifesto. If you missed those episodes, they are in the backlog. I ended that series with a set of recommendations about how to respond to the implications of the manifesto, but when it came to the fourth point which is to value the team's ability to respond to change over strictly adhering to a plan, I pointed out that this is where the agile notion of “embracing change” comes from.

But I also acknowledged that traditional technical practices tend to be change-averse, and that something must be done about this if we expect to truly embrace it.

My next series of four podcasts will be focused on this issue. It is largely a matter of technical expertise, and I know that most of those who listen to this podcast are neither developers nor testers. However, I think it's important for someone who is leading a team and managing their time to at least understand what the team should be doing from an executive point of view. This will enable you to make recommendations, evaluate progress, remediate missing skills, and measure the team's effectiveness correctly.

If you ask the average developer whether they would prefer to work on a brand new product, or to enhance, debug, tune, or otherwise maintain a legacy system, virtually every one of them will say they would prefer to build something new. The reason for this comes from their experience, that changing older, existing systems is fraught with peril. It's an opportunity to fail, and to potentially damage one's reputation and career.

But in an agile environment we not only have to embrace change, we have to acknowledge that we will be causing change to happen more frequently than we ever would have in older methodologies.  It is a hidden cost to agile processes that a lot of people miss and which can derail the effort entirely.   I did a live webinar on this which was recorded, and I will post a link to that recording in the transcript of this podcast. If you seek to be an agile project manager and have not watched this recording, I strong recommend that you do.

What do we do about change? This is not a new problem obviously, we have always had to deal with change in some way, and I'm old enough that I was around when a number of things were tried.

For example, some people believed that if you designed a framework or ecosystem with enough flexibility, then whatever changes come along you would be able to deal with them effectively. The problem with this is that it tends to lead to highly complex systems which are difficult to understand, time-consuming to implement, challenging to test, and hard to maintain. Also, change is  unpredictable, and is becoming more so as the world is moving faster and faster. So you cannot really design a framework with enough flexibility to be able to deal with any potential change. If you try to do so, you will almost certainly over-design the system, which creates waste.

Recognizing this, some organizations, notably the military, for a while decided that if change was a negative force, and if we cannot effectively design for it, then we should prevent it entirely. Such organizations usually adopted a strict policies that once the development team had begun to implement the proposed product, that they could not be interrupted with new requirements or re-prioritization. But this has two very negative implications:

First if the team cannot respond to the changing world around them, then the products that they produce will likely not be relevant by the time they're finished. This produced a large number of beautifully designed, high-quality products that nobody used because they were no longer relevant once they were completed. The pentagon has an entire warehouse of automation products that were never installed because of this.

The second problem is that some of the changes we would like the team to be able to make are actually positive things that come from innovation, new ideas, technological breakthroughs, all of which are also unpredictable. We'd like the team to be able to benefit from these things, but they cannot if we say that change is against the rules.

So, if you cannot design for all possible changes, and if you cannot prevent change from happening, then what do we do about it?

This conundrum has been a focus of mine for the last 20 years of my life. It is one reason I got into training in the first place. The short answer is this: we must change change itself. Or maybe more to the point we must fundamentally change our relationship to change in the way we manage products and lead teams..

How can we do this? That's going to be the focus of the next four podcasts.

URL of the recorded webinar:

https://www.projectmanagement.com/videos/843612/enabling-agility--addressing-the-hidden-costs-that-exist-in-every-agile-project