Micro Book Review: Agile Retrospectives, making good teams great

Title: Agile Retrospectives, making good teams great
Author: Esther Derby / Diana Larsen
Pages: 165

What the book is about
The book is about leading retrospectives. Retrospectives came into fashion with agile software development, especially Scrum has retrospectives every sprint. The beginning of the book motivates retrospectives, explains them, shows how to lead them and establishes the concept of phases: set the stage, gather data, generate insights, decide what to do, close the retrospective. The second part explains detailed several activities you can use in each phase. A description is structured like the famous design pattern book: Purpose, Time needed, Description, Steps, Materials and Preperation and Examples.

What I've learned from the book

  • Retrospectives have several phases: set the stage, gather data, generate insights, decide what to do, close the retrospective
  • There are many activities for retrospectives, you should change activities from time to time
  • Use an activity like"appraisals" for closing a retrospective

Should you buy this book?
Yes, highly recommended

Who should buy the book

  • Every ScrumMaster or Iteration Manager
  • Everyone who leads retrospectives

Book bought by myself due to a mentioning on Twitter.

I've chosen the micro review format because it lends itself to be used as a future micro format and I like short reviews myself. You can read the table of contents elsewhere, I don't like it when reviews iterate the content.

Scrum is not about engineering practices

Scrum is not about engineering practices - which is a good thing. Martin Fowler writes:

They adopt the Scrum practices, and maybe even the principles
After a while progress is slow because the code base is a mess

and connects Scrum failure to missing engineering practices. This completely misses the point. Scrum is not about engineering practices, it's about management.

Engineering practices are a responsibility of the team. Scrum creates self organized teams. They organize themselves, they organize their quality. They organize their tools. They organize their engineering practices (TDD, pair programming). Why? Because they are responsible for delivering. No one else is.

Craftsmanship and level of done

Often quality and craftsmanship are organized by a level of done agreement in the team which describes what a team considers when code is done. This can include

  • Documentation / JavaDoc
  • Functional tests
  • Unit tests
  • Bug free
  • Refactored, maintainable code
  • Reviewed code

What about technical debt? Technical debt is not professional. Seeing an ice berg and keeping a crash course is not professional. With the right level of done there will be no technical debt.

Scrum helps with good engineering practices

Concerning Marting Fowlers comments Dean Wampler twitters:

His comments match my experience at client sites. Teams using Scrum w/out the XP prog. practices don't work long-term.

Not very insightful it says: developers who do not use professional practices will fail. Of course they fail, but they fail independently of the process you use.

The main difference to classic project management is that developers have the freedom to define their level of done and the amount of work they do. Developers define what stories they work on in each sprint, management doesn't set a (unrealistic) finishing date as often happens in classical software projects.

Is there too much quality? Doesn't the product owner care if the team takes "too much" time for quality? The product owner is entitled to two things:

  • Story estimates
  • Shippable products
  • Professional developers

The product owner is not entitled to speed. Scrum sets resources and time in the Iron Triangle and let's developers decide about scope. Speed is scope / time and is an output variable of the team, not an input variable. If she thinks the velocity of the team is too low, talk to the ScrumMaster and remove impediments. But engineering practices should never be dropped. Other crafts will never drop theirs. Ask a doctor to drop sterilizing to gain speed. Ask a banker to drop double-entry bookkeeping. They won't. Neither should developers drop theirs [1].

[1] This could mean developers need to be trained to be professionals. But a company needs to teach professionalism to developers independently of what process it uses. If you do not have skilled, professional developers you're doomed and no process will help you.