Reaching the unreachable

The other day, I ran across this blog post by Jeff Atwood in which he argues, essentially, that those who would benefit most from learning more about their profession (e.g., reading programming books or blogs, studying process methods, etc.) are most often precisely those who are least likely to seek out such education on their own.
At the end of the article, Jeff concludes, “All those incredibly detailed rules, guidelines, methodologies, and principles? YAGNI [You Aren’t Gonna Need It]. If it can’t be explained on a single double-spaced sheet of paper, it’s a waste of your time.”
This is where agile differs from other methodologies–and to a large degree is responsible for its success. You can get across the basics with four values, twelve principles based on those values and a handful of intentionally simple practices (e.g, scrum, XP).

Team liturgies

Over at the Agile Software Development blog, Janusz Gorycki reminds us that scrum activities–daily stand-up, planning, retrospectives–play an important role beyond the purported goal of each activity:

The quality of the team and the caliber of its members is more important than the efficiency of its processes – nothing controversial about this statement really, this fact has been well documented in some pretty classic books on team management (“Good To Great” by Jim Collins comes to mind). And the old fashioned rituals are crucial in maintaining the team spirit and identity. This is because people happen to be wired in such a way that it makes them feel safe and comfortable if they can devote some time every day to repeatable old habits. And teams become better integrated if they have some common habits that they care to repeat every day – as a team. Liturgies and rituals do matter a lot – and there is no reason for these rituals to be overly efficient. That’s not their purpose to be efficient.

I love it that he calls these scrum activities “liturgies.” As a church-goer, I think it’s an apt analogy. I recognize that there is indeed a certain value in just coming together with my fellow parishoners each week and at the very least, going through the motions together. Though with church, as with work, you need to try to keep the point of the ritual in mind.

Ends and means

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?”

The ten commandments of agile

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:

  1. The system analysts did a bad job of requirements elicitation,
  2. The business guys do not know their business or do not bother to explain things to the IT guys, or
  3. 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.

Agile and the Protestant reformation

I’ve already compared agile to Alcoholics Anonymous, so why not religion? Tom Grant draws an analogy between the timing of Luther’s demands that sparked the Protestant reformation and the timing of the rise of agile within software development:

Remember junior high school history class, when we heard that Luther’s protest conveniently occurred just when secular princes were looking for ways to gain independence from Rome? The Agile movement arrived when more was happening in the technology industry than just the disgust of developers with schedules in which no one believed, or projects that didn’t deliver what the customer wanted.

Tom’s blog post, and it got me thinking: if Luther had started the Reformation and agile, the Reformation might have looked quite different. Instead of nailing 95 theses to the door in Wittenberg, in his first iteration, Luther might have only demanded a handful of changes to the Catholic church.

Agile maturity

In an earlier post, I made reference to Alistair Cockburn’s application of Shu Ha Ri to agile adoption. This comment summarizes a session at Agile 2008 in which the participants broke this agile maturity scale down even further:

0- The Agile Convert attempts to understand and learn all the Practices.
1- The Agile Purist follows all the Practices (this is the evangelical recent agile convert).
2- The Agile Pragmatist starts to realize that not all practices work in all situations and pursues the Agile Principles molding the Practices to their specific environment.
3- The Agile Purist follows all the Principles.
4- The Agile Pragmatist starts to realize that not all Principles work in all situations and pursues the Agile Values molding the Practices and Principles to their specific environment.
5- The Agile Purist follows all the Values.
6- The Agile Pragmatist starts to realize that not all values work in all situations and pursues the ??? molding the practices to their specific environment.
7- The self-actualized agile follower realizes that Agile is the embodiment of some higher understanding that can be applied in part or whole to any environment to help deliver more value… forget the boundaries of values, principles, or practices… these are just simple mechanisms to enable the education of agile to others.

On this scale, I would rate myself about a 4, with quite a bit of 7 thinking thrown in.
Where do you stand on this scale?

Agile adoption cheat sheet?

Amr Elssamadisy, author of Agile Adoption Patterns, has published an ‘Agile Adoption Cheat Sheet‘ in InformIT in which he outlines the steps to take in order to adopt agile.
One thing strikes me right away about this article: it makes no mention of the agile manifesto or the agile manifesto’s principles. Perhaps the author assumes that the reader already understands these basics, but I don’t really see how an organization can adopt agile without starting with the manifesto and principles. As I have mentioned before, you can follow all the steps in this guide but still not be agile unless the entire organization understands and buys into the values and principles of the manifesto.
Update: Amr Elssamadisy, the author of the article, replies in the comments.

Update from the Agile 2008 conference

I’ve spent a lot of time in the Borland booth the last few days, explaining our new BMS software to passersby. It’s actually been a lot of fun, as I’ve had the opportunity to talk with lots of people about our own agile experiences at Borland.
The most interesting conversation was with an agile coach from Sweden. If I understood him correctly, he believes that scrum has reached the point of being just another buzzword, and that many organizations are pursuing it just for buzzword-compliance, not understanding the fundamentals and value of scrum. I’m sure there’s a certain amount of that, but I don’t think it’s widespread enough to warrant his sharp opinion.
He did raise interesting one point, though: fork out a couple thousand dollars, attend two days of training, and you, too, can call yourself a certified scrum master. He believes that scrum masters should have much more training than that. He said that the agile coaches he’s working with have developed a year-long process for learning how to facilitate agile.
This guy’s thoughts on what it takes to be a qualified scrum master meshes with a conversation I had yesterday with some of my Borland coworkers. One of them was suggesting that scrum masters could benefit from facilitator training since facilitation is an established discipline that’s very similar to the role of scrum master. I would love to get some facilitation training.

Greetings from Agile 2008

Unfortunately, I didn’t get to attend any conference sessions on Tuesday. Several Borland employees got hung up in Chicago due to bad weather, so I spent most of the day working the Borland booth. I plan to attend some sessions today.
Borland booth at Agile 2008