AgileAnti-patternsKanbanLeanScrumSmart use casesUse casesUser storiesWaterfall

Flower-Power Agile Fluffiness

To all the dear people in the agile community and to the faint-hearted: this will not be an easy blog post. There was a time when being a software developer was a decent craft, requiring decent craftsmanship and yes also a lot of creativity, some communication, some collaboration. Still it was a decent craft. The waterfall-ish methodologies we used weren’t extremely optimal, but at least software development was a craft. Similar to a carpenter who uses his tools to craft new furniture, or a industrial designer using his tools to come up with a new model Toyota – I know this is not the best example, but at least I now have the attention of the kind folks in the lean community. And then came agile.

Now believe me, I don’t have anything against agile. I’ve been promoting agile and iterative approaches to software development since the mid-nineties, and haven’t done traditional projects ever since. Agile used to be about engineering. We were improving ourselves by using better techniques, continuous integration or continuous deployment, writing unit test, pair programming, writing smart use cases or user stories, using a bug tracker, burn-down charts and even post-its on the wall. So far, it’s still all in a days work. There was a time that as an analyst, a developer, or a tester you could be proud of being in an agile project.

But these days if I look at what’s going on at agile conferences, on twitter, in blog posts, literature and discussions on agile, Scrum, Lean, Kanban and whatever new flavors of the month are passing by, I get the feeling I’m no longer talking about craftsmanship but rather ending up in Disneyland or in San Francisco in the late sixties. I’ve got a feeling were not in Kansas anymore.

image
Agile coach at work.

Agile community anti-patterns

Certainly it’s a good thing everybody can join the agile community. But I witness a lot of repetitive behavior I strongly discourage. Let’s name this repetitive behavior agile community anti-patterns – not to confuse with agile anti-patterns. The latter merely describe failures in agile projects, and yes these do occur, while the former describe community failures. Let me sum some up for you – while on the fly breaking my first anti-pattern:

  • Metaphorizing
  • Zenify
  • Kindergarten Agile
  • Open Door Wisdom
  • Scrumdamentalism

Allow me to elaborate a bit on these agile community anti-patterns.

Metaphorizing

Although I’m not sure metaphorizing is a even good English word, I’m quite sure you get the meaning of it. Everything anybody comes up with these days about agile – or about what people think is agile – is immediately turned into a metaphor or is given a silly name.

Can we please stop talking about the Gemba Walk when we mean that it’s a good thing our manager stops by every now and then? This shouldn’t even have a name.

image
Japanese manager stopping by.

What does it mean when an agile specialist states that “you should verify the five why’s with the reverse loop”? And what about Feature Injection? According to a recent tweet “feature Injection is more about using examples to discover the relationships you need and missed or got wrong.” Call me old-fashioned but I totally miss what this is about.

Zenify

Yes, I know lean manufacturing started in Japan at Toyota. So there is a link between agile and Japan. But is that an argument to zenify software development?

image
Our new Feng Shui office space.

Why do we need to explain roles in a software development project as samurai, sensei or roshi. I thought product owner and agile coach were already abstract enough. What about re-arranging our office in a Feng Shui manner? Also the word kaizen seems to become very popular. Quoting a recent tweet: “Just write down small things on small papers. It’s your kaizen.” Although I’m all for small things what does this mean and why do I need to introduce this in my project?

Kindergarten Agile

Not sure about the average level of maturity of people in agile projects around the world, but in the projects I’ve been in the last decade or so, people where pretty mature. So why is it groups of sensible people at unconferences are discussing the Happiness Index of projects? To me this sounds much more like a weekly column in a women’s magazine than a solid engineering practice in a software development project.

And I for one certainly don’t want to have to pass a baton if the flow in my stand-up meeting or scrum isn’t achieved automagically. Still this was seriously recommended by one of the authorities in the agile community during a recent presentation at a conference.

Some tweets to further illustrate my point? If someone says “Add Ready for Celebration before the Done column on your wall board” should I start decorating the office? It makes you wonder how often his projects get things done. Even worse is “Make sure you don’t miss the agile elephant versus the waterfall elephant in the lobby.” which was tweeted from a recent agile conference. Where was this conference held? At the Toys-R-Us?

image
Participants at a recent agile conference strolling down the exhibition hall.

Open Door Wisdom

Often I see quotes coming from the agile community that are no more than open doors, and have been open doors in projects for decades and perhaps centuries, but that are treated by others in the community as sources of new and ultimate wisdom.

