3 Ways We Can Revive Agile

We recently started talking about Taking Agile Back.

I was surprised to hear how much response came from this. Now we have a community on google and presence on linked in and yahoo groups and twitter. People are coming from the woodwork to say that they're also sad about the state of agile practice and they either yearn to return to agile values, or they lament that they never were able to enjoy really practicing those values.

But what do we do?

I think that there are at least three immediate steps we can take.

1. Remove barnacles
2. Reinstate values
3. Move forward

Remove Barnacles

The first is a tad negative. We should call out the things that have grown on the skin of agile (shallow, peripheral issues) and have obscured the heart of the principles. 

I've already addressed some of the noise that has grown up around velocity and estimation. I've been suppressing a number of opinions on metrics and disengagement. 

You can love or hate Linked-In, but I have found kindred souls there, teaching and answering questions and calling out practices that divert from the real goals of creating a human system that actually produces all the time. I think it's always good to have some time spend in dialog on the forums there.

There are google groups and yahoo groups where people ask good, honest questions, but they're often the wrong questions. It would be good to have people there to help scrape the barnacles from their view of the agile world.

You don't have to publish in magazines or blogs or even twitter. Scrape the barnacles where you live, where your teams are producing software today. 

While we have issues with some distracting practices, please be aware that taking back agile is the work of many people. If you make us seem to be all anti-whatever, then we'll always be fighting to beat the image of being a bunch of haters trying to return to the past. More on this later.

Reinstate Values

This is the good stuff. 

The first step to building the values is to live them intentionally. If you need reminders, visit the agile manifesto site and put a printout of the principles up on your own wall. Focus on being the most heartfully-agile person in your space. 

Then take to the streets. You probably have a blog or a twitter account. You probably go to user groups or company lunch-and-learn meetings. You could probably start some of these if you don't have them.

We need stories of how living these values changed our work, after all "working software is the primary measure of progress.".  Other benefits are important, but the overwhelming pragmatism of the agile approaches should get more play. Remember that XP was built on two questions:

• What has worked really well in the past?
• How can we do these things much more intensely?

As much as agile work has helped humanize the workplace, the practical advantages have always been the entree.

One warning, though; don't try hard to seem an expert. Instead, be very transparent and open-hearted about your goal of becoming more expert all the time. Always be in transition, and never even pretend to have fully arrived. The humility of a seeker will win you much more mindshare than the appearance of authority.

In this light, I'm planning to put together a positive blog this week describing how I have seen the agile methods pick up on rather old and new ideas and create greater project safety. I believe that agile methods are safer for developers, managers, customers, and all members of a product community. I'll tell why.

Move Forward

I don't want to return to the technology of the 1990s or the 2000s. 

I don't want to be answering questions that people are not asking anymore. 

In the time between the manifesto and now, the world of technology has changed. We need to carry our values into the future and even modify them if we find them dated or unhelpful. 

Now we have influences from Lean Startup, cloud computing, mobile development, social computing, mob programming, etc. 

If we aren't moving forward, we become irrelevant. I believe that these values are timeless, in which case they work just as well in 2020 and 2030 as they did in 2010.

Now we have something called Modern Agile which is free from barnacles, entirely built to promote four simple principles, and is moving forward. We finally have the forward-step I was hoping to see in 2014.

I Want Agile Back

Note: this was originally all plain text and a little shorter. 

As more people have joined the conversation, and other supportive materials have come to mind, it is growing links and a little verbiage but this is only to support the idea: we don't have to settle for expediently cranking out horrible work between pointless meetings. We can do better. 

Are we getting tired of the kind of "agile" where you don't really have any particular technical practices, change (and improvement) is entirely optional, and you pretty much do waterfall with additional overhead of meetings?

Are we tired of seeing "sprints" and "iterations" used as ways to pressure people into working harder and longer ("pushing velocity"), with no training or learning or even autonomy? Are n-week death marches the ultimate expression of our values?

Are we tired of the kind of "agile" that's all about buzzword compliance and rituals and motivational posters? Aren't we in the industry tired of being shamed by people who think that this weak, soul-less form of agile is what we wanted? 

I know we can do better.

We've done better. We can go further.

I want my "agile" back.

You?

UPDATE: 

I think that I've gone as far as I want to go with this. I've had discussions with good people like George Dinwiddie and Joshua Kerievsky, and I think there are ways to go about this that don't verge on "recreational anger" or "habitual anger" or "victim blaming" and have realized that there is a much higher road to take here.

For progress on the higher road, follow the movement around Modern Agile. This is not a company trademark or a reinvention, just a refocusing on the core values that (IMHO) made Agile great to begin with -- at least in the places where it has been great. 

 

