It is true that it may be hard to draw exact lines. For example, if the ScrumMaster of a team changes the time box for the Daily Scrum from 15 minutes to 5 minutes, is it still Scrum? Or what about if the team decides to do Sprints that are five weeks long? Or what about two people on the team regularly switching into the ScrumMaster role? These questions are interesting for a methodologist (and maybe for an expert coach)… but are they really important for a team that is just starting out?

We know that the Agile Manifesto delineates some values and principles. Certainly if we compromise those, then we are not doing Scrum. Scrum also adds some important principles (e.g. Inspect and Adapt). If we break those, just as certainly we are not doing Scrum.

I think what is most interesting is to include in our thinking not just values, principles and rule, but also purpose. What is the purpose of Scrum? Is it a do-anything system for “Transforming the World of Work” or is it a framework for helping organizations create high-performance new product development teams? If the latter, then the rules of Scrum _must_ be extremely flexible. If the former, by virtue of being a much narrower purpose, then the rules of Scrum must also be much less flexible.

The problem that then faces us in the former case is that too much flexibility leads to meaninglessness, and, I would assert, uselessness. What is the “nail” of the hammer called Scrum?

Based on my observation (not a scientific study), organizations that try to apply Scrum beyond new product development find that it is a much weaker tool. They always get modest results. Organizations that apply Scrum to new product development might also get modest results, but sometimes they get truly amazing results. It is this potential for amazing results that seems to only exist in new product development that I hope we can strive for.

Is Scrum a proper name (or a brand)? Or is it just a concept? Personally, I would like Scrum to remain a definite thing that has a great deal of strength to transform specific situations, rather than it becoming weakened through too much flexibility.

So which one of those is “a hammer” and which ones are not? Don’t get me wrong – I’m clear on how ineffective “scrumbut” is. But I think it’s useful to view “scrumness” as a continuum. And like any continuum, it’s difficult to draw a hard line between when something is and when something isn’t. But to me, there’s room for processes with minor modifications to still be called Scrum.

Thanks for the comment!

It is very important with Commitment Velocity to keep lowering the number since we are trying to make _commitments_ not _averages_. If you took the average then the team would accomplish all its work 1/2 the time, and the other half would have work left over. If the team finishes it’s work in a Sprint early, then they are welcome to take on more work, but it does not count towards its Commitment Velocity.

Basically, with Commitment Velocity, we are trying to measure how much time the team needs to leave aside each Sprint for the unexpected.

I hope that helps explain!

Mishkin

One thing I don’t understand about Commitment Velocity: Is it true that the team has to drop it’s expected velocity to the amount of effort they made in the last iteration? I miss the possibility of raising the velocity. E.g.:

1st Sprint the team finished 200/240
2nd Sprint the team finished 190/200
3rd Sprint the team finished 210/190
4th Sprint the team finished 200/190
5th Sprint the team finished 220/190
…

Means, the team has to stay on 190 as the is the lowest number they made even if they continously deliverd more then this velocity???

However, when coaching organizations to use Scrum, or better still, to be agile, I have found that being dogmatic about Scrum or agile practices does not help. I often find that if the people can understand why the principles are in place then they can start applying practices and get better at them over time.

Agile practices are changing and new agile tools are developing and appearing all the time – change is constant, that is a fundamental fact of life in IT/software development and it is a good thing.

Is Scrum the perfect answer for new product development? Maybe but over time it will be challenged by other “tools” that may prove better. There are also many external factors that determine the appropriateness and utility of Scrum as a new product development tool that mean Scrum in its pure form might not be accepted therefore it is not the best tool.