I took my ScrumMaster course three weeks ago and had the honour to take it with Jeff Sutherland as our teacher. This course was very insightful – a pity that it was so short! So I guess 90% of my learnings are hidden in the slides and in the back of my mind. But I’d like to write down and share with you some of the major takeaways.

What it is all about

Scrum is like a bootstrap program in a computer (BIOS). When you start Scrum it seems all chaotic (and it is). But by self-organizing and applying the rules it improves massively. However, if you change a bit in the bootstrap program, the computer does not work anymore.

The setup of Scrum aims in making an average team a very high-performing team. If the velocity of the team does not increase steadly throughout the sprints, that indicates that Scrum was not fully implemented.

According to Jeff, many Scrum teams have improved their performance by about 50%, which is fine. But it is not what Scrum was designed for. If your performance does not improve by about 300-400% after introducing Scrum, you are not implementing it right.

Both Wikispeed and Toyota can build a new car prototype every single week – they are both applying Scrum.

Steadily improving team performance

There are a few things that have proven to heavily increase performance:

• Introducing (and sticking to) a proper Definition of Done (DoD) can double your velocity.
  (DoD defines criteria that have to be fulfilled by a freshly implemented backlog item to be considered “done”)
• Introducing a proper Definition of Ready can double your velocity, too (resulting in a factor of 4 with the DoD)
  (DoR defines criteria that have to be fullfilled by a new backlog item before it can be taken into a sprint, e.g.: “Must follow I.N.V.E.S.T. criteria” + “Most of the team understand the item” + “The team has an initial idea for the architecture”)
• Morale is a performance multiplier. The PO is critical to motivate the team with the project vision.

Here are a few performance killers.

• The biggest waste in software development is incompleted work being taken over to the next sprint (not tested, technical debt…)
• If you test a feature in the subsequent sprint which would have taken 1h to be tested in the current sprint, it can potentially take up to 24h instead.
• “At midnight a bug turns into a feature” – cited by Jeff, unfortunately I am not able to find the original on google. If you find a bug (originating from the current sprint’s development), fix it immediately or it will we cost you a lot more. A bug not fixed within 9 hours is a good indication for the ScrumMaster that there is an impediment.

Roles and Meetings

Some new things I learnt about Scrum roles and meetings.

ScrumMaster

• It is the ScrumMaster’s responsibility to maximize the team’s performance.
• This means, the ScrumMaster is not simply required to teach the team how to do Scrum (I heard people say that experienced teams don’t need a ScrumMaster because they know how to do Scrum). The ScrumMaster’s duty is that the team performance improves in every Sprint.
• If the ScrumMaster participates in programming, he adds some value but loses focus on improving the team’s performance.

Product Owner

• The Product Owner (mainly) definies the Definition of Done! (I was thinking that the team does it.)
• The PO must promote the vision of the project to motivate the team – Morale is a performance booster.
• The PO plans the releases and sets either their scope or their date.
• The PO (or someone from the PO team) must do the final acceptance test. Only he can move a backlog item to done.

Retrospective

• The goal of the retrospective is to increase velocity. If velocity is not measured and inspected, the team cannot judge whether it improved over the last sprints. This is the main point of using story points for estimating user stories!
• Only one action should result from a retrospective – only change one thing per sprint, but focus on really doing it.

Backlog refinement

• It has proven useful to have a regular meeting for refining the top backlog items and make them “ready” according to the DoR – for example twice a week, discussing one or two stories each time.
• It is not necessary that the whole backlog be estimated. Only estimate as many stories as are required by the Product Owner for release planning (and of course any item that will go into the next sprint).

Release Planning

• By estimating the business value of each backlog item and ordering them properly, the items build a continuously increasing value-over-effort curve that starts off very steep.
• The PO can maximize the value of the first release by planning it at the point where the curve turns from steep to flat.
• The remaining backlog items sum up to only little value added with much effort. This is the value that would be added if the project was planned and executed as a whole.
• The feedback from the first release enables the PO to create, modify and re-estimate items, resulting in a much greater value for the second release (and any subsequent releases equally).

Testing and Testers

• Anybody can test – except the developer of the feature.
• Final testing must be done by the PO (or anybody from his PO team)
• Testing should not be made a state (“todo – in progress – testing – done”). Better make it a task.