Fixing your scrum

Practical Solutions to Common Scrum Problems – by Ryan Ripley and Todd Miller

This is a book intended for the Scrum Master but in my humble oppinion it should be read by everyone involved in anything Scrum related, because chances are quite high that if you are doing Scrum, then you are probably not.

This book gives the authors’ best shots at fixing common problems typically occuring in Scrum teams and their organization.

In general I think it’s a good book which dutyfully works through all parts of Scrum adressing particular problems which the authors have discovered through the years of being Scrum Masters. One caveat, though, is that the book was released – and therefore, of course written – before the current version of the Scrum Guide (https://scrumguides.org/scrum-guide.html). The astute reader will notice that some of the fixes to the problems might not be what the Scrum Guide itself dictates. Those solutions are therefore – per definition – not Scrum.

One chapter where this shines through is in the section “Trust is Missing” (Chapter 2). It is somewhat funny – and rather weird – that trust is not a Scrum Value. You could argue, of course, that team members naturally must trust each other for team work to actually work. But you could argue that about the other Scrum Values, as well. Not that I think that those five values are a bad choice, definitely not. But trust should have been there, too.

Chapter 3 goes in depth with the Scrum Values and – I think – does a markedly better job at describing them than the Scrum Guide does. Let’s take Focus, which the Scrum Guide describes so:

Their [the scrum team] primary focus is on the work of the Sprint to make the best possible progress toward these goals.

Fixing your Scrum describes it like this:

Focus allows us to do our very best. Valuing focus means that we give people the time they need to think about their work. After all, creativity is hard enough without being constantly interrupted. Allowing development team members to focus just on one product, the current sprint, and the current sprint goal gives them the best chance of succeeding. Encourage the product owner to focus on the future value of the product while you, the Scrum master, focus on upholding Scrum.

I really wish the Scrum Guide would be this detailed about the Scrum Values, because this actually makes sense. But the Scrum Guide is the one source of Scrum truth so you could probably not use the definition from Fixing your Scrum and still claim to be doing Scrum.

On it goes in chapter 4 about the Product Owner where there definitely are some sensible takeaways. It does state the being a Product Owner is a full-time job. And it also states that:

A development team that’s distracted by PO-type work is an impediment that you need to address.

Chapter 5 – The Product Backlog has a lot of gold nuggets, but one I really like is this:

Bottom line: The product backlog is the single source of truth for every kind of work in Scrum. There should only be one product owner and one product backlog on a product-development effort, regardless of the type of work or number of teams.

Chapter 6 – The Development Team about all the problems that can arise on a team that is not cross-functional, that is, the team does not together have the needed skills for creating finished work:

in Scrum, a development team needs to have all the skills necessary to create a done increment every sprint

There is so much more in this chapter, make sure you read it. Lots of common sense, even if you are on a team that is not doing Scrum. This is actually true for most parts of the book.

Chapter 7 is about the Scrum Master role. One interesting nit pick in this chapter is the discussion about whether a Scrum Master needs to have technical skills:

Being a Scrum master requires so many different skills that technical proficiency belongs near the bottom of the list of things to look for when evaluating candidates.

I personally think it’s a hard pill to swallow, but I get the intent behind it. Being a Scrum Master is about team dynamics, organizational issues and a lot of the softer, or even softest skills. And as with the Product Owner it is a full-time job:

Organizations that use a part-time Scrum master likely won’t realize the full value and potential of a high-performing Scrum team.

Then the book moves on to chapter 8 – about managing management, which takes a whole new set of skills. The whole chapter is great and I had a hard time to pick one essential quote, but ended up with this one:

Staying curious (by asking questions instead of passing judgment) is how you fulfill your role as a servant leader.

Servant leadership is nothing new, of course, and most definitely not a Scrum invention. Still, having anything called a leader in a team without hierarchies (according to the Scrum Guide) is an oxymoron.

Chapter 9 is about sprints and my personal guess (and it is nothing more than a guess) is that this is one of the most hard parts of Scrum for many teams. Scrum insists that you must have a production ready increment each sprint, but some tasks/jobs/pbis/stuff are so difficult to squash into a sprint, especially when a lot of setup is needed or when an architectural rewrite is needed. But Scrum insists, so you have to find a way.

Unsurprisingly the chapter really doesn’t offer much help on this. It is, after all, a book for Scrum Masters, who aren’t technical people and therefore cannot really help the team. Only demand that they deliver.

Chapter 10 is about Sprint Planning. An activity that can be both painful and exhilerating, although probably not at the same time. A useful quote here is:

A painful sprint planning event is a sign of an unrefined product backlog.

There is also serious and thorough talk about the Sprint Goal, which in Scrum is an essential part of a Sprint.

I will, though, offer the valuable quote about Sprint Planning:

The purpose of sprint planning isn’t to fill the development team’s “plate” so that the plate can be “cleared” during the sprint. Rather, sprint planning is meant to create a starting plan for the sprint which includes a sprint backlog, forecast, and a sprint goal. The plan that is created in sprint planning will change. The sprint backlog emerges: When complex work is started, additional work is found. The point at which a team knows finitely how long it will take to complete a PBI is when the PBI has been completed.

It is, of course, important to notice that the Sprint Goal is the important part of a sprint. The team may have additional PBIs on the Sprint Backlog but those additional PBIs are not that important, the Sprint Goal is.

Chapter 11 is about the Sprint Backlog. The core of the sprint machinery. Where all the work of a sprint is captured. Ideally, that is. The chaper is clearly written in pre-covid times, but that is what it is. There are some really good pointers in this chapter, and this is not the only one:

In Scrum, the development team commits to achieving the sprint goal. But given the complexity of the work that dev teams face, it’s impossible for them to commit to completing everything in the sprint backlog.

This is really important! The Sprint Goal surfaces here again as the most important in a sprint. All other PBIs are bonuses.

There are also a very good (and funny) note on estimation:

A Forecast: An estimate of how much total work exists in this sprint and the amount of work remaining. Scrum is agnostic on how you estimate work. You can use PBI counts, task counts, Fibonacci numbers, zebra stripes, or whatever.

Chapter 12 discusses The Daily. How it is usually a status meeting instead of an actual mini-planning for the day. The chapter has tips and tricks for how to coach out the more quiet team members and correspondingly how to quiet down the more outspoken members.

In chapter 13 the Definition of Done is put on the table. According to this chapter it is the development team that owns the definition, but the Scrum Guide states that it is the entire team. This chapter, too, suffers from the Scrum Master’s missing technical skills.

Chapter 14 is about the Sprint Review, which in my oppinion is inappropriately named, since the idea is that it is NOT a review, but rather a discussion between the team and the stakeholders about the project and how it should progress forward. The Sprint Review must include PO, the developers and the stakeholders and it must be a collaboration.

The chapter does have a very good suggestion for an agenda which will make the review into a colleborative session. Read it and weep!

It mentions the concept of “mob programming”, which I had never heard of before.

The final chapter – 15 – is about the Sprint Retrospective. Again the Scrum Master is on the home turf: team dynamics. The Scrum Master is held accountable for positive outcomes:

When used correctly, sprint retrospectives are a great tool to help keep your team moving forward in a positive way. It’s vital that they happen and are fruitful in outcomes that create solid improvements for the team. You, as a Scrum master, are accountable for making sure that happens.

I think this is – in general – a very good book. There are much more to it than mentioned above. And probably most teams – and most team members – can benefit from it. You cannot do it all at once, of course not. But focus on one Scrum Event/Role/Artifact at a time, read the corresponding chapter and make adjustments.

Review: Elemental Design Patterns

Jason McC. Smith has jotted down a few clever words, not so much about design patterns as about Elemental Design Patterns. There is quite a difference. If you haven’t read the original Design Patterns: Elements of Reusable Object-Oriented Software by the now so famous Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) you really should. Its an important book.

 

