James Shore, author of The Art of Agile Development, has a new blog post, The Decline and Fall of Agile, in which he declares that “the agile movement has been in decline for several years now,” and by “agile” he specifically means “scrum.” He writes:
There are a lot of teams right now failing with Agile. These teams are working in short cycles. The increased planning frequency has given them more control over their work and they’re discovering and fixing some problems. They feel good, and they really are seeing more success than they were before.
But they aren’t working in shared workspaces or emphasizing high-bandwidth communication. They’re don’t have on-site customers or work in cross-functional teams. They don’t even finish all of their stories by the end of each Sprint, let alone deliver releasable software, and they certainly don’t use good engineering practices.
These teams say they’re Agile, but they’re just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It’s the reward, not the method. These psuedo-Agile teams are having dessert every night and skipping their vegetables. By leaving out all the other stuff–the stuff that’s really Agile–they’re setting themselves up for rotten teeth, an oversized waistline, and ultimate failure. They feel good now, but it won’t last.
As I’ve said before, the thing that sets agile apart is that it is, at heart, a set of values and principles, not just a set of practices. Methods such as scrum or XP provide practices that have been demonstrated to support the agile principles. But unless you understand why you’re undertaking the practices, you’re setting yourself up for problems.
As agile gains wider acceptance and as organizations start to drive agile adoption from the top down, it’s inevitable that some groups will mistake the practices of scrum for a recipe for success. All we can do is continue to focus our education on the agile values and principles and ask people, “Why are you doing that?”
A new survey of CIOs found that “40% of CIOâ€™s reported a general indifference towards the quality of the software they produce.” Also see the blog post about the survey with some good comments. Interesting. Not surprising, but interesting.
Blogger Kishore Kumar, who apparently has no direct experience of agile, recently looked at the agile manifesto and its related principles of agile and concluded that agile is ‘the new religion‘ and that the agile principles constitute its twelve commandments.
Over at the Borland Agile Transformation blog, I wrote three blog posts in response to Mr. Kumar’s thoughts on the first ‘commandment’ (see here, here and here).
I thought I would move back to my blog for my thoughts on the second ‘commandment’: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Mr. Kishore lists three possible reasons why requirements change late in the process:
- The system analysts did a bad job of requirements elicitation,
- The business guys do not know their business or do not bother to explain things to the IT guys, or
- The business need itself changes frequently (i.e. competitive landscape changes frequently in an unpredictable fashion)
Mr. Kishore comments that while he has seen the first two happen, he has never encountered an example of the third, and spends the rest of his post explaining why.
But let’s look at the first two sources of changing requirements. Based on his wording, I have to assume that Mr. Kishore considers these to be problems with the process. Why should one adopt a methodology to deal with the results of these problems?
It is indeed a problem if, for instance, the business-oriented people don’t adequately communicate customer needs up front. But a conventional waterfall-type project doesn’t have any good mechanism to deal with such screw-ups. If such a SNAFU happens, then your project is delayed while you re-plan and re-work, or you take some other sort of shortcut in order to meet the schedule. As long as each step of the process goes according to plan, you’re good, but as soon as any of them encounters unexpected problems, you’re screwed.
But agile assumes that imperfection, not perfection, is the normal state of affairs. That’s the beauty of agile.