Scrum is a great methodology enabling greater flexibility and hence higher effectiveness in software development. However, when I heard about if for the first time from our Scrum Master, Maria I was quite sceptical. My first impression was that the whole thing is over complicated – all these meetings, roles, rules and techniques. C’mon, there must be a simpler way to do software …

After couple of sprints I realised that my objections were nothing more than a biased impression of the novice. You should treat scrum like a new board game – at the beginning rules may seem complicated but as you play more and more, the whole thing gets very natural. I found out that actually all the mysterious sounding meeting names – retrospectives, reviews or groomings – have a deeper sense and each of them plays an important role in making your team more agile.

Treat scrum like a new board game to learn – at the beginning rules may seem complicated but as you play more and more, the whole thing gets very natural.

I do not want to get into too much details of Scrum – there are many great tutorials for that online. In this post I will share with you couple of thoughts from our adventure of introducing Scrum to the organisation.

Daily Sprint

When one of our product teams heard about regular DAILY stand ups – they were totally against. They considered it to be just an additional unnecessary meeting and waste of precious time that they could spend on coding or photoshopping. Kudos for a hard-work attitude, but eventually it wasn’t the case.

After few days they realised that daily update in fact saves a lot of their time. Thanks to spending up to 15 min on updating each other about what happened, what’s going to happen and what’re the blockers, they didn’t have to spend three times more time sharing the same information informally – in the kitchen, open space or on Slack. By the way – it is even mathematically proven that the larger the team, the more you save thanks to such meetings (still keep your product teams as small as possible!) – see Richard Hackman’s formula describing relationship between number of communication links and team size.

Groomings and Reviews

What about other meetings?

Groomings  let team members prepare for next projects without interfering with their current projects. Many developers were delighted with the fact that they are able to learn more about next technology they will have to use in some reasonable advance.

Reviews help providing regular feedback from stakeholders to the team and motivate them to deliver some incremental improvement during each sprint. They work well regardless if there is something awesome to show or not.

Scrum Master

Another tricky thing about Scrum is probably the most ambiguous role in this methodology – Scrum Master. This person is around to make development process faster. S/he facilitates meetings and makes sure that everyone is well informed and has the same understanding of the process. Scrum Master makes sure that scrum meetings take place, everyone’s well prepared and conclusions are actionable.

Without this person in place I used to, as a product owner, cancel some of the regular meetings because there was something more critical or everyone was busy. Ultimately it made the team worse informed about what’s happening and required even more effort to handle. Do not do that. These meetings make sense and saves your time if done right.

Warning: Scrum Master who is overly dogmatic about Scrum and applies its rules without good understanding of the business / company process is likely to slow down the process and brings more confusion than value. Make sure that it doesn’t happen.

Product Owner

Relationship between Developmers Team and Product Owner is very interesting, yet challenging to be done right. I will cover it in a separate post…