Dysfunctional Agile, Agile-in-the-Large

There’s an old joke in which which an engineer, a psychologist, and physicist (or some other trio involving a physicist) are asked to optimize a dairy farms production. The first two both come up with advice based around the mechanics of their skills. The physicist then delivers the punch line: “first, assume the cow is a sphere.”

At times, Agile-think can feel like that last piece of advice, esp. when applied to large organizations. The comments around this pointer to a Peter Coffee column on Agile in dysfunctional settings reminded me of the sphere cow joke. As Frank Bolander said in one comment:

I hope we’re not saying here that “your organization doesn’t fit my management style so you’re deficient”. Agile has to adapt to reality(see above) just as much as organizations need to be more flexible.

If you have the time, be sure to listen to Peter Coffee’s keynote that’s the original nugget the above link-verse is spinning around.

When Perfection is Elusive

What’s missing from most of the Agile dialog that I find are methods for fixing, or working with, dysfunctional organizations. That’s been the case so much that I’ve narrowed my interest in Agile to just that: how can you make Agile software development work in crappy situations, and/or when do you give up?

I recall one teleconference we had with Ken Schwaber when figuring out how to implement Agile at BMC. Someone asked the equivalent of “what if all this isn’t working out?” to which Schwaber replied something along the lines of,

I was working with a company awhile ago, and things were going poorly. As I talked with people, I realized that their goal was not delivering software, but maintaining the organization. So, you have to ask yourself, is your goal to deliver software? If it is, then Scrum can help. [Again, this is an inexact quote from memory.]

It’s one thing to declaire that things are “screwed up” (to use the PG phrasing), and another to figure out how to un-screw them. To me, unscrewing things up is the more the glorious and helpful task: once the system is in a perfect state, it’s easy to use a perfect process. This is also a good approach to take to SOA and other The Next Big Thing in Enterprise Software: does the approach require a spherical cow?

The Baby and the Bath-water

Now, I’m not laying down a blanket, negative assumption about Agile-think. I’m actually a huge fan and believer in the worth of Agile. Instead, I’m trying being additive in my suggestions: I’d like to see much more “here’s how you unstuck” things discussions. I want to move those skills, thinking, and stories from people’s experience to common wisdom and lore.

I’m interested in seeing Agile move from more of a developer-level, philosophic-magic (“it just works!”) to boring tools that all levels of a business use. Boring tools are great because they work in the majority of cases and don’t require drinking the kool-aid. More importantly, you don’t have to sell the value of a boring tool every time you want to use it. Everyone knows a screw-driver works and holds stuff together. It’d be great if everyone knew that rapid feedback and changing course appropriately (or not!) is key to successful software.

Team Agile vs. Agile-in-the-Large

Agile is a “solved” problem at the team level, but it’s still an open question when applied in the large. To put in crude terms, I feel like you’re always trying to plug and Agile team into an un-Agile org-chart. The team, and even the immediate layer above the team may be following Agile practices, but once it reaches out into the rest of the organization, leakage occurs in both directions: development needs frequent input from the field on what’s valuable to implement, sales and marketing need to “sell the future” beyond what development can promise.

What needs to be charted out in are Agile practices and process in the rest of the orginization: product marketing, marketing, sales, support, IT, tech writers, and even HR. As developers, we’re quick to arm-chair manage the rest of the organization (or anything, really, being the little geniuses we know we are ;>), but just as with us, others don’t want to be told how to do their job. More importantly, they probably know better than us how they could be doing better: often times, people just need to be given permission to do so.

So, while abondoning such structures is certainly possible (alert readers might note the fact that I went from a 5,000+ person organization to a 3 person firm, and call pot-and-kettle on me), the thing now for people who want to do Agile is to figure out how to make it work in “dysfunctional” organizations by coming up with ways/tools to change those organizations or changing Agile-think to fit.

Some Hurdles

The scope of this post is beyond coming up with a useful response to the above, but here are a few points to start thinking with:

• Developers and (of late) QA are the vanguard for Agile, and they need to be given the tools to bring it to the rest of the organization. Those two groups are already at a disadvantage in that they’re the chicken head eating freaks of the organization who have a legacy of being unhelpful and expensive. Those groups are also the weakest when it comes to money and power: their primary power is causing failure and late ship dates…which is a crappy thing to be known for. Not to mention the fact that many of those people simply want to do their jobs and not take on organizational change.
• The primary problem is this: changing the organization is done by executives and management. The organization’s purpose is to enforce that fact and enforce it. What this means is that Agile in the large depends on executive and middle-management sponsorship. The problem is that these are the people we’re trying to change in the first place, and often times we’re trying to shift power and responsibility from them down to the “lower levels.”
• Another challenge is that, frankly, poorly run businesses can still be profitable and “good.” Maybe they don’t last in the long term, but they serve the short and medium term goals of the people involved. The goals of company may be to make money, but the goals of the people are often different. The Goal, of course, did a great job explaining this a long time ago.

I’ve been thinking about other problems and possible solutions this morning. While I’m sure I can come up with more, and I’m more eager to hear from you.

And, for those who like them, as usual, here’s a mindmap:

Disclaimer: BMC is a client.

Tags: agileinthelarge, mindmaps, dysfunctionalagile, KenSchwaber, peopleware, petercoffee, process