Over a million developers have joined DZone.

Responding to Change Is Too Much Work

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

The fourth tenet of the Agile Manifesto is a difficult one.

Responding to change over following a plan

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


 

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

Topics:

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}