I'd like to rant a little bit on something that I find prevalent in the teams that I coach and in the classes that I teach. When I talk to people about scrum (and agility in general) I invariably hear things like "I'd like my teams to be more efficient," "we're using scrum so that will be more efficient," and of course, "we'll be more efficient with this process and save some money, right?"

One of the main myths of traditional project management relates to measurement precision. Traditional project managers have numerous statistical tools in their arsenal. Such measures as earned value or cost performance indicators etc. are touted as providing a precise scientific measure of how we’re doing. All of this points back to a Tayloristic view of software and product development.

One of the principle practices in Scrum (and in fact most if not all agile methods) is the use of “cross-functional” teams. Somewhat surprisingly there is often resistance at the team level to creating these cross-functional teams, but sometimes this is a result of misunderstanding what we mean when we say that a team is cross-functional.

When we are introducing Scrum to a new environment, we often get into debates, sometimes heated, with people who question the validity, truth and/or value of a particular agile or Scrum principle. My general feeling is that any time spent having a philosophical argument with a client/Product Owner is time not spent adding value.

Guided by a discussion on the Scrum Trainers list I just read Jeff Sutherland’s latest blog, Shock Therapy: Bootstrapping Hyperproductive Scrum, where he quotes the words of Scott Downey, the MySpace Scrum coach, describing his Scrum bootstrapping techniques.

On a recent scrum development thread about changing Scrum (here) Dave Barrett wrote:

“I think that [Agile Software Development with Scrum] is just as relevant today as it was when Ken wrote it. We still use 30 day Sprints, an Excel spreadsheet for burndown charts, track in hours and estimate in Ideal Developer days. And it works just fine thank you.

At a recent meeting of a Scrum users group in Portland, Oregon, the topic of release planning came up.

Management is demanding release dates a year out, but Scrum says not to do that because of the rapidly changing environment that is software development.

From time to time we see people complaining about Scrum and Agile being sold as a magic painless solution to all your problems. We can't seem to catch anyone in the act of making these claims.

So who's going around saying Scrum is a silver bullet, and that it's all you need? Ken Schwaber's not saying this; Danube isn't saying this; other Scrum trainers and coaches aren't saying this ... at least not when I'm around. We're all saying quite the opposite. I see more complaints about hype than actual hype.

I've had the great privilege of learning about Open Space meetings from one of the best practitioners in the business: Diana Larsen. One of the principles of Open Space meetings is that "whatever happens is the only thing that could have." Assuming that our Scrum team is working in good faith (which is to say, doing the best they possibly can), I believe that this Open Space principle is true for Sprints as well.