Recently a speaker at an agile conference claimed that “if your retrospectives don’t add value to your project, you should change your retrospectives.” Duh. The speaker got a loud applause from the audience, he is now considered an absolute guru, and his quote got tweeted and re-tweeted all over the world. This is not even an open door, it’s an open gate.

Scrumdamentalism

Now I’ve blogged about Scrumdamentalism before, but with the newer generations of agile converts, some communities are getting more and more populated by religious zealots who will treat their newly gained faith with deep fundamentalism. Any best practice from their own belief is treated as mandatory, while followers from other beliefs are often considered heretics. A recent blog post states that: “A technical project manager can be a good product owner if he sticks to managing the product backlog and abiding by the rules of Scrum.” I wasn’t aware that Scrum even had rules. You learn something new everyday.

And if Scrumdamentalism alone isn’t bad enough already, it is even enforced by the so-called leaders themselves, proven by the following horrible quote “the team needs to listen to god talk and follow the commandments” from one of the Great Leaders in this particular community. Dear agilists there is is no one-true-belief. There’s value in all of them. And also can we please abolish the function title Agile (or Scrum or Kanban or Lean) Evangelist. Moreover, people calling themselves Agile Sensei should be banned from conferences and projects if you ask me.

Flower-Power Agile Fluffiness

Please people can we stop adding all this new age Flower-Power fluffiness to agile. In my opinion the agile community with all it’s great ideals and best practices is slowly degrading into a worldwide Luna park. My guess is I that it won’t be long before someone somewhere will suggest to add a psychotherapist to every software development project. “How do you feel about not being able to get your user story to the Ready for Celebration column?” Or plan a clown’s visit during retrospectives to increase the Happiness Index.

image
Agile retrospective with product owners present.

We are slowly becoming the laughing stock of the engineering world. I long for the time that we re-introduce engineering in our trade, and all go back to work again.

