The Decline and Fall of Agile
I’m a little behind the times in responding to this (the “blogosphere” moves so fast), but I wanted to address an article that James Shore wrote back in November about the decline and fall of agile.
He talks about how agile is failing us, but I think the real underlying problem is that teams are failing to understand agile. Perhaps that is a failing of agile, but I think it speaks more to how teams and companies choose to implement it. In particular, Mr. Shore makes a good point:
[Scrum] also has a few mechanical things about a monthly Sprint and daily Scrum. Trivial stuff compared to the rest. But guess which part people adopt? That’s right–Sprints and Scrums. Rapid cycles, but none of the good stuff that makes rapid cycles sustainable.
I see this every day in my own organization. Project management gets so hung up on sprints and burndown charts that the team focuses too much on trying to deliver rapidly, avoiding quality practices like pair programming, TDD, and others.
It is not a lost cause, though. For Scrum to succeed, you need to think about your projects from the bottom up rather than the top down. Top-down thinking is a result of project management trying to hold onto waterfall practices while paying lip service to agile practices. The sad part of this is that typically in these kinds of environments, the team consistently points out these problems in their sprint retrospectives, and yet has no or little power to do anything about it.
Project management has to buy into Scrum and embrace the hands-off part of the practice. Determine the product backlog and the release cycle, but leave everything else up to the team. In return, the team should focus on delivering quality over quantity, i.e. following best practices rather than “get ‘er done.” If quantity is becoming an issue (missed commitments, etc.), then the team needs to stop committing to too much and focus on ramping up, or the product owner needs to stop forcing the team to commit to the pace the product owner wants rather than what the team can deliver.
As a closer, I wanted to share a response to the article that one of my colleagues sent me:
An interesting article. Here is an odd thought that won’t seem related, but I think it is.
Over the course of the past week, whenever I had a little “down time” (i.e., while people were sleeping), I re-read Malcolm Gladwell’s book Blink: The Act of Thinking Without Thinking. In one of the chapters, Gladwell talks about Agile, he just doesn’t call it that. He speaks of the commonality between highly successful combat commanders, on-floor commodities traders, ER personnel, firefighters, Improv comedians, and basketball players. Every one of these domains has this thing in common: they are agile. Here are the two primary keys that Gladwell asserts contributes to their success. First, in each domain, there is agreement with the circumstances. As in systems/software development, when we are using Agile, we take things as they are – we don’t try to tell the customer what they want, we try to find out what they want. Second, in each domain, once the action starts, the players do not maintain rigid adherence to a scripted outcome (how “waterfall” is that?); instead, they respond in each moment, according to a very disciplined set of fundamentals. Players in each domain spend their “off-court” time practicing those fundamentals, honing their skills, sharpening their tools, so that when the moment to perform arrives, they are prepared to perform at their very best.
We could learn a lot from people in these different domains As Gladwell asserts, they are our soul-mates. Agile will never decline or fall. It is an adaptive way of life for any domain where rigidity leads to inevitable failure.
And my response:
An excellent observation… it is similar to one of my favorite metaphors for agile (from Ken Schwaber): driving a car. It’s something we do every day without realizing it, but it embodies agile: adapting to change. As you drive, you continually assess the state of the road around you, making adjustments as necessary… most of the time minor, but if you hit a major “block,” you might change your route completely.
When you realize how much “agile” there is in the world around us and in your everyday life, you really start to see the counter-intuitiveness of waterfall.
Heather,
I read the original a few weeks ago and was tempted to respond following an experience I had this year on a major integration project. Reading your article has prompted me again.
Driving is the perfect analogy not just because of the adaptation aspect. I think it’s also that before you learn, it seems so un-natural – but we adapt to this new domain very quickly – we go from walking and occasionally running relying on our legs and arms for balance to sitting in a machine with many instruments and controls and travelling as much as 10 times faster. Even a child of 3 is capable of this when they sit on a bike for the first time. We are built to be agile.
So why are most organisations unable to behave in this way? The major difference is that when we drive we’re on our own, but at work we are a team. When we’re driving and we have a nervous passenger on board our ability to be agile is interrupted and probably reduced by their begging you to “slow down” and “brake now” or quizzing whether you are in the right gear for the situation. This is what happens in a team – another aspect of our nature takes over – competition and innate mistrust.
So, agile is all about relationships – we all have it in us to be agile we just need to trust each other – look each other in the eye and say “lets do it”. In human nature the ability to create successful relationships around us is related to our maturity. Generally senior citizens are better at relationships than teenagers – however in the work place there are people at all levels at various degrees of maturity in relation to the job. But there is another problem humans are stubborn, and this is why they find it hard to mature – it requires effort to admit that you could make more balanced decisions, listen more, counsel more and basically “grow up”. Finally the aspect of human nature that prevents us from dealing with this is laziness. As well as simply not putting in the effort this also includes such things as being responsible, caring and co-operating.
Its not just the human that is agile – all of life is – capable even of adapting to the catastrophic change brought about by the KT boundary event that rid us of the dinosaurs.
For an organisation that’s struggling to be more agile – introducing scrum is not going to deal with these issues – but employing a life coach will. I firmly believe that there are fundamental aspects of team behaviour that need to be recognised and managed before introducing pure practice – to ensure its success.
I recently heard my peer in the UK operative of my major global corporate customer say that they were going to get more agile but they weren’t calling it agile. I’m looking forward to seeing what transpires here. This year we completed a major web integration project that was promoted as an agile project but ended up falling foul of all the usual traditional challenges of project (mis)management. I guess this is why they don’t like the “A” word any more but hopefully there will be someone who really knows what it means.
David McLean
16 Dec 08 at 4:27 am