Review: “Scrum Shortcuts without Cutting Corners” by Ilan Goldstein

Photo by Kelly Sikkema on Unsplash

Out of curiosity, I decided to take an official test exam on knowledge of Scrum a few years back. The 70% outcome and my overall dissatisfaction with the way the engineering process was set up at Jetlore led me to review the parts of the Scrum process where I saw the majority of issues. Although there are a lot of great books that cover Scrum end to end over the course of hundreds of pages, I was hoping to find the practical tips for the common problem and as a result, came across “Scrum Shortcuts without Cutting Corners” by Ilan Goldstein.

Summary

Everyone knows about Agile processes but few read the Manifesto of Agile development (I didn’t until this book). I will provide it here to give the context.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Many times agile processes are being introduced with the focus on the left side only. However, it is an abuse of the manifesto because the items on the right are always required even in the limited capacity based on the project at hand. As a matter of fact, most of the agile teams that you will see around are “agile” only because they use sprints, some planning, and standups. Some of them do great work, a lot of them “make it work”.

Ilan addresses the Scrum antipatterns and how to add the elements from the right side of the Agile manifesto without bringing too much of bureaucracy. The book highlights the following antipatterns:

• test sprints: quality assurance should be an integral part of the development. However, there are a bunch of initial “functionality” sprints that focus purely on writing new features followed by a bunch of “catch-up” sprints to quality. Another option is when programmers and testers work in shifted sprints. Even though the teams use sprints, it is a waterfall process in the end.
• never-ending sprint zeros: the preliminary work drags and drags without having the proper structure and form and the actual sprints are being delayed
• random-sized sprints: adding extra days to the sprint in order to finish the work
• estimation isolation: senior developer estimates the tasks in isolation from the team. The team is doing the work so the whole team should be involved in the estimation.
• reliance on the spec: Communication is broken and the team only wants to build the things that are in the spec.
• poor scrum master selection: scrum master makes unilateral product or technical decisions, micromanages the assignments, and drives the team into overtime.

Each chapter of the book provides a set of shortcuts on how to properly tackle the common issues at different stages of the Scrum process. There are 30 shortcuts described in the book, three shortcuts per chapter. At the end of the chapter, there is a summary of the shortcuts and the main points.

For example, there are multiple different reports that one can generate in a project management tool. Monitoring and metrics are critical parts of any process. Ilan suggests to use the following four metrics:

• Sprint burndown — daily gauge for the Scrum team to help manage its workflow and track progress. The right definition of the “Done” state is critical to make that metric work or you end up with the burndown that only shows the progress at the end of the sprint.
• Enhanced release burndown — a signal that tells what the development team’s rate of progress is relative to the scope’s rate of change. If the scope’s rate of change is high, the project will be delayed even if the team shows a great velocity in the burndown.
• Sprint interference — a metric that provides visibility on the time spent handling historical sprint disruptions (non-sprint tasks). It helps to quantify the disruptions and identify the unavoidable descriptions (company meetings, emergencies) vs avoidable impediments (fixing inadequate equipment, build server, test environment). However, it requires discipline and tooling support to log non-sprint related tasks on a regular basis.
• Remedial focus — a metric that monitors the fluctuations in product quality by measuring the percentage of each sprint that is spent working on bugs as opposed to new functional requirements.

Overall, the whole book is the summarization of the author’s experience of what works and what doesn’t when teams embrace the Scrum process. It is very practical and pragmatic.

My experience

Teams distributed across multiple timezones pose a great challenge at running effectively the critical parts of the process such as backlog grooming, planning, and retrospectives due to little time overlap that works for everyone. Even if the team finds that overlap, it usually requires one part of the team to stay late in the evening when the productivity is low and brainstorming is the least exciting part to finish the day. That reflects in the quality of the meetings. Co-locating teams is definitely a good solution but it requires a Scrum master (EM) to be in the same timezone with the team which is not always possible. If there was no option to assign a Scrum Master locally, we let the team self-organize and run the grooming/estimation sessions at their convenience the day before and sync up with the Scrum Master on the priorities and open questions when the bulk of the work was taken care of.

Another interesting observation is that remote teams tend to use standups for discussions beyond the scope of the meeting. So the standup ends up as a lengthy 30 minutes roll call. One of the reasons is the lack of face-to-face interactions. Keeping the communications only in Slack is definitely efficient but it removes the bonding experience that happens when people work in the same room. That brings the urgency to address it in COVID-19 world where everyone is forced to work from home. Establishing donut meetings (ideally via a tool), encouraging brown-bag sessions, and bringing the team together for a meetup helps to build good communication channels within the remote team.

Lastly, it is hard to plan the sprint when you have customer-specific work that can come at any point in time in the sprint and bring the havoc to a nicely working process. We took that work out into a separate Kanban project and spent additional time with our customer success team to manage the right capacity for the sprints before the planning sessions.

To conclude, there is always a hope that there is one book on the topic that will give you all the answers. My favorite part of any book is the prologue that outlines how the book can teach the new skills and what superpowers will be given by the end of it. The “Scrum Shortcuts without Cutting Corners” provides a lot of interesting, practical ideas but I didn’t find all the answers there. It gave a lot of good pointers that helped to better focus the search online and be more specific in the next selection of the books (I ended up buying two more books).

Verdict

Recommended for engineering managers as a quick reference guide to the common problems.