David Gray on Russ Ackoff

David Gray wrote a great article in a funny place, as a comment to a really great YouTube video.  

I took it upon myself to reproduce it here because you need to read it and I do too.

Dividing work.

Division of labor, as Adam Smith pointed out in the 1700s, has the potential to increase productivity. But division of labor also leads to interdependency: every worker relies more heavily on others to do her job, and as the number of handoffs increases, so does the potential for dropped balls. As the number of divisions grows, so grows the interdependence.  

This interdependence creates a need to synchronize and coordinate the work.
Traditionally this has been the job of management and bureaucracy. We coordinate the work through measurement and control.  

As you increase the number of divisions, you also increase complexity. One of the goals of these divided and interdependent systems is making work more efficient and systems more consistent, predictable and reliable. The goal in many cases has been a perfect system; a system that’s idiot-proof. If something can be automated, you automate it. If you can’t automate it, you constrain it to the minimum possible variation. 

Of course, the more idiot-proof the system, the more you will constrain behavior, forcing people in many cases to act like idiots, against their better judgment. Even when people know there’s a better way to do something, they will often be constrained by policies and procedures that were designed to reduce variety in the system. If your system needs to solve problems that you can’t anticipate, then you have a problem, because automated systems and idiots can’t solve problems. 

In addition, although dividing work may make the system more efficient, by dividing work into ever-more specialized tasks, we also disconnect people from the meaning and purpose of what they are doing. From their small, constrained box, people can’t see the big picture so they must make decisions and act within a very limited and constrained perspective.

Standardized, interchangeable parts.

Another core idea from the industrial revolution is the concept of, interchangeable parts. Standardization does make it easier to mass-produce quality products. Standards also make it easier to connect things. 

For example, having a standard for electrical sockets assures that you can plug in any appliance, and having a single standard for web links makes it easy for any web page to link to any other. 

We run into problems, though, when we try to apply standards to things that inherently have a high degree of variety: for example, a customer service call. Customer problems come in all shapes and sizes, and even problems that might seem very similar on the surface can be subject to a lot of variability based on the context. 

We have gotten so used to the idea of standards as a good thing that we tend to apply them in the wrong places. For example, consider the idea of a “best practice.” The concept of a best practice assumes that there is one “best way” to solve a problem: that every problem can be isolated from its context, and a single best way of solving it can be described and shared. Unfortunately, this has caused a lot of problems in the business world, because it’s impossible to isolate problems from their context. 

A system is not just the sum of its parts. What makes a system work is not the parts in isolation, but the interactions between them, and the inherent tradeoffs that must be made to achieve different kinds of system performance. Standardization is something you apply to the parts of a system, not a whole. A best practice from one company, or from one part of a company, cannot necessarily be applied successfully elsewhere. 

Systems expert Russell Ackoff points out that “If we have a system of improvement that is directed at the parts, taken separately, you can be absolutely sure that the performance of the whole will not be improved.” 

Ackoff illustrates his point with the following example:
“I read in the New York Times recently that 487 kinds of automobiles are available in the United States. Let’s buy one of each and bring them into a large garage. Let’s then hire 200 of the best automotive engineers in the world and ask them to determine which car has the best engine. Suppose they come back and say the Rolls Royce has the best engine. Make a note of it. “Which one has the best transmission?” we ask them, and they go over and test and they come back and say the Mercedes does. “Which one has the best battery?” They come back and say the Buick does. And one by one, for every part required for an automobile, they tell us which is the best one available. Now we take that list, give it back to them and say, “Now remove those parts from those cars, and put them together into the best possible automobile, because now we’ll have an automobile consisting of all the best parts. What do we get? You don’t even get an automobile, for the obvious reason that the parts don’t fit. The performance of a system depends on how the parts fit, not how they act taken separately.” 

What’s true for the fit of the parts of a system is also true of the fit between a service and the context within which the service is delivered. Every interaction with a customer is different: sometimes in subtle ways, and sometimes in profound ways. Two interactions that look similar on the surface may be dramatically different, in ways that are hard to predict. 

Consider a customer walking up to an airline counter who has already been bumped from two flights and whose luggage has been lost. These previous interactions will have a major effect on the context of the current one. 

Managers think that standardization is a good thing to do. If we standardize, goes the idea, our costs will go down. But if your interactions are highly variable, as most service interactions are, then the opposite will happen. Attempts to standardize the work will make costs go up, not down. This is because standardizing the work reduces the ability of your system to absorb variety. We try to cage variety into nice neat swim lanes: For example, voice menus in an automated voice system. But when there is a lot of variety in your environment, these kinds of control systems are exactly the way to make things not work.