Again and again I see the expression “ScrumBut” [1] used as a running gag among the Scrum community. ScrumBut means the excuse Scrum teams use why they don’t fully comply to the Scrum specifications. “We are doing Scrum but …”. The cause of this phenomenon seems to be the “We suck less” mentality in some companies. [2]

Generally there’s nothing wrong with adapting the Scrum method according to your companies needs and structures, as long productivity and profitability are the main focus. Bending Scrum rules for the sake of keeping obsolete structures in place doesn’t seem to be such a good idea. Especially because Scrum is predestined to identitfy bottlenecks and the cause for suboptimal productivity.

So, to transform a running gag into a valuable tool, ask yourself in what respect, if any, your Scrum team or your company deviates from the recommended Scrum method.

Are there real causes for this deviation? Or is it just because “that’s the way it is”? Do you have to consider facts that are more important than productivity?

Which causes for deviations are ok for you and which are not?

[1] http://blogs.msdn.com/ericgu/archive/2006/10/13/scrumbut.aspx

[2] http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=15032