Agile Backlash? Or Career Wakeup Call?

I’ve been reading accounts of how Agile has ruined lives. It’s quite the hot topic at the moment. Initially I thought it was yet another Agile backlash.

But unlike some of the previous anti-Agile rhetoric I’ve encountered, this isn’t by Traditional Consultants accusing Agile Consultants of playing with post-its instead of doing “real software engineering.” Nor is it by Traditionalists looking at Agile from the outside and saying “that dog don’t hunt.” Rather, it’s by practitioners who have been on “Agile” projects and burned in some way. These are working programmers with skin in the game. And they’re hurting.

So I started reading more carefully.

As I read through the vitriol in the comments, I noticed two general patterns.

The first pattern involves people who have been burned by a corrupted flavor of “Agile” foisted on them by clueless managers in dysfunctional organizations. By “clueless,” I mean the kind of manager who thinks the way to find a qualified coach is to find someone with a certification from a 2-day CSM class. Or the kind of manager who thinks that if we do a global search and replace on key phrases in our process docs that we will somehow be transformed into an “Agile” organization. By this I mean:

phase -> iteration
project manager -> scrum master
requirements -> stories
estimated hours -> points
status meeting -> standup

Sadly, there’s nothing we can do to prevent this bastardization of the word “Agile.” It happens with every buzzword. ISO, CMM, CMMi, RUP, take your pick.

I was on a project once where management decided that UML was the right cure for all our ills. Of course, it wasn’t. Didn’t help a bit. Actually made things worse. After everyone got trained up on UML we had to have meetings to review useless artifacts created only so we could check off a task item: “Create Use Case.” But UML was not the problem. The real problem was an executive team in so far over their heads that they were willing to believe in magic, and a staff so burned out and sick from the verbal abuse that they were willing to pretend magic existed.

So, to the people who are victims of Fake Agile, I extend my deepest sympathies. “Agile” ruined your life only in that it provided an all-too-glib buzzword for your organization and management to latch onto. I dearly hope that you’re able to experience real Agile: frequent delivery of value at a sustainable pace while adapting to the changing needs of the business.

Actually, maybe you already had experienced Agile, but your clueless management screwed it up by initiating an “Agile Transition” with so-called Agile Consultants or Coaches who dictated and enforced cumbersome variations on Agile practices in a sad command-and-control parody of Agile with the  ironic result of decreased communication, collaboration, visibility, feedback, and alignment. For you, I hope you can escape the nightmare and find a healthier organization.

But there’s a second pattern of responses that I find both disturbing and fascinating. The responses in this category do not appear to be motivated by a misunderstanding of Agile, but rather are attacks on Agile practices: standups, pairing, collaborative teams, open team rooms, and the like.

At the mild end of the range in this second pattern are people who object to being “interrupted” by meetings or derailed by having to collaborate with others.

I suspect that some of these folks are introverts working with a whole passel of extroverts who took to the social nature of Agile like ducks to water. Introverts need time and space to process stuff internally. If they don’t get enough time to themselves during the workday, they burn out. If this sounds like you, I hope that instead of seeing Agile practices as evil you can work with your team to achieve a workable balance of collaboration time and alone time.

At the more extreme end of this second pattern, however, the comments get nasty. Some refer to the business stakeholders as idiots, use dismissive labels like “bean counters,” and decry the work of other “crappy programmers” that they have to clean up after. These aren’t just attacks on Agile, they’re attacks on people.

Perhaps some of these comments come from good people who have been in toxic environments too long. I want to give everyone the benefit of the doubt.

But I think that at least some of these folks have a vested interest in the status quo. They liked the old way of working because it allowed them be the magicians behind the curtain. No one knew what they did or how they did it. They could pick and choose the work they liked.

These are the folks who think they are at their most productive behind a closed door, headphones on, music blaring, being “Programmer Man” (or woman, as the case may be). They dismiss requests for help with an airy wave of their hand and a distracted, “RTFM.” They think Dogbert is right about just about everything and they resent being stuck working with a whole pack of Wallys. They like to work from 3PM to 1AM because those are their best hours: things are quiet and they’re not interrupted. They write what they want, the way they want to, without concern for what the business stakeholders asked for.

Many of these people are undeniably brilliant. They produce more code—working code, even—in an afternoon than an average programmer can write in a month. And it may even be beautiful code, too. Well-factored. Clean. Really good stuff.

