Tim’s Rule on Agile

Tim’s Rule on Agile:
If you read a description of Agile practices and do not find at least one thing wrong per page, then you do not have enough experience to make Agile work.

Tim’s first corollary to the Rule on Agile:
If you can’t find something wrong with an Agile practice, you are looking at a practice that Agile adopted, not invented.

Tim’s second corollary to the Rule on Agile:
When your Agile project fails, you will be told “you did not do Agile correctly”.

Note: “wrong” means “sub-optimal”, or “contradictory”, etc. If things were actually wrong in the “demonstrably not correct or true in all contexts” sense with Agile, Agile would have died long ago.

Note: “description of Agile practices” does not mean the manifesto, or principles, or other vague lists. It means concrete, actionable process definitions or rules [which are admittedly hard to find.] Examples: Pair all of the time and Everyone Commits To the Mainline Every Day and No commit on a broken build. [Did those last two cause a twinge of “hey, those two things don’t necessarily work well together” for you?]

Examples of practices that Agile “adopted” (i.e. co-opted, i.e. stole, i.e. predate the term Agile): Unit testing and Daily/Nightly builds

As Dilbert’s pointy-haired boss said: That was your training.

This entry was posted in Software Engineering. Bookmark the permalink.