Clean Agile Spiral-Bound | 2019-10-27

I wrote this book because I thought it was time for someone to stand up and yell about what Agile was, and what Agile still ought to be. I thought it was time to remember the basics.
And those basics were, are, and will be, the disciplines in Ron Jeffries' Circle of Life. Those basics are the values, principles, and disciplines of Kent Beck's Extreme Programming. Those basics are the motivations, techniques, and disciplines in Martin Fowler's Refactoring. Those basics were stated by Booch, by DeMarco, by Yourdon, Constantine, Page-Jones and Lister. They were shouted by Dijkstra, Dahl, and Hoare. You heard them from Knuth, Meyer, Jacobsen, and Rumbaugh. And they were echoed by Coplien, and by Gamma, Helm, Vlissides, and Johnson. If you listened carefully you'd have heard them whispered by Thompson, Ritchie, Kernighan, and Plauger. And - somewhere - Alonzo Church, John Von Neumann, and Alan Turing all smiled as those echoes and whispers went by.
***
In February of 2001, a group of 17 software experts gathered in Snowbird, Utah to discuss software development processes. At that time, most software was created using ineffective, heavy-weight, high ritual processes like Waterfall and overstuffed instances of RUP. The goal of these 17 experts was to discuss, and possibly come to consensus, on more effective, lighter weight, approaches.
This was no mean feat. The 17 were people of varied experience, and strong divergent opinions. Expecting such a group to come to consensus was a long shot. And yet, against all odds, consensus was reached, the Agile Manifesto was written, and one of the most potent and long-lived movements in the software field was born.
***
Accountants have a discipline that was invented 1000 years ago. It's called Double-Entry Bookkeeping. Every transaction that they enter into their books is entered twice. Once as a credit in one set of accounts, and again as a complimentary debit in another set of accounts. These accounts eventually flow into a single document called the Balance Sheet, which subtracts the sum of Liabilities and Equities from the sum of Assets. That difference must be zero. If it is not zero, then an error has been made.
This practice is so essential to the proper accounting of monies that it has become law in virtually all parts of the world.
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 complimentary, just as credits are complimentary to debits. When executed together, the two entries produce a zero result: Zero tests failed.
***
The Agile certifications that exist are a complete joke, and an utter absurdity. Do not take the certifications seriously. The training that accompanies the certification programs is often worthwhile. However that training should not be focussed on a particular role, it should be for everyone on the team.
For example, the fact that someone is "certified" to be a Scrum Master is a worthless certification. The certifiers are not guaranteeing anything other than that the person paid the fee for, and possibly attended, a two-day course. The certifiers are specifically not guaranteeing that the newly minted Scrum Master will do a good job as a coach. The absurd implication of the certification is that there is something special about a "Certified Scrum Master", which of course flies in the face of the notion of a coach. An Agile coach is not specially trained to be an Agile coach.
Again, there's often nothing wrong with the training programs that go along with these certifications. However, it is foolish to train just one special person. Every member of an Agile team needs to understand the values and techniques of Agile. Therefore, if one member of the team is trained, all members of the team should be trained.
***
The practice of Pair Programming has enjoyed a substantial amount of controversy and disinformation over the years. Many folks react very negatively to the idea that two (or more) people can work productively together on the same problem.
First of all, pairing is optional. No one should be forced to pair. Secondly, pairing is intermittent. There are many good reasons to code alone from time to time. The amount of pairing a team should engage in is on the order of 50% or so. That number is not critical. It could be as low as 30% or as much as 80%. For the most part, this is an individual and team choice.
***
Over the years there has been a great deal of confusion about "The Daily Scrum" or the "Standup Meeting". Let me cut through all that confusion now.
The Standup Meeting:

• Is Optional. Many teams get by just fine without one.
• Can be less often than daily. Pick the schedule that makes sense to you.
• Should take ~10 minutes. Even for large teams.
• Follows a simple formula.

The basic idea is that the team members stand in a circle and answer three questions:

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

That's all. No discussion. No posturing. No deep explanations. No cold houses nor dark thoughts. No complaints about Jean and Joan and who knows who. Everybody gets 30 seconds or so to answer those three questions. Then the meeting is over and everyone returns to work. Done. Finito. Capisce?