Skip to main content

5 Reasons to Embrace "Cafeteria Agile"

Agile enthusiasts are quick to make fun of people who pick and choose among various agile concepts, philosophies, techniques, and tools, rather than working hard to be "pure."  We have a word for people who do that:  dilettantes. 

From http://lifeasareader.blogspot.com/2010/11/i-am-cafeteria-catholic.html
But when we use two words we call them "cafeteria agilists."
  • If a software development team has a burn-down chart, weekly releases of something to production, and no discussions with the business, ever, we are quick to chorus "THAT's not AGILE!"  
  • If they have a great working relationship with business partners and talk daily, but managers still do estimates of work durations, and assign work to the programmers and testers, we roll our eyes, and we start to abbreviate:  "TNA!"  
  • If a team deviates from any named agile technique, be it Scrum, Extreme Programming, Crystal, or WaterScrumFall, and even if they follow that last one to the letter, "TNA!"  If they use UML these days, or even Use Cases, "TNA!"  
One almost wants to design a t-shirt with "TNA" on the back in flashing letters, since it's a saying that fits almost every real-world situation you'll ever see.  It's fun to make fun.  And to some degree this is human nature--why would you choose to help a company "suck a little less" when you went into this business to change the world?  Seriously.

I have five quick defenses for "cafeteria agile:"

1.  People Have Label Fatigue:  Today's business people are tired of fads, and tired of labels.  Flying the "Agile" flag for this audience not only isn't good--it's actively going to get in your way.   Unless told otherwise, when you address a new audience, you should assume that they think you're here today to represent a management fad.  All your listeners can think of is "the guy doing Six Sigma wore a blue track suit, not a rainbow one," or "the TQM lady had a cuter English accent."
  • They do not want to lie on their backs on blue towels and listen to blurry cassette players through headphones, as they did with the PMP trainer.  
  • They do not want to do "Jeopardy" skits, like they did with the Tech Leadership trainers.  
For the label-fatigued audience, your best bet is to avoid using the word "agile" altogether, listen closely to what they have to tell you, figure out how to best help them from your treasure trove of agile philosophies and techniques, and just do those things first.  One day they may forgive you for being an agilist, and one day they may develop an interest in the Manifesto.  But in the mean time, what about giving them something they can use?
From http://www.oempromo.com/Tools-and-Hardware/Measuring-Tapes/index_25.htm
You're going to win more friends with useful piecemeal advice than you can by taking a hard party line that it's all or nothing.  Which is related to:

2.  It Takes Time to Change the World.  Think of each Agile Cafeteria choice you ladle out to your client as a "thin slice" of a bigger system.  What time frame did you have in mind, when you came in to do your "agile transformation" of this group?  A week?  A month?  18 months?  It's amazing how you can take a group of sophisticated software developers who understand about "incremental delivery," "refactoring" and "thin slicing," and have them despair when they aren't able to do a "big bang" change to the software development processes in a company of any size:  lock, stock, barrel, culture, tools, and team rooms.

Although "social epedimic theory" suggests that a "biggish" bang may occur along the way, you're likely going to have a long incubation period when you're slowly wooing your audience by feeding them measurable returns on the money they have invested in your agile advice.
From http://blogs.cornell.edu/info2040/2011/11/08/viewing-the-world-tipping-points-and-social-epidemics/
You may need to swallow your pride and just provide your audience with a few key things to try that will pay off, and then spoon feed them a little more the next time around, and the next time, and so on.  Later they will understand that they were short-changing themselves, but they can't hear that message from you now.  Which is related strongly to:

3.  Client Executives don't want a generic label.  They want something they can brag about specific to them and relevant to their own context.  There's a reason most consultants do a thing called "pain point analysis" early in their engagements.  If you know what the company's pain points are, you can design a strategy to help with those things that matter to your employer.

You may feel "TNA" if the team isn't collocated.  But if your sponsoring executives are going to live or die at the end of the year based on the ROI on some big project you're helping with, and what they're looking for is low investment and accelerated revenue, you won't make yourself popular by insisting on an expensive relocation of the entire offshore work force.  Find out what they care about and deliver it, making sure they get the credit for all of your ideas.

Executives will seek you out if they hear that you can selflessly solve their problems and make them look good.  They are less likely to feel a strong motivation from a person who comes on strong with the message "look!  you're doing this simple thing all wrong!"  Which brings us to:

4.  The Prix Fixe menu makes it hard for YOU to claim success too.  If you spend any significant time with agile evangelists, and you will quickly find that the "definition of how agile we are" quickly gets mixed up with the question of "how are we making software delivery better?"

Let's say your "definition of agile" is that software goes from idea to production in a week, every week.  You work with a pilot team to make this goal a reality.  You claim "Victory!" and then suddenly find yourself stalled.
from http://scienceblogs.com/strangerfruit/2008/05/02/national-mission-accomplished/
Let's say it turns out that your company mostly has customers who can only absorb change once per year, and then only with a LOT OF TRAINING.  The project where you were able to instantiate your idea of agile was an anomaly.  If you're measuring your "agile penetration" by the percentage of the portfolio going to production every week, and also calling that your "success," you've just boxed yourself in quite thoroughly.  Don't do that!

5.  Don't Be The Thing You're Fighting Against.  What do we agilists want to stand for?  Change!  Agility!  Flexibility!  The last thing we want to do is get locked into some rigid set of "dos" and "don'ts."  Do you seriously want the next generation of rebels to laugh at you?  No!  Have some self respect.  Be a cafeteria agilist, and be proud of it.
From http://www.huntsvillerewound.com/athens.htm
 

Comments

  1. I think the "that's not agile" argument is really about agilists' concerns that people could get SO MUCH MORE if they'd challenge some of the organizational assumptions that create the cafeteria approach. Sometimes picking and choosing is the best way to get value quickly from your agile transformation, and other times it's a way to avoid confronting the problems that a more whole-hearted transformation would make obvious.

    In either case, it comes down to: what *value* are we getting out of the set of practices we choose? And is what we're choosing the best we can do based on what we know right now?

    ReplyDelete
  2. I agree. It looks to me like it's hugely a matter of context. If I were surrounded by cynical "let's just do something and call it agile" people, I would come out fighting on the side of "have some standards, for heaven's sake!" But either way, I think the bottom line isn't "how agile are you" but "what results are you seeing that matter?"

    ReplyDelete

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica