Don't be a Scrumbut.

But is it really OK to be a Scrumbut? Can the scrum process work if every one of the pieces of the methodology is not followed exactly?

Perhaps...

Scrum works best when all of its pieces are used in the process. It is unlikely that the full benefit of the agile methodology will benefit from an incomplete process. However, in the real world it is sometimes very difficult to get an organization to adopt each and every piece. I think however, that even the teams using incomplete scrum might still be able to get some value out of the pieces that are adopted. Sometimes being a Scrumbut is still better than floating in the barrel as it goes over the waterfall...

It's not a perfect world.
If you happen to be on a scrum team that really gets the idea of scrum and is able to make each of the pieces of scrum work for you, then I say you are a very lucky person indeed. Personally I have been on several teams this way in my career and I can say that there is no better way I've ever seen to develop software. But while the world is round, it isn't a perfect sphere. Sometimes things are a little bit off. Yet, I believe that things can still spin around and everything can still work, if there is a clear plan.

Why?
As a consultant, my first instinct is to look at the process being used and question everything. I ask people why things are the way they are. Especially when I see something that doesn't seem right to me, coming from a perfect scrum background. Sometimes it takes time for an organization to be able to trust a new process. Some organizations have to bite into something new in pieces rather than adopting a completely new process all at once. I don't like it... it's not the best way... but sometimes it's the ONLY way. Something is better than nothing - as long as it is adding value. That is the real test I think: does it enhance the value of the software delivery process?

Yellow Light
Caution. That is the word I use when I see Scrumbut in action. I am looking for signs of devolving process rather than evolving process. If a team has adopted scrum's tenet of documenting what is actually delivered rather than big documentation up front, but then really isn't getting the concept or delivering the documentation as required by the stakeholders, the it really isn't working and someone is going to be dissapointed. Dissapointed stakeholders can then poison the entire organizations' view of the scrum process, and that can be the last nail in the coffin. Caution I say - we don't want to let this happen.

Perfection vs. Good Enough
I strive for perfection in the process but it's really a very lofty goal. As a consultant though I have to realize that I am there to help improve the process, not get it to perfection. I need to look for the warning signs that might dissapoint stakeholders, and advise course corrections for these things when they come up. Practiality is essential in software delivery, even if imperfect in process. The iterative model should give value, even if each of the pieces of the process isn't followed completely.

So, don't be a Scrumbut. Unless you have to. then if you have to - make it work, and watch for the warning signs...