Elemental Design Patterns is an important book, too. It may, eventually, end up being just as famous and having even more influence on development of object oriented software. I hope it will.

 

What is it about? The GoF book was about abstractions that could be hard to recognize in software without knowing what to look for. And even then it could be hard if the software was not built from the ground up using Design Patterns. Jason McC. Smith realized this difficulty while building a system aimed at finding Design Patterns in software. He finally figured out that something more, ehm elemental, was needed. Hence, Elemental Design Patterns.

 

Elemental Design Patterns can be something as simple as a method call, but it is important to acknowledge that we are talking about concepts here. The patterns are language independent (although they obviously feel really at home in object oriented languages). The neat thing about these patterns are the fact that you can use them to reason about structure in software on a conceptual level and all the higher abstracted design patterns can be built from the elementals.

 

Elemental design can even be used to reason about refactoring of code, which is one of the reasons I predict it will have a great influence in the years to come.

 

I can’t say that I think the book is a light read. It is very well written, though, but if you are a stranger to sigma and rho-calculus (I am), you will likely gain something from reading Jason McC. Smiths dissertation about the subject. And you’ll probably like to read the most important reference: A Theory of Objects by Martín Abadi and Luca Cardelli.

 

I say: If you have the slightest interest in the theoretical foundation of software development you should read this book.