Elephant carpaccio for SCRUM Masters

Sergey Dmitriev

This week I attended a two day SCRUM Master course to learn more about the methodology we use in the development of SESAM - the learning management system (LMS) at NKI Nettstudier. The course was lead by Sergey Dmitriev (picture below), an inspiring and knowledgable coach, moderator and teacher from www.agile42.no.

Here are some of my reflections after the course:

SCRUM adheres to the Manifesto for Agile Software Development and perceives large projects as Elephant carpaccio.

The Wikipedia definition of SCRUM states that: SCRUM is an iterative, incremental framework for project management often seen in agile software development.

SCRUM argues that projects should be more flexible in scope, since traditional projects don't use a lot of the functionality that initially was built into the project scope. Therefore, it is wiser to involve the costumer in the development process, show incremental results and adjust the scope along the process.

The SCRUM process is based on these major elements: Product Backlog (often an Excel Sheet with development projects and ideas), Sprint Backlog, Sprint Cycles and a Working Increment of the system.

There are three core roles: The Product Owner (PO), the SCRUM Master (SM) and the Team. The PO is really dedicated to the project, develops the product backlog, initiates the sprint backlog and is typically involved with the team an average of 3 hours a day. The PO contributions are crucial for the project, and the PO is the one to blame if a sprint is unsuccessful. The SM works as a team facilitator and becomes less important as the team becomes more skilled in the SCRUM methodology. The team ideally consists of 5-9 people and include those who are responsible for testing.

A project consists of a number of sprints, and the work is organized in sprints. Each sprint is typically 1-4 weeks in which typically 10-12 tasks are included. It could be wise to go for equal length sprints to establish a sustainable pace.

The tasks are moved from To do, via In progress to Done as the work progresses. There are hosts of IT-tools that could be used to support SCRUM (Jira, Enterprise Arcitect etc.), but wall charts have proven to be very effective and was recommended strongly. The pictures below illustrates wall charts of our two day course as a Sprint.

Each sprint has dedicated meetings. The PO, the SM and the team take part in the following sequence of meetings: Sprint Planning (one day), Grooming (three hour meetings each week) and Sprint Review/Retrospective (one day). In between these meetings, the Team should not be disturbed by the PO. The team should also have 15-minutes Daily SCRUM meetings.

A Sprint needs a Definition of Done, and the roles need to agree on a common and clear definition of done. When a sprint is done, the updates are typically released to the users. However, modern infrastructure with clusters of test and production servers allows more flexible release schemes, and the trend moves toward more frequent releases. It was argued that Facebook has a new release every 9th second, and that small evolutionary releases are safer than larger revolutionary releases.

Estimating developing time is not a major focus in SCRUM. Good teams don't spend much time on estimation. The tasks should become more detailed as they move toward the top of the product backlog and into the sprint backlog. It is a waste of time to make detailed specifications for tasks months and years ahead. So typically, tasks starts as Themes, are later broken up in Epics, then user Stories, and finally Tasks on the Sprint log. A typical task is less than 8 hours effective work.

Finally, I hope you enjoyed the first slices of my SCRUM Elephant Carpaccio.