Skip to content

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: , , , , , ,

Categories: Agile, Programming.

Comment Feed

4 Responses

  1. "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."

    I think most of the problems with Agile methods can be summed up in that one quote.

    Unless you're actually in the business of SELLING software, then the goal is never to deliver software. Software is at best an enabler of other, more important business goals. Agile gets sold as something that makes development better, but it requires a great deal of commitment from business folks who are likely to respond with a "so what?"

    A development method that benefits the business will be adopted no matter what developers think of it. Waterfall has two major benefits: a) it allows for (at least the perception) of being amenable to planning, control, and most of all budgeting; and b) it allows line managers to limit disruption and interruption of their routines and processes to scheduled periods that are under their control. From the functional managers, those are big benefits. You want to sell them on Agile, show them how it makes their lives better, right now, than the alternative. "Better software" won't cut it. Having their most requested features start to show up quickly might.

    Also–I think you're asking the right question here. However, there's a LOT of literature in the management field pertaining to this. People have been trying and failing to make businesses "agile" for the last 30-40 years, at the very least. It's not an easy thing to do.

  2. Indeed, there's quite a lot of text written on this topic. What are you're top picks? I'll have to check out the BOK in more depth, it looks exciting.

  3. I've actually going through them and they're disappointing; there's a lot of exhortion about adopting teams and empowering them and how this will achieve business nirvana without much acknowledgement of the reality that people have been saying this for decades now without much changing. It's not a precendent that bodes well for Agile adoption, although that's not Agile's thought.

    One thing that has occured to me is that "branding" it may have been a good idea–people are usually more likely to buy into a methodology for some reason.

  4. I guess this spherical cow joke passed me by while I was on blog hiatus. Fortunately, it's too good for you to let sit without linkage.

    In my half-time consulting job, the cow is definitely not a sphere. I don't know how agile could possibly fit in and I can't imagine how I could have any influence on it fitting in, given my status as an advisor, many times removed from the actual development. But God what a mess.

    Yet isn't that the reality of developing software? A big mess? Aren't all organizations dysfunctional in their own special ways? Software gets developed and delivered anyway. That's what I love about the business.