Clean Agile: Back to Basics (Robert C. Martin Series)

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 AgileIt 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 AgileThe 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 AgileThe 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 PracticesThe 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.

Great read for anyone who thinks Agile is a project management methodology. (Spoiler: it is not). Great reminder to programmers to embrace responsibility for the results of their work.The only thing I'd argue about is the author 's approach to acceptance testing. I believe the more practical and even more 'agile' way would be to let them emerge from implementation and subsequent approval by customer and then be automated instead of trying to automate in advance.

I've read every Uncle Bob book ... Clean Code being my favorite ... I am not sure this book would help you if you want to learn agile ... It's sorta outdated and opinionated ... If you are lost in a failed scrum org, then yes, this would help you breathe some hope into your lungsIf you are just starting head over XP Explained by Kent Beck and mix that with maybe Scrumban so you get a mix of Scrum and Kanban also try some Lean Startup by Eric Cries ... Most important than all that is to read a lot but use your head and adapt ... listen to your pain and don't push it too farCheers

Amazing book. The truth is that I expected a lot less from the book, but it actually surprised me a lot. From beginning to end the book looks for how to help you within each world present in computer science, looking for alternatives of clear and precise concepts to help you in this new concept that is Clean. Highly recommended and I hope to buy another book in the series.

I love reading and watching Uncle Bob. This book is Bob just flat setting the record straight on what Agile truly is and means. While I think the book went a little deep on Scrum and estimates (when we have, perhaps, uncovered better ways of working) , I still found myself literally standing and cheering in the other parts. The clear message of code quality and software craftsmanship being a "business problem" is a mandatory wake-up. Read this book. Then read it again. Then share it. We want our Agile back.

This is a concise book covering the essentials/principles leaving out the fluff. The author covers all foundations in a pure fashion which I love. I've been doing Agile since early 2k, but still managed to keep 9 Post-ITs in this book.

Usually we have a Scrum Certification and don’t know what we are certified on, this book show what it is all about clearly.

Great book on Agile! The overview of the concepts is very well written and the stories detailed in the chapters are unique and very personal. Read it in a week! Could not stop :)

Uncle Bob and friends provide a salutatory reminder of what Agile is all about. In the penultimate chapter, he gives space for a dissenting view about its applicability in teams of > ~10 a la John Fowles alternative ending to "The French Lieutenant's Woman".

Agile lost its meaning to the dogma that exists today in large organisations. Coming from an evangelist like uncle Bob this book is a great refreshers. I love the way he leads from the history and what was real driver at the time.

Je suis déjà un grand fan de Uncle Bob. J'ai dévoré ce livre durant un week-end. Toujours fidèle à son style, Uncle Bob ne tournera pas autour du pot. Vous aurez l'impression qu'Uncle Bob est venu espionner vos processus de travail pour vous dire à quel point on a l'impression qu'il parle de votre compagnie!Il décrit avec précision tous les problèmes d'aujourd'hui, les frustrations constantes que nous vivons comme développeurs.Trop souvent, les gens ne comprennent pas AGILE et leur conception est à des années lumières de ce que AGILE était au départ. Uncle Bob remet les pendules à l'heure, simplement, clairement et avec précision.Bravo!

Everybody in software development needs to read this book. Period. No matter if you are a developer, development manager, project manager, product manager or owner or project manager. I even think that Clean Agile is most valuable to anybody who is not a developer at all, as it brings an insight into how software development is meant to be, how processes and approaches should look like in a modern company producing software - and who isn't that nowadays? Go buy it, Clean Agile is ought to transform how you see software development.

I was looking for a book that was able to provide me what and why Agile was intended for and why we should be enthusiastic about it. Martin for sure is a great writer and thanks to its writing way it is able to enjoy while learning a lot of new things. Very useful also all the referees, for sure to be investigated.