Clean Agile comes from Uncle Bob, one of the founding fathers of Agile, one of the seventeen people who authored the Agile Manifesto back in 2001.

I thought he might have some interesting thoughts on the beast they released on the software development industry.

He taught me even more.

The role of this book was perfectly summarized in the afterword by Eric Crichlow:

Imagine the significance of having a view into the origins of your religion, an understanding of the events and thoughts that shaped what would become canon for you. When it comes to your professional life, that’s exactly what you have here.

As the author wrote, it's not a book of research. It's rather the opinions of someone who was involved in Agile for about 20 years. I think it's a little bit more. The book reflects the opinion of multiple people. There are two chapters that are at least partly written by others.

There is a chapter written by the author of Software Craftsmanship, Sandro Mancuso on - guess what - software craftsmanship. More on that later.

Timm Ottinger and Jeff Langr also contributed to the book with a few sections on Agile Tools.

What I feel more important to mention that Uncle Bob included a part written by a friend of his Damon Poole on coaching. I feel this important to mention because as he emphasized, they don't agree on so many things. Including agile coaching. Yet he asked Poole to contribute to his book and express his different ideas on his platform.

These days it's so rare to listen to other opinions, not to mention having conversations with people who see certain questions or the world completely different.

Let's see a couple of things I found important in this book.

What is agile about?

Agile is about organizing small teams in order to solve small problems.

The question of big teams for big problems is already solved. Telephone networks, highway networks, cars are already built. Those are big problems and big teams solved them rather successfully. And we haven't even mentioned running states... Should we start talking once again about the Roman Empire?

We could think about big teams for small problems, but those teams shouldn't exist and usually, they don't. The market wouldn't let them survive.

What about small things for big problems? Writing the control software for the Mercury space capsule is a big task? It seems so. Yet it was done by a small team and they managed to do it with half-day iterations and everything was unit-tested.

I already mentioned once in the last paragraphs the Roman Empire, and those Romans knew something well. They could organize small squads into legions that conquered vast territories from England to the Tiger and Eufrates, from The Atlantic Ocean to the Black Sea.

Yet, Agile is for something else. It's about small teams for small software problems.

Hence the author is not really fond of those scaled agile frameworks. They might work, but he hasn't seen a lot - this is kind of the same thing that Nicolas Chaillan Chief Software Officer of the US Air Force said about scaled agile frameworks.

Hence, the agile he talks about throughout the book is not the scaled one.

Agile without technical practices is not agile

The agile he talks about is also not the one without technical practices. "Any attempt to employ Agile practices without the technical practices is doomed to fail." As one of the agile coaches I worked with said, people who delivered crap before working in scrum, will deliver the same crap within scrum too... Unless they start using agile technical practices, such as pair programming, refactoring, TDD...

This is definitely something Uncle Bob and David Poole agrees on. Too bad that I've seen too many coaches who didn't promote those technical practices and seemingly they wouldn't even have been able to.

I think it's quite obvious that we cannot simply start delivering better software just by start attending daily standups and by complaining every couple of weeks in retrospectives.

We need to change the way we actually write code, in other words how we develop our products. Extreme programming practices that are the base of agile give us quite a good foundations. I'd highly recommend the book Extreme Programming Explained by another author of the Agile Manifesto, Kent Beck.

If we think this farther, developers are responsible to actually look for the best practices and continuously improve themselves. We should look for improving our professional reputations and work by our professional ethics.

This also means that management or business has no right to micromanage the way we work. They have no right to force us to ruin our professional reputation or to force us to violate our professional ethics.

Anyway if things go the bad way, who will be the first ones found and convicted? Hello Volkswagen!

Are we all the same?

We are not. Just like we tend to misunderstand equality and equity, we also tend to misunderstand in agile what collective ownership means.

I've heard so often in agile meetings that everybody has to be capable of performing any activity. But "as systems grow in complexity, specialization becomes an absolute necessity. There are systems that simply cannot be understood in both entirety and detail." What is important at the same time is that we spend some of our time out of our specialization.

There will be parts that you know significantly better than everybody else and there will be other parts that you barely know. It's fine. Being agile doesn't mean that you have to be mediocre at everything. You'll have an average - or a bit worse - knowledge in many areas and ideally, you'll be a master of a few.

Agile Infected

The last chapter of the is written Sandro Mancuso on Software Craftsmanship. You might ask what Software Craftsmanship has to do with Agile.

We have to go back to 2001 and examine the motivations of the agile manifesto. According to Kent Back, it was about "healing of the divide between development and business". It was coming from the developers, but project managers flooded into the Agile community, and the developers were left behind, we become second class citizens in a community we created. At the same time, many project managers who became Product Owners play a double role. They don't consider themselves as part of the team and they don't share the responsibility when things go wrong.

The "us-versus-them culture" stayed dominant and the developers made another movement with similar goals to the original Agile, the Software Craftsmanship movement.

Conclusion

Clean Agile is a useful book if you are looking for the original intentions behind Agile, if you want to understand what it was supposed to be about and where it went wrong - according to one person, who is also among the authors of the manifesto.

Connect deeper

In case, you are also a bookworm and you're looking for some recommendations, let's connect on Twitter and sign up here for the monthly newsletter to get the best books for software developers (not only about software development).