Book review: “Workout: Games, Tools & Practices to Engage People, Improve Work, and Delight Clients”

Book cover


The book “Workout: Games, Tools & Practices to Engage People, Improve Work, and Delight Clients” is Jurgen Appelo‘s third book. It’s like the second part of Management 3.0 which gives a different approach to management.
It focuses on management practices whereas Management 3.0 is more theoretical.

Although these kind of books aren’t my favorite, I decided to read it because his blog posts are very good and I frequently read them.

Good practices

In the author’s opinion, a good practice should:

  • engage people and their interactions.
  • enable people to improve the system.
  • help to delight all clients.

This is a good pattern to know when a manager is following a good practice or not. When you have doubts about whether a practice is good or bad these three points should help you.

The top 3, for me, were kudo box (, merit money ( and delegation boards (

I’m going to write just about kudo box and other different subject (the law of requisite variety) because I don’t want to write a long blog post but If you want to know more about these practices, in the links next to them you will find a lot of information.

Law of Requisite Variety

This law says “if a system is to be stable, the number of states of its control mechanism must be greater than or equal to the number of states in the system being controlled”.
This means that anything that controls a system must be at least as complex as the system being controlled.
Organizations are complex adaptative systems. Then, for example, a manager of a team in an organization should be as complex as the team who is managed. As you can image that’s a ridiculous statement. In simple terms, a manager can’t manage a group of people.

Kudo box

This practice consists of writing a letter to a colleague when she did something good for the team. All the letters are put in the kudo box and, for example, once a month the box is opened and all the letters are read aloud.
Each letter should focus on individual effort instead of outcome because a great outcome requires many individuals’ effort.


Despite the amount of pages, this book is easy to read. What I’m more impressed about is that it gave me a different point of view on management.

I’m not a big fan of managers or management but now I know that is because of all the bad practices that I’ve suffered in my career.
It also shows me that it’s possible to create an environment where people really want to work when we focus on the real important things (see good practices).

In short, if you have money buy this book as soon as possible or if you don’t have any money the book is free when you sign up here:

My first project with Scrum

Image from
Image from


I’ve been working on a new project for the last few months. I worked with two external developers on this project. One of them has experience as Scrum master so the team decided to use Scrum as the methodology in the project.
I’d read a lot about Scrum and I’d applied some practices in the past but I’d never used Scrum by the book.

In this blog I’ve written a summary about my experience using Scrum in a project that was built from scratch.

I’m not going to talk about the practices of Scrum, so if you want to know more, a good place is:

you can find there the official guide of Scrum in many languages.


  • Retrospectives really work. Every retro helped us to discover the problems in the sprint and to solve them. For example, part of the team didn’t work at the office and that caused communication problems. The communication improved thanks to the retros and the actions that we took in each one.
  • Team building. We spoke a lot, and because of all the meetings we knew each other and came together as a team. I was new in the company and I didn’t know my colleagues nor the external developers. I believe we made a good team in few months due to the scrum practices.
  • The product’s design is understood for each member of the team. In this case, sprint meetings allowed us to understand the whole design of the application. That could also improved the design because many decisions were taken together.



  • Scrum can be used as a tool for micromanaging the team. That could happen when dailies and retros are done in the wrong way. Dailies would just be about the status of each story and retros would just be about checking estimations in detail. It didn’t happen but I realized how a person could transform scrum into something ineffective.
  • Feedback in the last part of the project. We did an acceptance test after the development had finished where most of the company participated and we received a lot of feedback. I see this like a negative thing because we couldn’t transform the feedback into new features. Our sprints were two weeks long and the last day of each sprint we did a demo where all the people involved in the product attended, including the people who gave us feedback in the acceptance test.

I’d like to add that we could apply the use of Scrum better because, for example, we had to write documents and other tasks after the development had finished and they should have been included in the project.
Furthermore, our main problem was that we didn’t have a product owner and a colleague had to play that role. I believe the highest benefit of Scrum and other Agile methodologies is that the value is maximize and due to the fact that we didn’t have a proper product owner that benefits were decreased.

The next blog explains the meaning of value very well:

The same writer has just released a book with the title “the nature of software development” and is amazing. It has a little more than 100 pages that explains in the most clear way possible what software development is about. I’ve read it recently and it´s a really nice book.


I’m happy with the end result of the project although we could do it better . I love how Scrum practices allow us to improve the team performance and the development process.

Scrum doesn’t have development practices and I miss them because developing an incremental and iterative product without them is very hard. For example, TDD and continuous integration.
So, in regards to development practices XP is better than Scrum because it includes many practices for us, programmers.

* 22-06-2015 Solved grammar error