Monday, 20 August 2012

SCRUM or SCRUMish?

Last week a bunch of us attended an external SCRUM training here in Gdansk. The main reason for me for participating was to systematize my Scrum knowledge. I already knew some basics but I don’t have any practical experience with real Scrum project. I’ve never worked on such in Kainos, although some of them “borrowed” some Scrum rules.

Except the basics, I was hoping to hear about real life examples and best practices. Also, I was keen to learn about biggest challenges when adopting Scrum.

Our trainer was a certified Scrum expert and practitioner. He claimed he has introduced SCRUM to his current company and they are successfully using it for all of their software development projects ever since. So he seemed to be the right person for the job.

Now to the actual training - it was a bit too theoretical for my liking. It consisted of a lot of SCRUM theory, charts and stats (over 200 slides if I recall correctly). Probably nothing that you wouldn’t find on the web though. In my opinion it lacked some practical exercises, workshops, detailed case studies, etc.

However, if something was unclear our trainer tried to explain it by providing examples from his personal experience as a Scrum Master. Multiple times he started explaining a concept with words "In my company we are doing it like this...". And this is actually what got me wondering, if a pure Scum is even possible.

Although the trainer was obviously a great Scrum enthusiast he admitted multiple times that very often they need to adjust the process, so it is actually not strictly following Scrum guidelines. As the main reason for that he named customer expectations and the market/economy factors. Some examples of this inconsistency would be:

  • not using unit tests because their client doesn’t want to pay for them
  • having some scrum team members only partially involved in the Sprint e.g. testers, graphic designers etc
Some of their adjustments I found justified (graphics involved only part time) and some not (lack of unit tests). However, I have no Scrum experience and only know some theory. If I were responsible for adapting Scrum in one of the projects how could I know which rules can I safely change? This is obviously a question of common sense, plus I could use experience of my colleges, but this still leaves me with some doubts. Is it still Scrum, or only Scrumish? I appreciate the flexibility coming from the "whatever works best" approach, but those rules were invented for a reason and there is a danger of me not seeing some hidden pitfalls.

Is there anybody out there who can say they participated in a pure SCRUM project and followed all the rules? I’m really interested if this is possible.

Or maybe you just treat SCRUM as a loose set of guidelines and you pick only the most valuable ones for you?

PS. The highlight of the training was when one of our Technical Architects commented the lack of unit testing in the projects led by our trainer with words that can be translated as: “That’s SO LAME!!!”. The comment was repeated later on multiple times by other attendees on other occasions. We all agreed it should belong to official SCRUM terminology ;)

No comments: