Clean Agile: Back to Basics (Robert C. Martin Series) 1st Edition, Kindle Edition
Download the free Kindle app and start reading Kindle books instantly on your smartphone, tablet, or computer - no Kindle device required. Learn more
Read instantly on your browser with Kindle Cloud Reader.
Using your mobile phone camera - scan the code below and download the Kindle app.
Enter your mobile phone or email address
By pressing "Send link," you agree to Amazon's Conditions of Use.
You consent to receive an automated text message from or on behalf of Amazon about the Kindle App at your mobile number above. Consent is not a condition of any purchase. Message & data rates may apply.
“In the journey to all things Agile, Uncle Bob has been there, done that, and has the both the t-shirt and the scars to show for it. This delightful book is part history, part personal stories, and all wisdom. If you want to understand what Agile is and how it came to be, this is the book for you.”
“Bob’s frustration colors every sentence of Clean Agile, but it’s a justified frustration. What is in the world of Agile development is nothing compared to what could be. This book is Bob’s perspective on what to focus on to get to that ‘what could be.’ And he’s been there, so it’s worth listening.”
“It’s good to read Uncle Bob’s take on Agile. Whether just beginning, or a seasoned Agilista, you would do well to read this book. I agree with almost all of it. It’s just some of the parts make me realize my own shortcomings, dammit. It made me double-check our code coverage (85.09%).”
–Jon Kern Nearly 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–programmers and nonprogrammers alike. Martin, author of Clean Code and other highly influential software development guides, was there at Agile’s founding. Now, in Clean Agile: Back to Basics, he strips away misunderstandings and distractions that over the years have made it harder to use Agile than was originally intended.
Martin describes what Agile is in no uncertain terms: a small discipline that helps small teams manage small projects . . . with huge implications because every big project is comprised of many small projects. Drawing on his fifty years’ experience with projects of every conceivable type, he shows how Agile can help you bring true professionalism to software development.
- Get back to the basics–what Agile is, was, and should always be
- Understand the origins, and proper practice, of SCRUM
- Master essential business-facing Agile practices, from small releases and acceptance tests to whole-team communication
- Explore Agile team members’ relationships with each other, and with their product
- Rediscover indispensable Agile technical practices: TDD, refactoring, simple design, and pair programming
- Understand the central roles values and craftsmanship play in your Agile team’s success
Register your book for convenient access to downloads, updates, and/or corrections as they become available. See inside book for details.
Inspire a love of reading with Amazon Book Box for Kids
Discover delightful children's books with Amazon Book Box, a subscription that delivers new books every 1, 2, or 3 months — new Amazon Book Box Prime customers receive 15% off your first box. Learn more.
Customers also search
From the Publisher
|Best agile practices of cleaning code “on the fly” Software Craftsmanship||Endure and succeed amidst swirling uncertainty and nonstop pressure||Direct, no-nonsense answers to key architecture and design questions||There are no shortcuts for Agile’s true benefits: You need to do Agile right.||Deliver robust, effective code and to be proud of all the software you write|
|Title||Clean Code||Clean Coder||Clean Architecture||Clean Agile||Clean Craftsmanship|
|Core Concept||Presents a revolutionary paradigm that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it.||Robert C. Martin introduces the disciplines, techniques, tools, and practices of true software craftsmanship. This book is packed with practical advice–about everything from estimating and coding to refactoring and testing.||Uncle Bob presents the universal rules of software architecture that will help you dramatically improve developer productivity throughout the life of any software system.||Uncle Bob describes what Agile is in no uncertain terms, stripping away misunderstandings and distractions that have made it harder to use than was originally intended, and how Agile can help you bring true professionalism to software development.||Provides a pragmatic, technical, and prescriptive guide to the foundational disciplines of software craftsmanship and a discussion of the standard and ethics developers and programmers should be following.|
|Endoresement||"It is the best pragmatic application of Lean principles to software I have ever seen in print." —James O. Coplien, Founder of the Pasteur Organizational Patterns project||“Some technical books inspire and teach; some delight and amuse. Rarely does a technical book do all four of these things.”—George Bullock Senior Program Manager Microsoft Corp.||"A good architecture comes from understanding it more as a journey than as a destination, more as an ongoing process of enquiry than as a frozen artifact." -- Kevlin Henney||“What is in the world of Agile development is nothing compared to what could be. This book is Bob’s perspective on what to focus on to get to that ‘what could be.’ And he’s been there, so it’s worth listening.” –Kent Beck||". . . [A] timely and humble reminder of the ever-increasing complexity of our programmatic world and how we owe it to the legacy of humankind--and to ourselves--to practice ethical development.” -- Stacia Heimgartner Viscardi, CST & Agile Mentor|
About the Author
- ASIN : B07XTL99JQ
- Publisher : Pearson; 1st edition (September 12, 2019)
- Publication date : September 12, 2019
- Language : English
- File size : 7487 KB
- Simultaneous device usage : Up to 5 simultaneous devices, per publisher limits
- Text-to-Speech : Enabled
- Screen Reader : Supported
- Enhanced typesetting : Enabled
- X-Ray : Not Enabled
- Word Wise : Not Enabled
- Print length : 245 pages
- Lending : Not Enabled
- Best Sellers Rank: #217,750 in Kindle Store (See Top 100 in Kindle Store)
- Customer Reviews:
Reviews with images
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
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.
If 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 far
By Juan Astudillo on September 30, 2020
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.
Top reviews from other countries
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.
I do miss some content around using agile in teams working in enterprise environments and developing on systems such as low code platforms, where implementations of technical practices of agile such as simple design, refactoring and TDD if not close to impossible it’s truly uncharted territory for agile.