Agile Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

Responding to Change Is Too Much Work

07.21.2010
| 4643 views |
  • submit to reddit

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


 

Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)