Responding to Change Is Too Much Work
Responding to Change Is Too Much Work
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
The fourth tenet of the Agile Manifesto is a difficult one.
Why is that so difficult? What's the point of responding to change? Why is that point even in the manifesto? Because we're all lazy.
It's human nature to take the easy way out of any situation, and following a plan feels easier than adjusting. When we have a plan, we have the illusion of control. The illusion of mastery. The illusion that we know what's going on. Sadly, this is rarely the case.
Technical work is difficult to understand. Nearly all of the vital work takes place inside our heads, and the output of this work, code, is requires a high level of expertise to understand. The final result, a running piece of software can have multiple levels, components, layers, and servers. Good software can be stunningly difficult to understand. Bad software is often incomprehensible.
Then add in a manager or executive with a nontechnical background and ask them to manage this work and the people doing the work. What's a typical development manager to do? They're responsible for our work, but they can't wrap their heads around what we do. Far too often they fall back to something they understand. They reach out and look for anything they can grab onto and use to manage the work.
So this manager lays out plans. The plans are often very detailed. And then they try to drive these plans into reality by "managing" the teams into compliance because it seems like the easiest way to move forward. The result? Extreme frustration when the plans don't work.
The truth is that software is complicated and not easy. Under the best of circumstances, it requires a well oiled team, time to concentrate, and an understanding of the problem. Under more typical circumstance people are involved who have petty jealously, political ambitions, suspicions, and more baggage than we can imagine. It involves much less time than is needed to do the job properly. And the requirements are usually muddy and poorly understood.
So what's a manager to do? The easy response is to get angry and loud. Demand more hours from the team. Ask for overtime and weekends. Add new hires to the equation.
The easy answer sometimes works, but it usually fails. Even when it does work, it's usually a short term fix. So what's the hard answer? It's adjusting.
There are many facets to this equation. One is the triangle of software... every product has time, quality, and features. When time can't slide (for whatever reason), then trim out features. If features can't change, then move the deadline. (Don't slide the quality! Please!)
It's much more work, and it requires difficult conversations, to adjust, but that's why it's in the manifesto. If you really want to craft great software, make your plans. Map out your strategies. But never, ever, think they're right, perfect, or lasting. If you're not willing to adjust, you're very likely going to fail. And that's really difficult!
Plans are worthless. Planning is essential.
-Dwight D. Eisenhower, general and president
Note: This is the fourth part in a series of commentary on the Agile Manifesto
- What's Agile? Individuals and Interactions or Processes or Tools?
- What's Agile? Working Software or Great Docs?
- Customer Collaboration Over Contract Negotiation? Huh??
Opinions expressed by DZone contributors are their own.