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

by Robert C. Martin

If a change to the requirements breaks your architecture, then your architecture sucks.

Customers, users, and managers expect fearless competence. They expect that if you see something wrong or dirty, you will fix and clean it.

Iterations do not fail. The purpose of an iteration is to generate data for managers. It would be nice if the iteration also generated working code, but even when it doesn’t it has still generated data.

If we see a positive slope, it likely does not mean that the team is actually going faster. Rather, it probably means that the project manager is putting pressure on the team to go faster. As that pressure builds, the team will unconsciously shift the value of their estimates to make it appear that they are going faster.

If the velocity chart shows a consistent negative slope, then the most likely cause is the quality of the code.

What did I do since the last meeting? What will I do until the next meeting? What is in my way?

Whom do you want to thank?

Test-Driven Development is the corresponding practice for programmers. Every required behavior is entered twice: once as a test, and then again as production code that makes the test pass. The two entries are complementary, just as assets are complementary to liabilities and equities. When executed together, the two entries produce a zero result: Zero tests failed.

In general, Agile coaches are not trainers. They are members of the team whose role is to defend the process within the team.

Nowadays, it is all too frequent that we see Scrum Masters who are not coaches at all but are simply project managers doing what project managers always did.

The Agile certifications that exist are a complete joke and an utter absurdity.

Agile was never intended for large teams.

Large teams are a solved problem.

So again, the bottom line from my point of view is this: There is no such thing as Agile in the large. Agile was a necessary innovation for organizing small software teams. But once organized, those teams fit into the structure that large organizations have used for millennia.

Good collaboration removes some of the blocks people have to do their jobs but does not necessarily make them more skilled.

Companies are still not mature enough to understand that technical problems are in fact business problems.

we focus too much on the importance of the training wheels and keep them on for too long, the child gets too dependent on them and does not want them to be removed.

“Principles without practices are empty shells, whereas practices without principles tend to be implemented by rote, without judgement. Principles guide practices. Practices instantiate principles. They go hand in hand.”

Conversations between developers and business should be about why, what, and when—not how.

Differently from Agile coaches in the early 2000s, who had a strong technical background, most Agile coaches today cannot teach XP practices or talk to businesspeople about engineering.