And yet these folks are not nearly as effective as they think they are.

Their code might be elegant, but because they dismiss Product Managers and BAs as “idiots,” their code doesn’t do what the business actually needed.

Even if their code does do what the business needed, the fact that it was created in isolation means that doesn’t play well with the rest of the system. So it takes weeks to integrate and test it. These brilliant programmers, self-satisfied with their own competence, drastically discount the work required to turn raw code into something that has business value. They blame everyone else for long integration cycles, unable to see their own hand in the mess.

And even if their code works within the context of the rest of the system, the organization is frequently bottlenecked through them because they’ve decided to take on the mantle of the hero.

For these folks, Agile represents loss. A forcible expulsion from their comfort zone of darkened offices with closed doors and noise canceling headphones. The loss of autonomy afforded by opaque processes. The loss of sovereignty over “their” code.

And so I wonder if perhaps at least some of the current backlash is offered by those who are being forced out of their self-imposed isolation, into an open team culture. It feels like a crisis to them. It may even feel like Agile is ruining their lives. But as Jerry Weinberg says, “it’s not a crisis; it’s the end of an illusion.” In this case I think it’s the end of the illusion that they were the best because they cranked out more code than anyone else. Or the illusion that all that teamwork stuff is a bunch of fluffy nonsense and not nearly as important as the technical heavy lifting they do.

The truth is that creating even a modestly complex software system is of necessity a social activity, a team sport. It is not enough to be brilliant. It never was. Effective team members have social skills. They listen, collaborate, share, and contribute.

So, to the people who think Agile ruined their lives because it requires an uncomfortable level of teamwork, I say: what a marvelous learning opportunity for you. Yes, you are brilliant. But to advance as a professional, you need to be so much more than that. A deeper understanding of algorithms, OO design, or functional programming will not help you move forward further. It’s time to get on with the difficult and painful work of learning to be a good team member. Welcome to the next stage of your career.


Subscribe to our e-mail newsletter to receive updates.

