I would like to assert, without much to back this up, that agile is not about economic benefit.
Economic benefit is an important side-effect of agile. However, Agile Work is much more about learning, humans exercising creative potential, and value… which is in the eye of the beholder. Agile Work is about people, not abstract things called dollars/yen/ euros/etc. The only reason we care about dollars is because people care about them (certainly a tautology, but you know what I mean!)
I know I might be making a big deal about a little point, but I think that if we forget that dollars are the means, not the end, then we get lost very very easily. Agile is both means and end. It is about doing good work in a trust-building environment. It is about teams aspiring to the best service they can possibly give for their time, not just to be paid, but to derive the satisfaction of having created something that someone else values.
This is why the Agile Axioms are so important. The moment we lose sight of these axioms and start to treat Agile Work as if it was just a set of practices (no matter how effective) is the moment that it becomes un-agile and I no longer wish to be involved.
Now admittedly, as far as coaches go, I’m probably a little on the side of “impose the process and learn” rather than “learn and grow the process”. But I’m not at the point of “the process is perfect – thou shalt not change it” and I’m very comfortable working with other coaches who are more on the learn-first side of things.
When Agile Work is applied to software development, it is to everyone’s benefit to understand the value of the work being doing. I recently talked about using a financial model. I told the story of how using this tool allows an organization to make effective scheduling decisions. In fact, I strongly believe that the Team should be serving the “customer” and that the focus should be primarily around economic tradeoffs.
But this is just a specific practice. Delivering value is balanced out by self-organizing teams, adaptive planning and a whole host of other practices that are also important.
I’m not the only one who thinks this way. In the book Good to Great: Why Some Companies Make the Leap… and Others Don’t by Jim Collins, there is a whole chapter on the “Hedgehog Concept”. In brief, this Hedgehog Concept is composed of three parts: economics, excellence and passion. These parts are in dynamic interplay so that if a company only focuses on the economics, it will not become a great company. If it only focuses on excellence or only on passion, likewise it will not become a great company.
And what happens if you are trying to use Agile Work in a non-profit environment? Then suddenly economics takes a back seat. Does that mean that we can’t use Agile methods? Of course not. In fact, it might even mean an easier fit. So much of Agile Work is about culture change: trust and truthfulness, self-organization, learning, getting rid of bureaucracy, balance, etc. Big, command-and-control corporations are probably one of the more hostile environments for Agile Work!
This brings up another interesting experience I had recently.
I was working in the United States for a few weeks on a management consulting engagement related to an enterprise rollout of agile. The business development person I was working with (let’s call him Ed) told me a story about meeting with the CIO of a large oganization. The CIO complained about having to spend two years getting rid of the previous “religion” in the company about how to get things done. He was obviously concerned that adopting Agile would put him in the situation of having another religion around.
Ed comforted the CIO by telling him that agile was really just a bunch of common-sense practices. There is no religion of Agile.
I thought about it and realized that I had to disagree! Well… maybe it’s not a religion, but it is a belief system.
You have to believe that people have positive intent and that they want to contribute. You have to believe that people can come to agreement. You have to believe that money is not the be-all end-all of life. You have to believe that you can’t predict the future. You have to believe that people aren’t working only for their own narrow self-interest.
If you don’t believe these things, then you can’t be agile.