This post originated from an RSS feed registered with Java Buzz by Michael Cote. Original Post: PeopleOverProcess.com: Agile Rebellion Feed Title: Cote's Weblog: Coding, Austin, etc. Feed URL: https://cote.io/feed/ Feed Description: Using Java to get to the ideal state. Latest Java Buzz Posts Latest Java Buzz Posts by Michael Cote Latest Posts From Cote's Weblog: Coding, Austin, etc.

I was at a lefty book store last night for a meeting about the Austin TimeBank. As you'd expect from a bookstore named Monkeywrench, there were, of course, many shirts and posters available.

One of them said, "We are the machinery. We can shut it down." Which seemed like a good summary of my approach to implementing Agile: every individual working on the software has the ability to effect change, and if people band together, they can simply decide to do things differently, despite what the rest of the company thinks.

Sure, if the company wants to shoot itself in the foot and fire everyone, that's a risk. But when you're the people planning, writing, testing, and supporting the code, you're the machinery and you should act with appropriate responsibility and power.

The corporate word for that all that is "teamwork."

Adopting Agile is Changing Company Culture

For all the worthy talk and categorizing of Agile practices -- unit tests, pair programming, continuous builds, iterations, clearly defined roles, cross-functional teams, etc. -- at the end of the day, to me, Agile boils down to this dichotomy:

Be extremely disciplined about following the process you choose, but always re-evaluate that process and change the process accordingly.

Or, to date my tastes in music, as Guru said,

We just need to maintain our focus, and elevate
What we do is we update our formulas
We have certain formulas but we update 'em
With the times, and everything, y'know
And and so.. y'know
The rhyme style is elevated
The style of beats is elevated
but it's still Guru and Premier

In summary: become a rapid feedback loop nut-job. And not just in development and QA, but in product management, marketing, sales, and even build management.

Achieving that state is something companies and organizations have been questing after for decades. It's one thing to want to be a "more excellent" company, but it's another thing to try to codify a system for continuous improvement. Agile implementations are a pragmatic go at those codifications in the software development world.

À la Carte vs. Prix Fixe: The Eternal Debate

The soft sell of Agile, however, doesn't include the zinger goal: to give over 90% of the control to the teams writing the software. (I'd say a 100%, but that would just be sheer madness...maybe ;>) That is, we want to make the traditional job of middle-management moot. The whole concept of middle-management doesn't jibe well with Agile think at all. Sure, someone has to get coffee, but the end-of-liners can do that themselves.

This doesn't at all mean that you want to can all of middle-management. Hardly. As with the traditional role of development, QA, and product management, we want to change what people are doing, and only change the people if necessary.

That's the failing of most attempts at Agile that I see: the organization is not upfront about how much of a sea change is really required. In fact, much of the talk I've heard recently emphasizes how gradual the change can be. You can salad-bar the tools of Agile, but few things make a developer more to dispassionate than when an organization says it's doing Agile but doesn't change drastically. Or we like to call it: Wagilefall.

Once your developers loose their passion, it's time to tattoo the word enterprisey on your head and milk the hump for all it's worth before The End Times come.

Technorati Tags: agile, change, peopleware, productmanagement, projectmanagement, software