The title of the book and the author promise to finally give clarity to so many who misunderstand what Agile is all about. Such clarity is much-needed. The hope is for something properly argued and backed by evidence, research or at least experience as much as possible.
Overall impression: Clean Agile is not about the basics of agile since it is full of today's deprecated agile practices. It would be more basic without those practices. As the author acknowledges, the book is his memories, opinions, rantings, and ravings. For agile basics, look somewhere else.
The Preface is somewhat disappointing in the very first sentences: “This book is not a work of research…”. It feels like giving yourself a license to say incorrect things. I’m in doubt in which way to read the book, and whether to take anything seriously. So, I decided to take the book and its content seriously and disregard these first sentences.
The author mentions the “big teams” term several times. It is in the beginning not clear what exactly is considered “big teams”. Is it any kind of large group of people working on a single complex product regardless of how they are organized? That doesn’t seem to be the case since “many small teams doing small things” is ok. But I’m not sure what is “small things”. E.g. who makes sure that small things fit together? “Many collaborating teams” is mentioned further, so that seems to imply that small teams can together do big things. Unclear. This lack of clarity is surprising since the preference for small teams over big teams is the key idea behind the word “Agile”.
Chapter 1: Introduction to Agile It starts with his personal historic recollection. There are several incorrect references to names, papers, and dates. A reader is advised to not quote any of these before doing a proper check. Even recollection of gathering at Snowbird where the Agile Manifesto was created conflicts a bit with recollections from other participants. This is understandable considering how much time has passed and nobody made a detailed recording of what exactly was said or happened.
In the “Agile Overview” part, the author tells a hyperbolic story on how waterfall projects are organized with a strict distinction between different phases in order to bring a message across. After this story, a better way is explained. An iterative way. There is in this and previous part a lot of focus on the planning aspect of iterative development, in the context of doing “projects”.
Chapter: Reasons for Agile The author explains in a clear and practical way the reasoning and benefits of Agile, through many examples of the way of working and practices that accompany this way of working. The bill of rights for developer and customer is especially useful and clear. I do notice in this chapter apparent exclusion of product development system dynamics caused by the complicated structure of many roles. Those matters a lot since this can make or break a practice. An example: “QA should find no faults with the system.”. This is an oversimplification of the problem.
In this same chapter, there is a definition of customer. An example of what is understood as a customer, among others, is the project leader. It seems that whoever holds a budget or has a major influence on payment of developer is a customer. Also, it seems that the money aspect has a large significance in agile software development in the eyes of the author. The one who has authority on money needs to be pleased.
The author makes a remark about a Volkswagen developer a number of times. Yet again an example of not taking organizational and cultural aspects into consideration. After a bit of understanding of German engineering/corporate culture, one can discover that those developers didn’t decide to cheat the EPA test. They had a requirement and they delivered accordingly. A requirement was to make sure that the EPA test succeeds and the whole organizational system surrounding them creates this expectation. Just make sure EPA test succeeds! Most humans yield to such a system or at best warn management (which happened at VW). Only in exception, a developer can resist that. This will never change. The real problem is systemic, and cannot be solved by being a better developer but by changing the system. Making sure that cars produce very good results in a specific test situation is an established practice in the car industry. Nothing new about this. Diesel gate is just a more extreme manifestation.
Chapter: Becoming Agile The author doesn’t seem interested in problems of product development with many teams since the problem is “already solved” according to him. Solved a long time ago. 5000 years ago. For the author, the two problems are separate. Whether you do software development or anything else, how to organize many teams is unrelated to software. The view is astonishing. Especially considering it is purely an opinion and not backed by any further reasoning, research or evidence.
Chapter: Business Practices The author mentions agile practices that are either discarded nowadays or explained by the author, not as a practice is intended. By far the biggest issue is that iterative development seems to be intended for managers to better manage delivery. Iterative nature (feedback, inspecting and adapting, users involvement) is almost completely lacking in explanation. Though, there is just a general remark that feedback is important in chapter 6 (Becoming Agile). There are many statements such as this one: “The purpose of an iteration is to generate data for managers”. This thinking is manifested in the explanation of practices: - Iteration zero is mentioned but in community commonly considered a bad practice (phased development in disguise) - “The Demo” is used to make sure developers are working and not hiding things from “stakeholders” according to author - “In Scrum, the customer is called the Product Owner. This is the person (or group) who chooses stories, sets priorities, and provides immediate feedback.” is not correct.
There is a lot of good and clearly explained things in this book. All more technical practices are really nice to read. Unfortunately, the more author moves away from technical practices the more blurry, false or astonishingly illogical it becomes. So, considering a large amount of simplistic or outdated descriptions I’m not sure who should read this book. It only partially gives clarity on what agile basics really is.