Ken Schwaber just wrote a post on the ScrumDevelopment group in response to a thread about different types of Scrum and Lean processes.

Scrum is a very simple process for managing complex work. It has many areas in which it is quiet, such as engineering practices, planning and estimating approaches, risk management, and others because these are situational, dependent on who is using Scrum when. People will fill in these blanks and come up with a process or approach that helps them accomplish their results best, keeping in mind that Scrum will keep pointing out when they are deficient so they can continually improve their concocted process. To say there is a Scrum “A”, “B”, “C” or otherwise is to say that there are multiple foundations on which to build, when the base Scrum – described in the literature – is more than adequate. I believe that thinking this way will help us avoid the babble of OO in its early years, and also people who “modify” Scrum to remove its most important elements.

I think this summarises Scrum wonderfully well.  Scrum is, and always has been, about getting teams back to first principles in terms of software development and then working from up that point to find the right practices to get the best results.

There is no one-size-fits-all process for software development and anyone who says otherwise is probably trying to sell you something.