Agile Primer Series

We're going agile!

Have you ever heard this? “We’re going agile!”

Or my personal favorite, “We’re 100% pure agile!”

I can’t tell you (though possibly you already know) how aggravating it is to hear words like this and have them be complete fiction. And yet, software engineering teams the world over are constantly hearing this sort of thing, with the full knowledge that it is not real.

…when it comes to work, people need to be happy to be productive.

Why does it matter what process you embrace?

To understand agile, let alone be it, it is important to first gain some understanding of what building software is all about. Libraries full of books have been written about this subject, so if you’re not versed in the subtleties of producing working software with human beings, now would be a good time to review that topic. But here’s a brief summary:

• Writing mostly working code is easy.
• Writing good code that is maintainable in the long term is staggeringly more difficult.
• Building software that is useful and meets the customer’s need is nearly impossible.

How do we arrive at these conclusions, you ask?

• Human beings can correctly analyze simple problems and find solutions that pass the “eyeball” test. We know this because it is self-evident, this is what society does most of the time.
• Human beings are bad at doing things that require perfection. A rare few people can get fairly good at aspects of it, but very few will get close to mastery of even a few perfection-requiring endeavors. This, too, is self-evident, else we would not celebrate genius and exceptional talent.
• Human beings make assumptions (mostly invalid ones) more often than they get facts straight, and thus assume that their software works, is of a high quality, and will be easy to maintain in the future, all of which are usually false assumptions.
• Human beings don’t agree on anything. Ever.

Notice the pattern in the list above? The fundamental reason creating software is difficult is because of people. Jeff Sutherland, in his book Scrum: The art of doing twice the work in half the time, put it this way:

Whenever people are involved in a complex, creative effort, whether they’re trying to send a rocket to space, build a better light switch, or capture a criminal, traditional management methods simply break apart.

To put it simply, process is about getting people out of their own way, so they can do great things. Any organization or leader that does not understand this will not have (good) people for very long, if they were lucky enough to have them at any point along the way.

So that’s reason #1 for why it matters what process you use. But the other reason is because when it comes to work, people need to be happy to be productive.

Agility vs. Productivity

Many people say “We do agile here” or “We practice agile development”. I’ve never understood why people say things like this. I suppose we’re all guilty of talking out of the wrong end on occasion, it’s not usually intentional. But the idea that you can do agile is fairly well nonsensical.

Agile is not a verb. It’s not something you do. It’s an adjective. It’s something you are. That’s why the agile manifesto is a manifesto. It’s not a set of rules that form a framework, or a process. It’s not a set of dos and donts. It’s a statement of ideals. Something to forever strive to become. Something to aspire to.

Aspiration is motivational. It’s foundationally rooted in the human propensity for hope. Hope is important in all aspects of life, not just religious and spiritual ones. Without hope, we’re lost. We have nothing to keep us going. Nothing to drive us onward. The lack of hope is de-motivational. It’s soul crushing. It’s unsustainable. When hope is lost, so is the will to continue.

Conversely, when people have something to look forward to, something to hope for, they are happy. They strive. They produce. They work. They collaborate. They achieve goals, and set new ones, higher and more ambitious than the last. Happy people are productive people.

Agile is simply one attempt to capture that into a codified list that can be used as a guide on the journey toward an ambitious ideal. When people make progress toward that goal, when they have produced something of value and been given constructive feedback, and possibly excitement and thankfulness, they will want to continue to do it over and over again. After all, isn’t this why we got into software in the first place? To get that feeling of euphoria when we knock someones socks off? Or finish something particularly complex and know that “it is good?”

Engineers and the cycle of disappointment

Engineers, specifically of the software variety, are exceptionally creative and passionate individuals. At least, most of them are. And the ones that aren’t probably don’t deserve the title. This is true of most disciplines, really. Think about it. Those that are the best at something are usually those that care the most about what they are doing.

So when a manager, chief executive, project sponsor, or other person in charge at a company sets the tone of the Engineering organization by aspousing agile, claiming to be it, and generally working everyone into a tizzy about it, and then proceeds to drop the ball and produces no action and provides no support for its actual adoption, this is deeply discouraging and de-motivating. Those in the organization that have truly earned the title Engineer will usually make directed efforts to fix the situation or bring about a reform in the name of what was intended, not what was implemented or put into practice.

Needless to say, this does not usually go well.

This is usually a good first sign that your organization is not agile. Passionate people can spot false truth claims a mile away. Chiefly because they are the first people to latch onto the ideas being proclaimed, and the most let down when they realize they are total malarky. They build up a natural defense to lies and false sentiment, though they never truly let go of the ideals that drive them to achieve those lofty and aspirational goals.

The second sign of an organization that is not agile (but claims to be) is a decline in morale of the people around the first group (the passionate ones). Naturally, most managerial types blame the first group for the second group’s problems. Some even go so far as to say something like “What are you doing to fx it?” This does not help morale. And it’s not really good leadership either. It’s usually a sign that someone is just plain tired of hearing all the complaining.

The third sign that your organization is not agile is a little something we like to call The Mass Exodus. This usually occurs when the death-knoll is ringing loudly. For example, when a new executive or director is brought in to “reform” the department, and it becomes abundantly clear that even the idea of being agile is not important, let alone understood and strived toward. Sometimes it occurs when the organization starts shifting their message, and contradicting the message that was delivered consistently before. For example, “We don’t use agile methods here because the nature of our business doesn’t allow it.”

…like that person who you used to work for who told you what to do regularly, but never once inspired you to do something.

Break the cycle

So how do we break the cycle? There are only two fundamental approaches, and each one only works if you’re attacking the problem from a particular perspective, whether leader or follower. Let’s break it down.

Leaders

These are the folks who are in charge of things. They naturally receive the descriptive title “leader” whether they’ve earned it or not. Leadership is their position. Not necessarily who they are. You know, like that person who you used to work for who told you what to do regularly, but never once inspired you to do something.

If you’re in a leadership position, you have a choice to make. Inspire your organization to become agile, or risk being outpaced by a competitor who has visionary leadership. Here’s the rub though: If you go down the path of inspiring this change in your organization, doing it halfway is not an option. If you do, you will risk losing more than if you decided not to do it at all. But doing this thing all the way will be one of the most difficult things a leader can do.

Why? Because everything will be in your way. You will have to win hearts and minds across the organization, not just in Engineering alone. In fact, to only embrace change and encourage agility in one part of the organization is also a fools errand and will end in utter failure. Sound like a tall order? It is. Good thing you get paid the big bucks. Time to get to work.

In order to actually pull off this type of change, you will have to motivate the troops to inspire a grass-roots movement, and convince the highest levels of management to adopt it organization-wide. You can read about this in The Scrum Field Guide by Mitch Lacey. I highly recommend it, as it’s full of scenarios to help you visualize the challenges you will come across in this journey and has helpful advice for how to overcome them. In Chapter Two, he talks about getting people on board with Scrum, a well known process that helps you become agile:

Getting people to take a chance on a Scrum project requires more than just a “Scrum is Good” campaign. It takes a healthy dose of persuasion, a steady increase in pressure, and a whole lot of patience.

Followers

Ironically, if you’re not in a leadership position and you’re thinking about inspiring or encouraging an organizational change, you’re probably more of a leader than most others in the organization. But that aside, the journey that you will undertake to inspire change from the grass-roots is not an easy one. Again, The Scrum Field Guide has helpful advice on this topic, including a tip to pair up with someone in upper management to get the support you need. You can’t do it alone.

In my next post, we’ll explore the topic of becoming agile from the grass-roots, and drill in on this more fully. And remember, if you’re not in source, InSource!