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.