Elements of Agile Style - 1

I have written a short handbook, called The Elements of Agile Style. (Current draft available in PDF.)

What got into me?

Well, I had to do it. We need more reminders of the basic stylistic elements before we move forward to work in our own individual style. This is the way with any art. You write a sonnet. You play football. You learn a martial art. You dance. You cook. Establish a firm grasp of the basics and then move toward mastery.

All of these arts require the disciplined understanding of certain basic elements. It was recently March Madness time, so I'll call these basics dribbling and shooting, and staying in front of the offensive player and covering the passing lanes. From mastery of these basics your own individual style starts to emerge.

Strunk & White's The Elements of Style did a similar thing for writing. It set out some rules and guidelines and suggestions. It covered usage, composition, forms, and style.

Rules, Rules, Rules. This seems to be an area of some controversy. For some, Agile is a revolution against Waterfall, which had far far far far too many rules. And so, to them, any rules are anathema. Nonetheless, with admitted trepidation, I started with the "rules of Scrum".

Why? Didn't I know that every team must self-organize and set rules for itself? And that any externally imposed rules would likely ruin the team?

First, I guess I must confess my attitude toward rules. To me, rules were created by someone or some group long ago and far away. And I am here and now. I am in my current situation, and if the rules don't obviously hinder me, I will likely go along with them, but otherwise I will break the rules in a second. I'm from New York. I'll jaywalk. I'll go the wrong way on a one-way street (if there's no traffic).

Second, frankly, I have a lot of respect for the Team. I believe the Team wants some rules, if only to simplify life some. And I trust that the Team will use judgment about when to enforce a rule and when to let it slide. (Hint: On Wednesday, Sept 12, 2001, I would not be worrying too much about the length of the Daily Scrum.) If the Team can't stand up against a mere book, and tell the book where to get off, they have much greater problems than a book can solve.

I will have further posts about the book later.

If you read it, I hope you find this little book useful. Your comments are welcome. Thanks.