Day: February 3, 2021

Like any movement that becomes popular, agile has become more buzzword and less meaning than was originally intended.  When 17 software developers met in Utah, they didn’t set out to change the world of software development or change how projects are managed.  They came together to share a common passion for making software development more successful, because the industry had a dismal record of failures – much like change management today.  (See Why the 70% Failure Rate of Change Projects Is Probably Right.)  The heart of a desire for successful projects can be applied to any project – including change projects.

More This, Less That

The Agile Manifesto lays out what the group believed in a set of four principles in the form of conflicts:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

They’re careful to indicate that both are valuable, but the things on the left are more valuable.  Change managers will recognize that all but the second are general statements that apply to change projects as well as software development projects.

Boiling down the statements to an even more basic level, there are two keys to take away.  First, people are important, and they can’t be removed from the process.  Second, we can’t plan for every contingency; we must react to change.

Heuristic, Chaotic, and Wicked

We now live in a world where we’re not following the single formula that leads to the right result.  Instead, we’re working with a set of heuristic processes that lead us to the right location.  Richard Florida called for The Rise of the Creative Class back in 2001 when he recognized the work that was being done was not following a single process.  Before that, in 1970, Alvin Toffler wrote the book, Future Shock, where he coined the term “future shock” to mean a degree of change that people couldn’t cope with.  About the same time, Horst Riddle and his colleagues started speaking and writing about wicked problems and the nature of unsolvable problems.  (See Wicked Problems for more.)

By all accounts, we’ve entered a world where we simply cannot expect that we can plan for all the situations we find ourselves in.  Instead of rigid planning, we find the need to have more agility and resilience in our planning progress, and that means continuously readjusting the course of our projects.

Iterative

While the original “waterfall” software development lifecycle was designed to be iterative, few people did it that way.  They instead tried to plan everything and get the whole software developed in one project cycle.  Agile turned this on its head by removing the big, upfront planning cycle and instead replacing it with a vision of the end target and enough planning to take the initial steps towards that goal.  After each cycle, a review is preformed to capture learning and readjust the trajectory so that the end target stays in focus.

In an iterative model, the goal is to deliver as much to the organization as quickly as possible.  It has developers working on the things that add the most value to the organization first, so even if the project is cancelled early, there’s a working solution that delivers value.

Applying Agile Methods to Change

Agile can be directly applied to change projects by simply mapping out the end target and then only enough of how to get there that can be accomplished in a few weeks.  At the end of that time, the process comes together to evaluate what was learned and what the next steps might be.

Criticisms

Agile isn’t without critics.  They claim that the process is more wasteful than a waterfall project, citing the countless missteps that happen in the process.  These criticisms are true – but they’re weighed against the additional planning work that may or may not have identified the problem and all the downstream effects.  The net-net for most organizations is that agile approaches to software development – or change – mitigate their risk and don’t cost substantially more than a traditional project management approach.  Most organizations decide that the additional risk reduction is worth the cost.