48 Responses to Agile Backlash? Or Career Wakeup Call?

  1. Lisa Crispin September 8, 2010 at 5:49 pm #

    Well said!

    For me it always comes back to: projects succeed when they have good people allowed to do their best work – regardless of the ‘methodology’ or labels we put on what they do.

    If people would focus on the best way to produce good software in their particular situation, with an open mind to good ideas that might be new to them, we wouldn’t have to endure all the philosophical debates.

  2. David Christiansen September 8, 2010 at 6:00 pm #

    Good post Elizabeth. I have experienced the type of person you described in the latter part of this post as I subversively implemented agile in a “historically waterfall” IT department. I gave him an opportunity to grow. He didn’t. We battled publicly for several months as he fought to keep a chokehold on the workflow of the whole team. Ironically, he was a big proponent of Agile – he talked about it all the time, even while I was rolling it out right under his nose and he was resisting everything I did.

    Eventually I gave him a different kind of growth opportunity – a chance to work somewhere else.

    I think many people/organizations who decide to adopt agile underestimate the importance and difficulty of teaching a large number of people to value what agile values and to be guided by the principles of agile when they have spent their entire careers using the antithesis of these things for an organizational compass.

  3. Avdi Grimm September 8, 2010 at 6:11 pm #

    Really well said. I’ve seen some of this backlash firsthand from programmers who were brilliant but somehow still managed to be net negatives for their team. Heck, I used to BE the introvert who wanted nothing more than to be left alone with my code. But I discovered that in a healthy team, close collaboration really isn’t as scary as I thought it would be.

  4. Anthony Topper September 8, 2010 at 7:07 pm #

    Well put Lisa Crispin, the root of these problems aren’t the process; they are the people.

    On a tangential note, check out: “The End of Management”

  5. Dave Smith September 8, 2010 at 8:32 pm #

    Do you mean to suggest that Introverts are more likely than Extroverts to call customers “idiots”? That’s not been my experience.

  6. Peter Saddington September 8, 2010 at 8:36 pm #

    Well said. Collaboration and communication trumps shoving methodologies down people’s throats. Sometimes agile may not even be the answer!

  7. Recovering Waterfallist September 8, 2010 at 8:59 pm #

    Great article. I fall into case #1. Management has declared that we are agile. All the correct agile nomenclature is simply laid over the top of previous existing waterfall practices.

    It sucks balls.

  8. ehendrickson September 8, 2010 at 9:12 pm #

    Hi Dave,

    Whoops! No, that’s not what I meant. Edited for clarity. Hope the newer version doesn’t unfairly conflate introversion and name-calling.

    Thanks for pointing out my error!


  9. Dave Whalen September 8, 2010 at 9:56 pm #

    Let me go on record as one of the few fans of Agile. Even the word makes me cringe. In fact I’ve spoken and written against it often. My beef is not with the idea or concept of Agile but with some of the authors, consultants, and other pundits with a “My Way or the Highway” approach. In fact one of them scolded me, very publically, that I was hurting those that make a living writing about Agile with my anti-Agile comments. I was not-so-politely asked not to attend their conference. I skipped it.

    To me, there is no one, singular, universal, best way to test software. To be honest, I really like most of the Agile philosophy. But if I choose to modify my approach – say I implement iterations of 6 weeks rather than 2, am I not Agile? I’m doing most of the other stuff. According to some purists I’m not Agile. How dare I say otherwise!

    That’s where they lose me. I recently read where one of the pundits was scolding people for falling off the Agile “bandwagon” and falling back into “mini-waterfalls” So? They modified their approach – is that so wrong?

    Is waterfall really all that bad? Is Iterative? RUP? To me, it’s like Gumbo – a little bit of this, a little bit of that, and Viola! – Gumbo. No two recipes are exactly the same yet both are yummy. Wait – that’s a great new process name! Gumbo – the new Agile. Remember you heard it here first!

  10. David Reich September 9, 2010 at 3:42 am #

    I really liked this article. It has a lot of great insights, and I think you really nailed several key points.
    But one subtle point that I disagree with is that I don’t think the introverts are the ones complaining. I think they are finding passive ways to resist the additional collaboration.

    I think you were tip toeing around this point, and so maybe you are just using “introverted” as a nicer way to say what I am going to say here. But my theory is that the people that complain the most are the spoiled coders who are used to having the luxury of doing things their way with little interaction other than having to provide a weekly status to their manager. They would prefer to optimize their own little world, and may not fully realize the waste incurred at the team/solution level.

    It shouldn’t be about “me” and what makes me the most efficient coder I can be. It is about “us” collaborating to give the customer what they want. There is a different kind of intrinsic reward there, but I think it is equally if not more fulfilling.

  11. Bachan Anand September 9, 2010 at 5:50 am #

    Well said Elisabeth.

    I believe that Agile values and principles are the way to go for approaching work even beyond software.

    This too shall pass,what we can do is to fall back on the values and principles to rebuild any trust lost in Agile.

    Change is hard especially if you resist change.However change is the only thing that is constant, let us continue to shine and light and help people embrace change.

  12. JW September 9, 2010 at 7:34 am #

    Agile can be scary for many… but the ones who have trouble usually need something we struggle to create. Is there a real cumulative flow diagram from the system showing you a believable reality – numbers might trump rhetoric. Hand waving is not real enough for many.

    There is a lot of logic to why most agile methods work – but the old timers, myself included, have seen silver bullets come and go. So getting the right stories – and more than that the metrics that make the case – can be pivotal.

    Logic and numbers may be the path for some – where human ideas may work for others. If we want to sell the idea – we have to adapt to their mental frame and learning style. And we should be slow to ostracize or criticize – once it becomes real to them they might easily bring new magic and enthusiasm.

    Those who change slowly are great at staying the course – they just need a reason to switch tracks – and it has to be a reason that resonates with them – not us. Usually the problem is we are too busy talking and not listening. Guess what – they might have ideas of their own that are not being heard – ganging up is not something to do to anyone you want to keep. Ultimately “agile” is not the last word on anything – don’t stomp on someone’s voice. I have seen order of magnitude productivity improvements that have nothing to do with “agile”. Don’t be surprised if humility by those who dominate the microphone is the path forward.

    Blaming anything on personality types bothers me also. There is leverage in dissent… I hate seeing the dominant personalities blame things on others just because they can. Thats a cop-out and it may kill important perspectives. THAT is dysfunction.

    Remember the critical principle – People over process. You can easily self-organize into a dysfunctional team if you aren’t careful. Animal farm, Lord of the Flies, … Sometimes the enemy is us.

    Here is an idea… quit shoving it down their throat? Quit pretending you were first to the one true god and they are heathen if they do not succumb. Or do I need to recount memories of the unwelcome religious zealots. Telling people they are just wrong – oh yeah – that works 🙂

    People over process. (Maybe if I say it a few extra times, some will have a breakthrough.) You can not change people – they have to want it.

    I have been “right” many times… the smartest thing one early manager told me years ago – its not enough. If you can only convince the easy ones, maybe your argument is not compelling enough. Listening – being able to see the opposing viewpoint – make it about the ground you share: the product and the customers. Quit making it about them and you. Learn from each other – being superior is a laughable strategy.

  13. Yo September 9, 2010 at 7:49 am #

    Basically, software development is a team effort, as oppose to program development, which is an individual’s effort. So just like any other team activity, having a superstar on the team, that doesn’t understand that (s)he is part of a team can ruin the results. You see it in software development in the same way that it is seen in sports, orchestras or in our social life.

  14. Stefan September 9, 2010 at 5:05 pm #

    Well said!
    Your first few paragraphs are the perfect description for the company I’m currently working for (even if it’s somehow worse).

    “For you, I hope you can escape the nightmare and find a healthier organization”
    -> After trying to change something, thats exactly what I’m going to do. 2 weeks left…

  15. Dave Rooney September 10, 2010 at 4:05 pm #

    I started to comment, but it became too long and turned into a blog entry of its own!

    I do believe that this current backlash is multi-faceted, and personality types are part of the equation.

  16. ehendrickson September 10, 2010 at 6:48 pm #

    Awesome post. Commented.

  17. Jim Knowlton September 15, 2010 at 10:42 pm #


    This reminds me of a response from a developer when agile practices (specifically standups and pair programming) were introduced at a past employer:

    “If I liked being around people, I wouldn’t have become a programmer.”

  18. Introvert September 18, 2010 at 11:00 pm #

    “If I liked being around people, I wouldn’t have become a programmer.”

    Took the words right out of my mouth. Being an introvert, I can’t work or think when someone is looking over my shoulder, talking loudly, or coughing, and I feel drained after meetings. I’m definitely “most productive behind a closed door, headphones on”, not because I’m a “magician” or “hero”, but simply because I need personal space and privacy. Hell, I even hate public bathrooms. Is that because I’m a magician or a hero?

    You can read about Good Agile and Bad Agile here:
    “First, Bad Agile focuses on dates in the worst possible way: short cycles, quick deliverables, frequent estimates and re-estimates. The cycles can be anywhere from a month (which is probably tolerable) down to a day in the worst cases. It’s a nicely idealistic view of the world.
    In the real world, every single participant on a project is, as it turns out, a human being. We have up days and down days. Some days you have so much energy you feel you could code for 18 hours straight. Some days you have a ton of energy, but you just don’t feel like focusing on coding. Some days you’re just exhausted. Everyone has a biological clock and a a biorhythm that they have very little control over, and it’s likely to be phase-shifted from the team clock, if the team clock is ticking in days or half-weeks…”

  19. Nitin hatekar September 30, 2010 at 8:30 am #

    “Agile: frequent delivery of value at a sustainable pace while adapting to the changing needs of the business.”

    This is the most crisp description I have read of Agile since quite a few days.

  20. Software Testing October 5, 2010 at 4:59 am #

    Nice Article. I searched in google about Agile Testing I got your blog. Hereafter, I will come your blog frequently. So, please keep update it regularly.

  21. mrpinto October 19, 2010 at 9:09 pm #

    What about all the folks who talk about uninterrupted time, ramp-up and “flow”?

    Are they just malfunctioning, “introverted” (in this usage, apparently a euphemism for anti-social), poor-programming, hero-mantling team-killers?

    Unless the entire “bullpen” is working on the same thing, the folks “collaborating” on thing A are really just distracting the folks “collaborating” on thing B.

    My bullpen is frequently a scene of dueling pairs. Pair A is trying to work out a recently reported bug, pair B is trying to work out a new story. Both are on the list for the iteration. Pair A and B get louder and louder, trying to be hear each other over the other pair. When we’re working on things individually, we all have headphones to battle the discussions going on amongst the rest.

    I guess we’re all just anti-social misfits.

    I’m the only one whose headphones are noise-canceling. I also come to work about two hours early. I work 7-3 in an office that runs mostly 9-5. It’s hard to measure work, but on most days about half of what I’m going to do all day is finished in the first 2 hours.

    Clearly, I am the hero misfit.

    Still, I consider myself somewhat extroverted. I go out to lunch with my team. We meet socially outside of work hours. I know their significant others. I’ve been to their houses.

    I’m not sure what to do. I enjoy programming. I like my team. I love celebrating releases together. I like that our project is making money for my company, in which I hold stock. But my preference for peace and quiet when working on complicated software obviously means that I’m not a functional, team player. Should I just quit and take up a more anti-social vocation like blogging?

    Sarcasm aside, the desire for peace and quiet to think and produce code seems natural for a programmer. Collaboration and focus are both necessary, but the things that foster one can harm the other. Balance is perhaps more necessary than name-calling.

    In other words, if you want to take my noise-canceling headphones, you’ll have to fight me for them.

  22. Marc Thibault November 16, 2010 at 2:21 am #

    Proactive disclosure: I’m one of those who likes to sit in a darkened room, undisturbed, while I work my magic. But I’m definitely not an introvert.

    Two questions:

    After ten years, Agile should have matured. If it were versioned it would be around Rev.5(stable). Developers are expected to know and embrace it. The impact of this change for the better should include declining failure rates for software projects, but that hasn’t happened. Why not?

    In other high tech engineering environments–the people who design cars, bridges and windmills–Agile has not been adopted as an improvement over engineering tiger teams. Why not?

  23. Ruben Fragoso February 24, 2011 at 7:10 pm #

    I must say that this article was interesting, however, there something that I did not understood, you are basically saying, is that even if the developer did everything correctly, the code worked, it was brilliantly developed, commented, and fit the requirements that were asked and that person, actually understands even the business of the company that he works, still has to learn how to work in a team? if he did everything right, then what is to complain about?

    So far what I have noticed, was that agile is being used by people who by nature do no trust professional developers, and instead of taking a break to actually understand the business, are all the time disturbing the developer with self-doubt originated questions..

  24. qtrolazyg February 25, 2011 at 4:39 am #


  25. ehendrickson February 26, 2011 at 12:22 am #

    Yup. That’s what I’m saying.

    First, the probability that a developer *actually* did everything right working entirely in isolation is roughly 0. (Same for any other role working in isolation. Testers working in isolation waste massive amounts of time. Business stakeholders working in isolation dream up fantastical things that can never be built. Working in isolation is a recipe for waste and pain.)

    Second, even if by some miracle the project was small enough and the developer omniscient enough that they were able to succeed completely working in isolation, the probability that the work can be extended and built on by someone else long term is roughly 0.

    In short, software development is a team sport not an individual competition.

  26. simple country tech March 12, 2011 at 5:17 am #

    I sort of like this post, but it gets a bit extreme. I have worked in well done agile environments. Once even in a place where the dev manager convinced the business to put it all on hole while we practiced. That was nice, because we got to learn how to crawl before we had to start hoofing it again. But I didn’t like it simply because its exhausting to have to deal with people all day long. I have nothing to hide, I’m not an Introvert, I don’t want to be a magician, and integration and test on check-in tells me if I’ve bunged a spanner into the works. I just don’t like having to pay most of my attention to people all day instead of most of my attention planning my programming. I think that agile encourages people to jump right in instead of taking a day or two to plan. I deliver once a week like clockwork, with simultaneous work on quarterly big point releases. I spend the first two days of the week with a pencil and paper, thinking out how I’m going to do that weeks release and making sure that I understand clearly what the stakeholders want. I have never been allowed to do that in an agile environment. Invariably some bazooka is on me from minute one to start writing tests for code I’m not even convinced yet that I need to write, or someone else needs help with something, on and on all day long. I’ve had people trying to convince me that I don’t need to think it out before I start coding. “Just start writing tests and that will get you going”

    (sound of shirt rending)

    It’s ok to not like one technique of development without being a whackjob or anti-social. You might give us a wee bit o breathing room.

  27. Girish Sarwal July 11, 2011 at 5:50 am #

    Much agreed. Attitude matters more than knowhow. Everyone has their own ways of working. Through the 80-90s (when the “closed door programmer” grew up), planning and focus was a first class citizen maybe because software was expensive to change. Today, things are different and requirement change is the first class citizen…needs a tacit approach and higher acceptance, which Agile has been promising at.

    But I also feel its processes need to be made for people rather the other way round, and its important for people involved to know that most processes are made out of common sense. With Engineering, there are no silver bullets… everything needs a different treatment, even if there are, someone has made them after enough experience and intuitive sense, only attainable by exposure, team work, and lend-the-ear.

    And yes, I feel much of it comes from conscience than anything else, so attitude and conscience is what matters I feel, names don’t

  28. Anonymous July 21, 2011 at 1:47 pm #

    F*cking brilliant. Nuff said.

  29. Riaz October 10, 2011 at 12:05 pm #

    Holy SH!T!!

    I think looked deep into my soul and fixed a little part of me that was broken. I believe I am a result of a toxic environment. It is as if you always know what the right direction is, yet the ship is stuck in a whirlpool and it is only you that has realised it.

    I can’t believe I have only just found this blog. You are a very clear and concise author.

  30. John Quincy November 14, 2011 at 12:45 am #

    In general, most companies have been doing some sort of iterative development for decades — and quite successfully. I personally prefer that CIOs just continue with their current process and call it Agile, as the transformation costs, ongoing training costs, loss of productivity costs, and morale reduction costs for going to SCRUM are devastating to a company.

    All a CIO wants to do anyway is brag to his colleagues that his company is ‘agile’ — they truly don’t care what that means, as long as they can utter those two magical syllables.

    Take a peek at this video I came across… It is pretty funny and illustrates my point to some degree.


  31. Jordan January 10, 2012 at 6:25 am #

    You seem to be saying that people who need concentration are introverts, and introverts are bad since they don’t want to be interrupted.

    This makes little sense; even extroverts need concentration, and an open team room is anything but that.

    We need to provide more concentration space in Agile, and limit the amount of ad hoc communication.

    We especially need to stop disparaging people who have valid crticisms about various aspects as merely introverted sociopaths or unwilling-to-change heretics.

    A lot of life is about listening and understanding, not just denying and denigrating.

    And, we need to adapt to the individuals, not just impose a unifromity on everyone. That is silly. Give everyone the space they need, and the team will enjoy the benefits. Suffocate the individuals and the team will suffer.


  32. Jordan January 10, 2012 at 6:33 am #

    Also getting back to your “it’s a team sport” not an idividual competition.

    It isn’t an individual competition, but it’s the superstars on the team that most of the meaningful work done. The top 10% of programmers write 90% of the code, more or less. The rest of the team should be there to support the superstars, not drag them down to an “equal level”.

    If you have a Tebow, or a Michael Jordan, the team should be making sure that they have the space to work their magic. Telling Michael Jordan to stop hogging the ball (certainly when he was in his prime) would be stupid.

    Sure, if it’s a college basketball team of average players, what you are talking about might make sense, but real professional sports teams and real professional development teams aren’t like that.

    Nurture — not alienate — the superstars. Programming really is not a team effort — defining the requirements and priorities might be, but the programming itself is an individual effort, the results of which must be understanable to the rest of the team, yes, but handholding while writing code (pair programming) is just silliness masquerading as political correctness masquerading as business value.


  33. testobsessed January 10, 2012 at 5:16 pm #

    Hi Jordan,

    Thank you for commenting! I wonder if you’ve read another essay I wrote about team stars, “Beware the Hero”. It may offer some additional perspective.

    My experience with software development teams is that it really is a team sport, and that the whole is truly greater than the sum of the parts. Those people who are making sure that the superstars have the space to “work their magic” are magic themselves. And a manager who rewards stars out of proportion with others may find themselves with a team where individual competition and egos eclipse collaboration and results. I do believe in nurturing superstars…because I believe in nurturing everyone: giving everyone on the team the support, guidance, and resources they need to perform to the peak of their ability. And if that means a superstar’s feelings are bruised because they aren’t treated as sufficiently more special than everyone else? Then it suggests that superstar might want to make sure they’re really playing with the team and looking at the results of the whole game and not just their individual score.


  34. testobsessed January 10, 2012 at 5:44 pm #

    Hi Jordon,

    Thank you again for commenting. Apparently this essay touched a nerve for you.

    You might be surprised to learn that I am an introvert. Many people are. Because I am a public speaker, folks often assume I am an extrovert. But I’m not. I process information best when given time to think alone. I recharge by being alone. It takes a whole lot of alone time for me to be able to do public speaking and training.

    When I started pair programming in an open team room, I found it difficult. It’s draining. Working alone, I can be productive for 10 or more hours a day. Working in a team setting I am good for 8 hours tops. But after a few weeks of working with a high performing team in a truly Agile organization, I realized exactly how much more we were all getting done in those 8 hours than we would have if working for 10+ hours a day alone.

    There are some caveats, the most important of which is that the team room concept only works as long as everyone is working on the same thing.

    If the organization just shoves a bunch of people working on different things into a crowded, noisy open room, you’re right: the result will be that no one can concentrate and everyone will be miserable. I’ve seen that happen. But that’s not what the open team room concept is about. Rather, bunch-of-people-working-on-unrelated-stuff would be a good example of the fake agile phenomenon. And the resulting general misery and inability for anyone to concentrate would be a really good clue that the organization is doing it wrong.

    Doing it right is hard. As a consultant, I’ve seen a lot of organizations. Maybe half a dozen have done the team room concept really well. The rest might have mimicked the form, but they ended up with the kind of chaos you allude to because they failed to consider the various aspects of creating both a functional space and a situation where the team is in a position to take advantage of it. But those organizations that succeeded are seriously SERIOUSLY good and I would match them against a high functioning organization with individuals isolated in cubicles or offices any day.


  35. Mark Tomlinson January 10, 2012 at 6:42 pm #

    Fantastic post – which actually is relevant outside software development, testing, agile practices…to many other parts of life.

    My comment is that we should consider the individuals with borderline intellectual disability (or differences), who have been supported in the belief that their personality, skills and abilities practiced in isolation are so brilliant that the team should accommodate their peculiar limitations in favor of their technical results.

    When I worked at Microsoft, most employees had offices – with private space – so that engineers could “get into the tube” and crank out code. And the point was that some of those individuals had mild introversion, slight autism or even serious anti-social behaviors. As you suggest, we should be careful not to alienate those types of people – because they are well-meaning, hard-working and productive in the right context.

    The agile “culture” should be careful not to be too selective, lest we discriminate too much against certain valuable members of the team. It seems the original manifesto would promise the benefit of agility being increased flexibility in team structure, work habits and personnel.

  36. Jordan January 10, 2012 at 7:30 pm #


    First of all, thanks for your comments.

    Second of all, I take objection to the whole notion of “doing it right”, as if there is one right way, and that any pundit, yourself included, knows what it is for all projects.

    That is a dangerous form of arrogance found too often in this industry; the fact that people are even looking for a “one true right way” is silly.

    You may have things that have proven effective in some cases, then call them that, don’t have this attitude of “the right” way.

    Second, as you allude to, so called “agile” fails far more often in adoption than it succeeds.

    Therefore, the rare times that it succeeds could be called happenstance, luck, or serendipidity — which it most likely is.

    I go into more concrete details about all these aspects on my blog — feel free to give it a read.

    Finally in terms of war room or not, most companies don’t have the luxury of having both cubes and war rooms. If they move to a war room only model, they will sincerely regret it.

    I just wanted to add my $.02 saying that I agree with the many commenters here who disagree with this posting.


  37. Jordan January 11, 2012 at 8:08 pm #

    I guess I’d like to say one more thing and ask you, what is the value-add for the superstars to adopt the things you suggest?

    Effectively, the hero’s are irreplaceable; the rank and file are not.

    Sure it’s a team effort — but people are there to see Eric Clapton, for example. The keyboard player is important, but easily replaceable. Clapton is not. In fact, Clapton is the draw.

    So, you are saying, well, the band should all be treated equally, paid equally (a nice concept rarely found among touring bands).

    What is the advantage for the superstar to take this demotion? Agile wants to take away architects in general, and have everyone on an equal footing. Does that mean a pay raise for the rank and file? Or a pay cut for the Heros?

    Why should a Hero with decades of experience be treated equally to a fresher with 1 year experience? What is the advantage for the Hero to do this? I have never seen any stated.

    And further why should this even be done? This sees to be an effort to squeeze the team into a lowest common denominator status, and then, wherein is the desire to excel or exceed?

    It seems very odd and anti free market/capitalist. Maybe it is communist in nature — but I see that as being at odds with the Wester Economy and mindset.

    In capitalism, the ones with the skills, brains and work ethic are rewarded more than average people. Why turn this on it’s head in “agile”? I see no value add there other than to placate the “bruised egos” of the rank and file.

    Taken to it’s logical conclusion, this should be applied at all levels, so CEO’s should no longer receive 40x the pay of the rank and file. Why is this not a core foundation of agile as well, then, the excessive pay of the top ranks? Only architects and senior level engineers are singled out for Haircuts in agile?

    I go into this aspect on my blog posting “Scrum as the new Command and Control”


  38. Robert S. SFeir May 15, 2012 at 7:04 pm #

    Thank you for saying it and explaining it so eloquently. As programmers we’ve all our had our moments when we just wanted to be in that closet doing our own work, oblivious to the needs of the ‘idiots’. Yet thankfully the majority of us step out of that shell to move on and lead very successful projects using the agile philosophy and methodologies.


  39. Patrick Thompson November 26, 2012 at 10:15 pm #

    Great read, really appreciate your insight. I am working on a team right now that is trying to adopt agile and I am experiencing some of these frustrations.

  40. Jitendra February 6, 2013 at 9:50 am #

    Hi Elizabeth,

    It was tough to take this post as I am sort of an introvert too. However, there are times when you cannot do anything if there is lot of traffic around.

  41. Martin Hynie February 16, 2014 at 9:36 pm #

    Years later, your posts continue to provide me with excellent reading material to pass on to my team. If you ever feel you are running short on thank you’s, please give me a call. I will give you explicit examples of why I appreciate your contributions to our community.

  42. Vince Remile September 19, 2014 at 8:18 pm #

    “Actually, maybe you already had experienced Agile…”

    That is the most frustrating thing of all.

    In my experience, the best developers learn early to interact with the business and deliver quality and the best managers recognize what they have and stay out of the way.

    An “Agile Implementation” by “consultants” or “coaches” strips that away and shackles the best to the worst.

  43. Programmersguild October 8, 2014 at 8:36 pm #

    Scrum is micromanagement, not matter how you try to disguise it.
    If you think that programmers should be treated like assembly line workers, that’s because you never had to write code for a real business.

  44. J.M. November 21, 2014 at 5:55 pm #

    Ok, so I’m an introvert who likes to work my own hours and hate being trapped in the office like a caged tiger. Does that make me the anti-agile monster as described in your post? Just because someone works better in isolation doesn’t mean they can’t contribute to a team. Introverts just need to be handled in a different way. Email and instant messaging are enough to keep an introvert plugged in to what’s going on. We don’t all think we are Superman. We just know what environment allows us to reach are full potential. We have no problem reporting our progress and collaborating on issues. We just want to be able to focus.

    The bottom line is that everyone is different and it takes all kinds working together to successfully develop any type of large project. You need the introverted programmer for their expertise, the extrovert that works with the client, and the people in between that bring it altogether.

    The real problem is that “Agile” isn’t being implemented correctly. Large systems require careful planning and design. The lack of documentation makes it extremely painful for new team members to be effective and good luck trying to transition a large system built on Agile principles to another service provider.

  45. Mason May 23, 2015 at 4:32 am #

    If you’re using Agile, you’re building crap. No plan = no good.


  1. The Agile Acid Test « Test Obsessed - December 14, 2010

    […] Not surprisingly, that means few organizations are really getting the benefits of Agile. In the worst cases, “Agile” is resulting in worsening quality, increased pressure, and more burnout. People on those projects are reporting that Agile is ruining their lives. […]

  2. Testing the Limits With Elisabeth Hendrickson – Part I | Software Testing Blog - February 22, 2011

    […] You wrote a great blog post in which you referenced “the victims of fake Agile.” First off, have you considered starting an anonymous support group? If so, what are steps 1 […]

  3. links for 2011-02-25 | Michael Ong | On9 Systems - February 26, 2011

    […] Agile Backlash? Or Career Wakeup Call? « Test Obsessed (tags: agile career) […]

Leave a Reply