Twenty years after the Agile Manifesto was first presented, the legendary Robert C. Martin ("Uncle Bob") reintroduces agile values and principles for a new generation of software developers. In this eagerly-awaited book, the best-selling author of The Clean Coder shows how to bring unprecedented levels of professionalism and discipline to agile development -- and thereby write far more effective, successful software. As with his other books, Martin's Clean Agile: Back to Basics doesn't merely present multiple choices and options, and say "use your best judgment": it tells you what choices to make, and why those choices are critical to your success. Writing in the agile context, Martin offers direct, no-nonsense answers to crucial questions like: How and why did Agile begin? What are the costs and benefits of Agile? What are the most effective practices of Agile Development? How should an Agile team be organized? What roles do programmers, testers, and managers play in an Agile team? What is the role of the Agile Coach? What about Agile for large projects? What kinds of projects benefit from Agile? Clean Agile: Back to Basics is essential reading for programmers, managers, testers, project managers and every software professional called upon to lead or participate in an agile project.
Robert Cecil Martin, commonly called Uncle Bob, is a software engineer, advocate of Agile development methods, and President of Object Mentor Inc. Martin and his team of software consultants use Object-Oriented Design, Patterns, UML, Agile Methodologies, and eXtreme Programming with worldwide clients.
He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.
This book talks about the history of Agile and, as the subtitle suggests, the basics of it. It also tries to bring some sanity to the subject. Great to see Bob’s perspective after 18 years of the Agile Summit in 2001. It was a pleasure for me to write the chapter on Software Craftsmanship and contribute to this book.
This book is not an introductory text. Indeed, it requires that you'd been in the software industry for the last years because it's a deep analysis of the Agile movement and how and why it was created, and how it has evolved and adopted by the teams and companies.
Robert Martin's vision is clear here. The Agile ideas were good. They tried to solve common problems that the development companies had all around the world. But since its release, the ideas and principles were turned into a completely different animal. And that's the impression of one of the Agile Manifesto authors.
If you read this book, you probably realize that you were already lived some of the situations described there. And probably, if you are in contact with the community, you were also read/heard about the problems of the Agile movement nowadays. I love the concepts and ideas that make Agile up, but as Robert Martin also thinks, this is a little out of control.
Agile became an industry, and now it looks like it's more important to have an extensive amount of badges and certifications, to know how to scale a thing that it's not intended to be done at scale, to not have agile practitioners but coaches that bring no real value (because they excel on the processes, but not in the engineering), or Jira haters, or... The list is very long for me. So, citing the book, "You might say that Agile has become something akin to a religion in the realm of software development".
So, I strongly recommend to read it, even if you agree or not with the ideas and conclusions. This book is a journey, from the problems that Agile tried to solve, passing into the solution proposed and how it's supposed to help and ending in what's the situation today.
It's good to be reminded what was Agile (is it a noun now?) all about in the beginning, before it became distorted beyond all recognition by the industry. The book should probably be obligatory for everyone working in IT. Although, I don't agree with everything, especially with the critique of Agile Lifecycle Management (ALM) systems and I don't think that implementation of the presented practices is as easy as Uncle Bob says. If it would be that easy, there wouldn't be so much struggle, especially in big organizations.
What I did like is how savage Uncle Bob is about Agile certification programs. Some quotes: "The Agile certifications that exists are complete joke and utter absurdity. (...)" "(...) For example, the fact that someone is certified a Scrum Master is worthless certification". Ouch.
This is that kind of book that you need to read ignoring the author that is not a good human being.
A summary of this book would be: read the Kent Beck's eXtreme Programming Explained and ignore all the Agile bullshit. And I agree with that part.
Some arguments ignores some situations that happens in a real software project (eg. how to handle when some developers leave the team or when we hire a new, not so experienced, developer to work in a already running project?).
There are some chapters written by guests and some of these chapters are pure crap trying to sell "coach certifications" and others are really good like the Craftsmanship chapter.
It is a quick reading and it would be a good book for non-devs understand some aspects of the Agile *Software* Development.
Gandrīz neticās, ka tas bija pirms 20 gadiem, bet es atceros to telpu un brīdi, kad pacēlu roku, atbildot uz jautājumu, kurš būtu gatavs pamēģināt šo jauno pieeju - agile. Kopš pirmā brīž tā man izklausījās dabiska, saprātīga un produktīva. Pro-duk-tī-va! Tikt līdz rezultātam visjēdzīgākajā, reālistiskjā veidā, izmantojot dabas dotos un izkoptos talantus un prasmes. Tā es kļuvu par convert un neesmu to nožēlojusi nevienu brīdi.
Šīs grāmatas pārlasīšana bija kā pārlasīt pirmā sludinātāja piezīmes par idejas dzīvi 20 gados, norādot uz pārpatumiem, atkārtojot būtību. Saskanīgi. Idejā, manī un praksē viss vēl joprojām sader bez mazākās pretrunas.
It is very interesting how we usually change the meaning of concepts over time and the original meaning is lost.
To recover the original meaning, it is necessary to have a context in which this concept was created and Uncle Bob is one of the best storytellers possible to do that job.
Because it is so short (and I think it could be even shorter), everyone involved with Agile should read it.
"Agile is a small discipline that helps small software teams manage small projects. But despite all that smallness, the implications and repercussions of Agile are enormous because all big projects are, after all, made from many small projects."
"What about Agile in the large? I don’t think there is such a thing. Organizing large teams is a matter of organizing them into small teams. Agile solves the problem for small software teams; the problem of organizing small teams into larger teams is a solved problem. Therefore, my answer to the question of Agile in the large is simply to organize your developers into small Agile teams, then use standard management and operations research techniques to manage those teams. You don’t need any other special rules."
A must-read for everyone involved on software engineering. Well, if you really want quality and functional software, whether you are an engineer or an executive. This book is an oasis of knowledge and principles in times like these when Agile is being totally misinterpreted by people who want to do old, unprofessional and ineffective management practices with new "agile" names, roles and complex "scaled" frameworks. It has tons of experience, results and skin in the game in form of sentences.
I'm a Robert C. Martin fan, but this book is the same content from videos and other presentations all over repeated again. There is nothing new. Maybe, for newcomers to the Uncle Bob world, it can be fun to read and they can be delighted by his pragmatism. However, nothing new in the shop. Maybe he could try with different content that we are not so used to from him such us functional programming, for example.
Vale para quem tem pouca experiência em atuar com métodos ágeis. Para quem já é experiente, não agrega muita coisa.
De certo modo achei um pouco decepcionante, rasa e vaga a opinião do autor sobre os métodos de agilidade em escala como SAFe e Less, que estão na moda. A opinião se resume a: métodos ágeis são para equipes pequenas, mas que o problema de gerenciar grandes equipes "já está resolvido", pois é só dividir uma equipe grande em várias pequenas. (Será?) Mas ele mesmo admite que não pesquisou a fundo o assunto (!!!), o que se enxerga claramente uma vez que ele nem se dá ao trabalho de explicar o que cada um desses métodos de agilidade em escala prega.
I always had a blurry picture of what Agile actually means, and why we practice it.
Well, not anymore.
If you and your teammates don't care about the following and you still think you are an "Agile" team, I have news for you: You are not! and if anyone tells you otherwise, watch out, because he is full of BS (:
These are just the technical practices of Agile. If you wanna know why these practices are key, you can read the book. This book is a history and review of Agile principles, disciplines, and its business, team, and technical practices.
It’s also a fresh perspective (revised edition) 20 years after Agile Manifesto was born and how was the adaptation in the industry so far.
I developed a more clear understanding of Agile as a way to make successful software development achievable in small teams.
Great read. I love Robert Martin's insights. He is truly a legend in the field.
It's for anyone who is a part of a software development team from Managers, QAs, Business Analysts, developers…
Um livro que precisava ter sido escrito uns 15 anos atrás! Alguns conteúdos são completamente dispensáveis, o que poderia tornar o livro ainda mais enxuto. Apesar disso, a riqueza de conteúdo que o autor conseguiu colocar em 200 páginas é algo que eu não via em um livro sobre o tema há muito tempo. É uma definição completa sobre o que é o desenvolvimento ágil de software, desassociando dele toda a bullshitagem da "cena ágil" atual.
This book was a mix of memory lane, tips and essays from others.
The preface explains that this is a small book because it solves a small problem. The author reminisces about the the Snowbird meeting and the start tho the agile manifesto. He talks about 4 agile frameworks. (It's been a while since I thought about XP).
I like that he asks you to count the number of computers in your life. (Did you remember to count things like your clock and DVR). It was fun hearing the origin of the term “checkout” for source code. (from checking out physical punch cards from the drawer).
There are many good examples and stories throughout. I liked “Who is training the new people? The people who made the mess in the first place”. The point that the outer circle of Scrum is a “highly efficient way to make a large mess.”
The last two chapters were essays written by others, but they fit well. We are currently on lockdown due to coronavirus, but I look forward to passing this book around when I see people again!
This is probably not a must-read, but still a very interesting, thoughtful and personal perspective on Agile. Martin brings the often forgotten developers side to the equation and strongly advertises software craftsmanship as a way to incorporate the often forgotten and ignored parts of agile (XP, TDD, Pair Programming, ...) into today’s organizations. With this the book is an important contribution to the history of agile!
It was... okay. I like the focus back to the roots, but dislike the criticism you feel throughout the book. Yes, there is a lot of criticism due to the industry, but this book does not help building bridges, but takes a high ground. Yet: I totally recommend the first half of the book about everything fundamental about Agile.
In my opinion this book is a worse summary of other classic development books (XP, Refactoring) mixed with some personal anecdotes from Uncle Bob. It contained a lot of the contents from XP but I liked the XP book way more.
I would say this book is an additional read and that there are better sources out there about Agile (even though Bob was one of the authors of the Agile Manifesto 😂).
Anyways there were some good chapters: Refactoring, TDD, Pair Programming, Simple Design are highly valuable practices in Agile Development Teams and it is conforming to read this again and again.
Wonderfully opinionated (and slightly grumpy) polemic on getting back to the basics of Agile software development. Worth the price of admission just for the extended rant about project deadlines: "What is the first thing you know about a project? Before you know the name of the project or any of the requirements, there is one piece of data that precedes all others. The Date, of course. And once The Date is chosen, The Date is frozen. There’s no point trying to negotiate The Date, because The Date was chosen for good business reasons. If The Date is September, it’s because there’s a trade show in September, or there’s a shareholders’ meeting in September, or our funding runs out in September. Whatever the reason, it’s a good business reason, and it’s not going to change just because some developers think they might not be able to make it." - so true. I was reading on the train and trying my best not to LOL.
Uważam, że ta książka powinna być jedną z podstawowych lektur osób zajmujących się wytwarzaniem oprogramowania (nie tylko dla programistów). Świetnie opisuje przyczynę powstania Agile i jakie problemy to pozwala rozwiązać. Obecnie chyba jest stosowany ze względu "bo inni tak robią" lub "jest popularny", a jednak nie zawsze jest wiadome jak to powinno zostać zaimplementowane w codziennej pracy. Jeśli ktoś już zna historię powstania lub zna metodyki z podobnymi prawami/regułami to zapewne niczego nowego nie odkryje po przeczytani tego tytułu. Jednak moim zdaniem czasem warto przypomnieć po co to wszystko zostało wymyślone.
Maybe an article would be more convenient way to share the content of this book but then again it depends on the audience. If you have <2 years of experience working in an Agile environment go on and read the whole thing, otherwise feel free to skim through it. I enjoyed the exposure of common misconceptions of Agile i.e. that you can't just apply the ceremonies without the technical processes (TDD, pair programming), and some insights around the actual roles of Product Owners and Scrum Masters.
A huge disappointment and easily the worst book from Uncle Bob. There is nothing in this book that wasn't already published; most of ideas are borrowed from Pragmatic Programmer. The chapter about agile coaches written by another guy, which contradicts the author's opinion, is totally out of place. The whole book can be three time shorter and still tell the same story.
Who am I to review a book by god himself. The book is a must read and the stories/eg are so relevant that for a person like me who has been working on "agile" projects, my emotions have swayed from smiles to ROFL to sending shivers down my spine. Its a classic.
The ‘Clean Agile’ is a worth reading book to learn the basics of Agile and tell us the story of the Agile Manifesto creation and of how it’s started and where it arrives today, especially the book's author (Robert Cecil Martin) is considered as one of the founders of the Agile Manifesto and he was on that Software Developers’ catch up or meeting in 2001.
The book reflects the author's opinion/view of agile definition as a small technique for small to medium-sized software teams to build small to medium-sized software projects. It shows how the agile approach is closely related to software development, as an example given in his book was that Agile produces data that can be used to know the effort made (Story Points) by the team after each Sprint/Iteration, and project managers can take advantage of the data and results produced by the agile project to know the strengths and weaknesses and move forward on how the team will achieve the project.
Some chapter of the book focuses on the small details of software development using the Agile approach and identifies some of the differences between agile approaches used until these days such as Scrum and Extreme Programming, which all assume to reach the one goal despite the different practices inside each.
Also, the book presents his view of the theories and the additions that have occurred to the Agile methodology, such as the appearance of job positions such as the Agile Coach and Scrum Master, and how he recommends to those who want to learn Agile and practice it as a curriculum during the extension of a university semester is better than taking training for two days and obtaining a certification that shows the person is certified ( the author disagree with last learning method as it seeks to support the career path more than the goal of learning and practice the Agile approach itself).
I think it is important to know the basics through this book and read the beginning story to realize what is happening these days of including the Agile as a buzzword in many projects and tasks that have nothing to do with the Agile itself, and I can see how is used in some organizations which claim that they used Agile even they suffer from problems resulting from the lack of a healthy and transparent environment that should increase the productivity, to the bureaucratic work processes that considered as an obstacle to applying the Agile approach.
A good book for developers. It tells what it means to be a professional developer.
We read through war stories which teach us principles, concepts and tips on how to stay on track during project development. Uncle Bob reminds us not to cut corners, not to ask for permission to work in a professional manner (ex to ask to set CI), to say early about the problems in the project... and the list goes on.
We learn about Agile fundamentals, why it was born, what problems was it addressing when it was created, what was its purpose. The author takes us through the birth of Agile Manifesto. A nostalgic read on how the movement started.
The book is packed with good developers practices. However, I think uncle misses a big part of Agile where IT meets businesses. There isn't much about extracting more value from the business, cooperation on design step, influence the shape of product from bottom up. I must give uncle credit for writing about the importance of communication, asking questions, telling about risks and early pointing out impossible deadlines, but in my opinion, the topic is only touched and could go much deeper, especially when we're talking about agile development.
Uncle Bob asks important questions about the future of Agile, where it is going. He is afraid that is diverging from developers. That fundamentals of agile have been forgotten and we should bring them back.
I especially recommend Clean Agile for developers who are struggling with deadlines, business people or staying assertive when code quality is on the line. Lots of real-life experiences inspiring how to act in those tough situations.