Agile Forest

Find your path to agility with Renee Troughton

Last week Assembla posted the 7 things they hate about Agile.  Here is my take on their seven things I hate about people that hate Agile:

1) My cultural norms are not your cultural norms

Apparently according to Assembla everyone that does Agile is old.  Damn I have been doing Agile since I was 27. Apparently that means I am old. I hate that cultural norms are flouted as if they apply worldwide. In the southern hemisphere those following Agile are more likely to be under 40 than over 40.

2) see point 1

Assembla says that Agile is stagnated. Again, just because it has in your country doesn’t mean it is a worldwide norm (see last blog). I agree there is a risk that people want to do and not be Agile, but that has nothing to do with stagnation. I have argued many times on this blog that Scrum is stagnant, I won’t dispute that, but Agile !=Scrum. What Assembla is ultimately saying is that people aren’t learning of other approaches other than Scrum. Is it because they don’t want to, because they see little value in anything else or is it ignorance? I don’t know the answer, maybe Assembla does. When I think of this point it makes me ponder on why we replaced Waterfall with Agile in the first place – was it not because Waterfall failed to evolve and address the problem we were having. Where is it written that Agile must or cannot evolve? We are the community. We are the ones that encourage it’s evolution or not.

3) People that don’t value values

Assembla says that the values in the manifesto aren’t applicable. The examples that they provided were all of manufacturing or command and control environments. Last time I looked Agile was being used for knowledge work not manufacturing. Also Agile methods were used in WWII – in war rooms – where knowledge and innovation were critical. I agree that shared goals are important. I agree that if you can deliver your work and not have to talk to a single person (or even a customer) then values are not important, but I don’t know of anyone in software development that can get away with that excuse these days. You have to have values and goals when doing knowledge work. I am not saying the manifesto is perfect, hell I am enjoying the MoreAgile manifesto these days, but that doesn’t mean all values are useless.

4) People who don’t understand how complex it is to change command and control behavioural patterns

Assembla says that they hate the Scrum Master role and believe that SMs don’t do anything and need to get a real job. As someone that spends a lot of their time trying to re-wire behaviour away from command and control to enable environments where teams are empowered and autonomous I find this frankly insulting. We are taught to respect elders as children, to not talk back to authoritarian figures. Throughout our childhood and schooling we are constantly re-enforced with command and control messaging. And yet we know through many studies that empowered and autonomous teams are more productive and innovative. The Scrum Master is there to break down the old patterns and enable the team to do their job without interruptions. This isn’t something that happens overnight, it takes months of re-enforcement for neurological pathways to re-assert themselves to be the prime pathway. Does this mean that a Scrum Master role is full time – no! They will be helping to deliver when they have free time. They are just a normal in the person in the team who has chosen to step up.

5) People who think that Agile means you have to estimate/People who think that Agile means you don’t have to estimate

Assembla says… actually I am not sure if they are for or against estimating from their comments. Estimation really depends on the environment that you are in, the governance and financial models applied to get work started. Ideally work would be incrementally funded. Ideally all work would be broken down into roughly the same size. In this ideal Agile world estimation is not required (assuming you understand your cycle time or throughput of work items over a defined duration). If you don’t live in this ideal world you might need to estimate – at best a rough idea of the size of the project based upon relativity to other similar sized projects, at worst so you know your velocity if using Iterations.

6) People who assume a practice is 100% applicable 100% of the time and that common sense has no place

Assembla says that pairing all the time is not valuable and just to pair reviews. For me pairing for reviews is worst case scenario, it is a lag identification of problems. Would I recommend pairing all of the time – hell no! But if it was complicated business logic or a new architectural framework being implemented then I would recommend upfront pairing.  Pairing is about quality, reducing rework, cross skilling and engagement.

7) People that think just because it is hard that you shouldn’t strive for it

Assembla goes into some points about Scrum and it’s poorly formed ideas. The first is about co-location. I am not sure exactly what problem Assembla has with being in a work environment that is fun (what people don’t enjoy an odd game of Foosball?!?). I agree that co-location is much harder to do these days, but does that mean you shouldn’t strive for it? There are mixed benefits in this field – co-location provides reduced costs to communication (Thomas Allen curve), but conversely co-location decreases engagement (by 0.2% assuming you are instead working from home, still the figure is fairly negligible).

The second point Assembla makes on this is that cross functional teams are unachievable. In large organisations maybe, smaller ones less so, it depends on your environment. Again it doesn’t mean you shouldn’t strive for it. A cross functional team in the long term is more productive. The purpose of a cross functional team isn’t to reserve talent (where did that one come from?).

