| Title | : | Clean Agile: Back to Basics |
| Author | : | |
| Rating | : | |
| ISBN | : | 0135781868 |
| ISBN-10 | : | 9780135781869 |
| Language | : | English |
| Format Type | : | Paperback |
| Number of Pages | : | 240 |
| Publication | : | First published January 1, 2019 |
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.
Clean Agile: Back to Basics Reviews
-
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.
-
Great back-to-basics overview and historical perspective.
-
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.
For me, is a must-read and refreshing text. -
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.
Agile values: Courage. Communication. Feedback. Simplicity.
Agile vērtības: Drosme. Komunikācija. Atgriezeniskā saite. Vienkāršība. -
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." -
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.
-
Agile is like teenage sex - all claim to be doing it but nobody really does properly. This book offers a great introduction to the original foundations of Agile.
-
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. -
Good write-up, opinion and ranting about the problems with agile adoption in businesses.
-
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 (:
Test-Driven Development, Refactoring, Pair Programming, Continues Integration and Delivery, Clean Code ...
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. -
I find it educational but with too much repetition of some of the practices. But I think you can get a lot of value from it. Must read for a software developer nowadays.
-
Ótima leitura inclusive para quem nunca teve experiência com Agile.
Não é uma leitura totalmente técnica -
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.
-
Brilliant absolutely brilliant!!
Too many of us in this industry including myself think we know what agile is and that we are working for organisations who do agile and maybe work for companies who claim to be agile.
Uncle Bob as one of the original signatories to the agile manifesto clears alot of misconceptions.
Will be recommending this book to all at work fellow developers and PM's -
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. -
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.
