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. 

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?
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.
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.
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.


  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?

  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?"


Post a Comment

Popular posts from this blog

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.

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 applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

How To Write A One-Page Proposal to an Executive

One day you may need to communicate with an executive. Pro tip 1:  executives do not have time for you to dim the lights and show them forty slides with charts composed of animated dancing leprechauns and flashing arrows that emerge from the void in a checkerboard pattern. Pro tip 2:   Guys, and gals with deep voices, executives also don't need you to use your "Radio Announcer Voice."

As a rule, what executives want is simple: one printed page. No matter what it is, it should be one page. And it should be printed, not emailed.  You should plan to hand it to the executive, and then you should be quiet when they read it and wait for their questions.  It's harder than it sounds.
 So how do you do it?  Here are the steps:
Write the deck that expresses your proposal in as many slides as it takes.  Use imaginative animation and blinking letters if you must.Remove your title slide.Insert a new slide at the front of the deck with "Appendix" written on it in big …