The third point Assembla makes is in regards to capacity changing weekly. Discipline is hard. Yes unplanned things happen but onboarding/offboarding project team members every week is a severely dysfunctional Agile team and if this is the norm your organisation has serious problems regardless of Agile. This is why most Agile environments are shifting to product rather than project teams – that way the capacity and capability is always there.

The fourth point Assembla makes is that bugs will come up as you work and these impact your ability to deliver to a plan. Again discipline is hard. If you choose to use iterations, then understand your metrics of how much this is impacting you and add it into your planning process. Alternatively use an iterationless method and allow production defects to be handled as expedites. Or even better build quality in and don’t get bugs in production.


If Assembla is changing its developers every week, has bugs as a frequent occurrence found within production environments (hinting at  lack of automated testing coverage and quality testing), has developers incapable of widening their capabilities, teams that are stagnant, old, without values and breathing each day in an innovationless command and control environment I am really not sure that I would give them my business.

And Assembla – if your response to this conclusion is “we don’t use Agile” then I’ll add my #8 hate:

8) People that hate on Agile who don’t even do it.

23 thoughts on “7 things I hate about people that don’t know Agile

  1. Jordan says:

    Sayting that people who are crtiical of agile automatically “don’t know” it is a no true scotsman fallacy.

    “No true agilist” would….

    Although I thought his comment on old people was over the top, a little, there are a lot of exteremely aged people in agile.

    I pin this on the decline of their 401ks and being forced back into the job market even though they have no current programming skills… leading to the rise of the over 50 coaches that don’t program.

    Many former smalltalkers fall into this category.

    I think his comments on other areas are more appropriate


    1. I never said the first statement you are implying I did. I said that if they are arguing that they have never tried agile then they shouldn’t comment on it.

      The age thing is not a cultural norm here. True most of the founders are, but they aren’t here.

      1. Jordan says:

        So people who arent Iranian cant comment on iran and people who dont
        use cocaine cant say its bad?

        Sorry dont agree

      2. Agree to disagree on this then. I would not blog on car racing when I have never done it.

      3. Jordan says:

        That’s fine we can agree to disagree but I find it a dangerous trend.

        By extension, say some party invents methodology M1 and another invents M2.

        Then noone, has the ability comment on it, unless they have done M1 and/or M2 for a number of years.

        Two fallouts from that:

        1) Whoever started doing it first can run rampant over anyone with less experience and ignore their opininons

        2) People can invent their own metholodgies and then claim that noone can criticize it til they’ve done it forawhile.

        This happened with XP and Scrum, and much of agile, eliminating other people’s ability to comment since they haven’t done it.

        By extension, 3, if you (or anyone) is doing a new project, that noone has done before, then noone can say anything because they have no experience.

        This is such a self limiting, and insular, and damaging line of thought, that I find it hard that we disagree in this area.

        The CEO of Assembla is obviously a CEO of a successful company, and what he is saying is he gets success without agile, and doesn’t see the value in it. That’s fair.

        If you don’t like his opinons you don’t have to, but to say that they shouldn’t have a voice is backwards IMHO.


      4. Naturally every human being is allowed to express their opinions. I just find it personally frustrating when people do it based upon no experience in the area they are supplying their opinion on. Diversity can give a fresh perspective but that blog was ignorance not diversity.

    2. staf42 says:

      I, like Renee, feel that a response is required to the extremely over zealous rhetoric of Assembla. Given your intelligent arguments Jordan, I am surprised that you, or any of us are supporting an attack on a community based on their age. In my experience, just sometimes, wisdom comes with age.

      I think many of Andy Singleton’s points are highly stereotypical, inflammatory and ignorant. I am one part of an Agile movement that tries to do our best to think openly and improve and adapt. I do not meet any of his points and I like Renee, and I am sure many others, feel insulted by his bigotism.

      If Andy’s new agile at Assembla, called ”Scalable Agile”, is full of people who think like him, and spread bigotry, antagonism and hate. We are truly in trouble.



      1. Jordan says:

        I disagree. The agile community has demonstrated itself highly partisan.

        Check out this catalog off the ills of agile, that leaves out the age aspect.

      2. Jordan says:

        Additionally, as pointed out, many of the agile community engages in bigoted behavior as a routine matter, ignoring everything that the world has to say as if they are village idiots.

        The agile movement has been spreading bigotry and hate for a long time…. maybe not everyone but certainly a huge subset, probably a majority.

        So the agilists got a taste from Singleton? So what?

        The fact that a few people are open minded, like Renee, and possibly yourself, doesn’t mean the community as a whole is, and Singleton wasn’t writing about France or Australia or anywhere else.

        He’s writing about what goes on in the US.

  2. Jordan says:

    Also re stagnation the fact that official scrum has not changed much in 10 years is true; you’ve pointed it out may times on your blog

    1. Scrum != Agile
      I even stated in the post that I have called Scrum out many times as stagnant.

      1. Jordan says:

        Whats new in agile them? gamification?

      2. Gamification is an interest I have where we can learn more about working smarter.

        There are many other examples – ATDD, continuous delivery, continuous integration, lean startups, systemic flow mapping (just to name a few)

      3. I wish to add BDD, especially “BDD in the large” from Mr. Liz ( and his BDD turtorial slides in Slideshares.

  3. On estimation – breaking work down into roughly-same-size pieces _is_ estimation; you can’t do the breakdown without estimation.

    The five problems with estimation are:
    * when you do it too early, before you know enough to have confidence in the answer
    * when you don’t correct the estimates to reflect subsequent learnings
    * when you assume the estimates are going to be extremely reliable
    * when you punish people for taking too long – esp. when you _don’t_ punish them for being too fast!
    * when you think you’re estimating “how long will it take?” instead of “how hard is it to do?”
    * when you think you’ve identified all the work that’s going to need to be done

    Avoid those, keep your WIP limits to a reasonable level, and estimation turns out to be not-a-hard-problem. But you can’t do any form of Agile – especially not Kanban – without estimation.

    1. Hi Robert, I suspect we might be talking about different levels of estimation here.

      If all your work is roughly the same size with expected variability that is all the “estimation” you need. The other, and more common form of estimation, is planning poker with relative estimates.

  4. Ps Kim rightly has said to me that “hate” is a strong word and do I really mean it. The answer is no I don’t really hate people that hate Agile – in fact I appreciate a number of Agile dissidents because it helps me to question my beliefs and ensure that we stay focussed on the real bits that do provide value.

  5. Estimation is not the act of sticking a number on a piece of work – that’s the outcome. Estimation is the process of breaking work done into chunks small enough that you can put a number on it with a degree of confidence. Using roughly-equal-size chunks just means you only use one number.

    Let’s say a team has a feature that’s too big to estimate, so they start breaking it up. Using variable-size estimates, they will go to a certain level and then assign numbers – using tools such as planning poker. Using roughly-equal-size stories, they’ll start debating how many pieces to break the feature in to. Either way, at the end you can total up the number and call it an estimate for the feature.

    The roughly-equal-size approach is a key aspect of classic top-down-bottom-up estimation.

    1. Well put. I personally think of breaking work down and estimating as two different things but I can see your perspective.

      Reasoning for me – we break work down so that we can regularly demonstrate progress. We estimate do they we know how much we can do by when.

      1. The level that I personally break work down to – unit sizes of under 3 days (4 hours, if I’m going for the similarly-sized-pieces approach) – is too small to allow me to show progress effectively – at least that is my experience. Progress is measured in how well I’m delivering on the multi-day/week/month features that the customer originally asked for.

        What the break down allows me to assess is how well my prediction (“this is how much I think I can do in this time”) fits reality. But it is insufficient because there will be things that I missed in the breakdown.

        It’s the software equivalent of the Uncertainty Principle – I can either have stories on the board that reflect all the actual work, but I won’t be able to trust the estimates, or I can have stories that I know I can get done in the time allocated, but may not cover all the work that is going to be needed. (And that’s before going into the fun-and-games of variable availability and competing demands)

        I think which approach works best for you depends on the organisational culture of what happens when you find new work. Some places find it best to simply increase the estimates for the encompassing piece – others work best if they explicitly add a new block. I find the latter works particularly well when you’re trying to improve your ability to identify all the work, because it makes mistakes visible.

        Personally, I try the PHB approach and attempt to do both. 😉 At the release planning level I like to juggle stories which will have variable size (and tend to be measured in days/weeks/iterations). At the iteration planning level, I like to break those down into tasks, and I like my tasks to be doable between end-of-standup and going-to-lunch.

  6. I’m down. Good points as usual Renee.

    On another note, I met your other mate at Agile 2012. Good man. Hoping to jump on over to your land soon enough!

    1. Look forward to seeing you over here – make sure you stop into Brisbane to say hi. Come in June for Agile Aus?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: