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.
posted on December 15th, 2008 at 2:01 pm
← Back to articles