29 thoughts on “Flower-Power Agile Fluffiness

  1. Very amusing, and points well taken. I wonder if this represents the pendulum swinging from the extremes of the 1980s, perhaps too far toward the opposite extreme. Time to reel it back in a bit, as you suggest. However: Remember that humans are humans, and to ignore that in a question for engineering purity would not fix anything, but merely fail in a different way.

  2. Great post – I concur: While there are a seeming majority of folks that /do/ take agile adoption and its challenges seriously, I’ve made the same observations over the years.

    In 2007 I attended a local conference, XP Day Toronto, and just about invited some professional colleagues and potential customers to attend to get some exposure to agile ideas and engineering practices. Thank God none of them had the time – I blogged about my disappointment in the event (http://www.chapmanconsulting.ca/post/2007/05/15/XP-Day-Toronto-2007-Review-35-Stars.aspx). Re-reading it, I came across this passage that resonates with your theme:

    “If you’ve never done an open space, they can immediately seem like some liberal, wishy-washy, there’s-no-right-or-wrong-answer love-in. And to a certain extent – they ARE.”

    Arguably, Open Spaces can work wonders for generating an agenda people want to use, but in this case it led to meandering topics that had little to do with the conference theme. Then there was the “Closing Circle” that was signaled by the drumming of a gong. That nearly sent me over the edge…

    The organizer, JB Rainsberger, was a little off-put by my comments and, being a stand-up guy he did offer a free pass to the next XP Day conference to win me over. It was a nice offer, but I’d already seen enough touchy-feeliness for one day.

    Great read – I’ve retweeted to all and sundry.

  3. better keep telling the right story instead of bringing the wrong story under attention. It will not last for long anyway.

  4. I’m a big fan of provocative blogpost, a category well suited to describe yours.
    Although I don’t agree with many of your points, you made me think, and I thank you for that.
    It is true that many agile ideas are percieved as strange and uncomfortable. But is that a reason for not trying them?
    After all, you can’t claim the software industry has reached an acceptable maturity level.

    I agree 100% on getting rid of the buzzwords and Japanese lean manufacturing terms, as long as we keep the ideas behind them, which are proven to be valuable in the previous decades.

    1. Hi Nick. As I said also in this post, there\’s nothing wrong with agile. I have been involved in agile project since the mid-nineties, and intend to keep on promoting agile, and running all my project agile and iterative. My post had nothing to do with challenging the values and best practices of agile.

      But I do feel the agile community needs to get rid of all this fluffiness it surrounds itself with these days. The recent ALE2011 Conference was a very good example of this fluffiness (judged by the feedback I\’ve seen from it).

      1. The main reason (in my opinion) why these ideas are perceived as ‘fluffiness’ is because of the communication dysfunction in software development and engineering. We fail again and again to interact with end users and therefore don’t deliver the requested value.

        Maybe the ‘fluffiness’ can get us out of our comfort zone and slowly help us to remove this dysfunction.

        I suggest you attend ALE2012 next year and share your ideas in a session or during the open space. We ‘re more than happy to learn from them!

  5. I agree with probably 80% of the post. There are some really weird terms going around that confuse people unnecessarily.

    Two things I did want to call out:
    1) Scrum does apparently have rules now. But there are hardly any of them so it isn’t probably a big deal and working out which one is a rule vs a guide is a fantastic wheel of fate.
    2) Although Agile started with software development it has evolved beyond that. It started with ‘these are good ideas’, then when we found a new one it was added on, etc, etc until you have the problem you are describing. Yes some of them might not be worthy – but all? Are all of the lean principles that were added in worthless? Is it in the realm of possibilities that other industries are looking to what Agile did for software development and applying those techniques creating this feedback loop of change?

    Yes we need to be careful that we aren’t always chasing the new shiny but sometimes there will be nuggets of gold in the pan.

    1. Hi Renee. As said, nothing\’s wrong with agile. I have been coaching and writing code in agile projects since the mid-nineties, and intend to keep on promoting agile, and running all my project agile and iterative. My post had nothing to do with challenging the values and best practices of agile – or lean – or Scrum for that matter.

      It\’s just that I\’ve had enough of all the fluffiness. More than enough.

  6. Thank you very much for this post. You have managed to identify and put in words some of the nagging feelings I have had about the agile community for a while.

    I know people have good intentions but I think we’re currently overdoing it a bit. It’s getting tacky and a bit silly.

    I was wondering though how much of a role cultural differences play: I would expect your post to resonate a lot more with Europeans (especially Scandinavians and Dutch people) then e.g. Americans. Do you happen to have any information on this? (Just a random thought that I thought could be interesting to follow up on)

    Anyway, great post & thanks for being the voice of reason 🙂

    1. Hi Sandy. This is probably the nicest feedback I\’ve got on this post. Love being the voice of reason (although not many agile conference will invite me anymore to speak I guess). 🙂

      1. It’s easy to say this is the nicest comment, because she fully agrees with you. I always like comments better from people who don’t just agree and try to get a conversation started. No one knows all. That’s the reason an Agile Sensei should be banned from conferences! 🙂

    2. And, about the cultural thing. I\’d say here in the Netherlands, and in the North-West part of Europe people are not that fluffy – Calvinistic as we say. That\’s what surprises me about this agile fluffiness being so popular here too.

  7. I recognize most of the stuff that you mention. And I agree with most of it, though not everything.

    Sometimes you need to do some marketing to get people’s attention. I see this being done for agile, just as this is done for any other method or technique. For instance people exploit the link to Japan and zenify stuff, to say “this is agile, and agile is different”. They use words like celebration and party to tell that “agile is fun to do”. This is how marketing works, it attracts people and makes them take a look at agile, which is good.

    But I agree that that is where this “circus” should stop. The agile concepts are solid and based upon social science, and in my opinion have proven to deliver results in many situations. And yes, most people that I have worked with like agile, it fits how they want to do their work and they enjoy it when they work in an agile team. Nothing wrong with having fun at work, but let’s not forget that the main reason to use agile is because it simply works.

  8. Hi, I definitely agree with the general idea of your post, and said as much at a lightening talk at ALE2011. I will also be blogging about my observations hopefully soon.

    Although to be fair, the agile vs waterfall elephant was related to an activity that the children of the attendees did, so “Kindergarten Agile” can’t really be seen as a pejorative in this case.

  9. This blog post is making me think, and I thank you for that.

    Personally, I’d like to get away from all the vague labels such as “agile” and simply focus on finding ways to improve the software quality, and the lives of the people developing and using the software.

    It’s interesting to me that you found ALE2011 to be “fluffy” (were you actually there? Or just following the tweets?) but the reaction I saw in tweets from actual ALE2011 participants was that many of them who are now agile coaches vowed to go back to a hands-on development role. That seems like the opposite behavior to what you are criticizing.

    I’d be interested in your views on what the agile community (or, better yet, the community of people wanting to improve software) should be doing instead of these things that you don’t like. I think you’ve made valid critiques, and now I’d like to see ideas for what to do instead. (Maybe you already have posts on that, I’ll look around your site!)

    1. Hi Lisa. Good point. Sorry I only found your comments so late. In my opinion we in the \”agile community\” should strive towards assembling custom agile approaches for custom projects, tailored (and continue to tailor during the project) to fit the needs of that project. There\’s stuff to learn from any of the dozens of agile approaches, and yes, even from traditional software development techniques (which we seem to have thrown overboard when the agile wave came upon us).

  10. Yes, that’d be my gut feeling too. I worked in Copenhagen, Stockholm and Amsterdam and I wouldn’t have expected especially zenification to resonate with the Danish, Swedish or Dutch at all. Interesting and a bit disconcerting though …

  11. You’ll be happy to hear that Chris Matts, who picked the name “Feature Injection”, has described it as an example of why you shouldn’t pick names when you have a hangover.

  12. To some extent, I agree. I’m not wild about buzzwords like “talking stick” but the idea *is* a useful tool when everyone’s talking at once: you want one person to talk at a time, and a physical object that you must hold to speak accomplishes that.

    To some extent, the same thing goes with “kaizan”. In some ways, I’d prefer “continuous improvement”, but the problem with that is that everyone already assumes they know what it means. Whereas with “kaizan”, they might look it up and discover that there are actual specific processes and roles involved.

    For a similar reason, I once (tongue-in-cheek) proposed renaming Agile:

    “We believe Agile software development is being dumbed down, commodified, and is losing its spirit. We seek to replace the current name with one having two virtues: first, that it capture more exactly the attitudes originally behind Agile; second, that it be obscure enough that no one will assume they already know what it means and that—amazingly enough!—they are already doing it.” — http://arxta.net

    Can’t scrape up any justification for “Gemba walk”, though.

    That said, I want to echo Dave Nicolette:

    Two nice things about Agile were that (1) “The Agile methodologies were methodologies created by people who like to program” — Pete McBreen, and (2) there was a real effort to /blend/ the social and the technical. For example, one of the reasons for pair programming is that it converts solitary decisions into social decisions. If you’re working alone, it’s easy to convince yourself to skip a test or refactoring you know you should write. Working with a pair makes that harder because it brings all kinds of things like peer pressure into play. That helps me and other people without iron self-discipline write better code.

    It’s the blending that’s gotten lost as Agile has gotten infested with hypesters, talkers-not-walkers, and people who view projects as being about personal therapy rather than delivering code. The answer isn’t to go back to putting the people who do tech over *here* and the people who do people over *there*. The ongoing backlash against Agile risks that.

    I’m willing to accept a fair amount of Metaphorizing, Zenification, Kindergarden Agile, so long as it comes from people who *ship*. I can steal the ideas and leave the names behind. In the case of Kindergarden Agile, I can think about whether the things-they-do tell me something about real problems without necessarily adopting their solutions.

  13. Of course, agile has always been and always will be a luna park. I have never been at any agile project that didn’t have major problems, which could be solved by simply shutting up and trying to actually get some work done. Whenever I see one of those damn boards filled with nigh-unreadable post-its scattered all about its surface, I get the urge to haul my flamethrower and set the thing ablaze. I wish I was kidding, but it’s the truth.

    Agile has never worked and it never will. Proponents of agile are simply out to fill their pockets with the money of hapless managers who think they have found yet another silver bullet. The day when all those scrum “masters”, advisers and agile “gurus” finally get kicked out of the office will be a happy day indeed.

  14. I have a feeling you’re presenting two complete opposites here. One with _everything_ flufiness, and one completely without. Know you’re completely right if this is continously presented at conferences. I wouldn’t know, I’m not at those conferences. But isn’t Scrum about what works best for you? Maybe these people _need_ the flufiness. :-p

    However, in the past, before Agile, people were hiding the fact that they weren’t that good, by shouting a lot and having a lot of meetings. This flufiness feels a bit like it. As long as you present cool new gimmick-like words, you’re a guru in the field and get invited back to conferences. While in the end, you really don’t know all that much, or at least don’t present anything new. Not even good solutions to problems people are having with Agile.

    The feature injection quote is a good one. No idea what was said there.

  15. Brilliant post, funny, and provocative. Also daring in a field where there are some absolute thinkers who might not always see the irony.

    I guess the main point is that there’s still a large gap between the world of buzzwords, gurus, conferences etc. and actually getting things done for our customers. Seeing someone who I consider an expert on the topic critique the excesses makes my day 🙂

    Before you know it, people will be calling you an Agile Sensei.

Comments are closed.