Recommendations not Rules
I seem to be encountering more and more people who want to codify agile into a set of rules. I’ve seen this lately in authors of books, blogs or PDFs about agile or Scrum that say “You must do this” or “If you don’t do this or all of that then you’re not doing it right.” Over the last few months I also encountered this in conversations with a few Project Management Offices (PMOs).
That leads me to my new year’s resolution for 2012 and one that I hope a lot of others will make with me: make recommendations not rules.
There are very few hard-and-fast rules to agile software development. I’d put things like:
- work in iterations of no more than a month long
- by the end of each iteration be “done” with something to some pre-agreed upon definition of done and solicit feedback from your key stakeholders on it
- at the start of an iteration, get together and figure out what you’re doing to do during the iteration
- at the end of the iteration, reflect on how well you did during the iteration
- talk a lot during the iteration
Beyond that, it’s much more about recommendations. And there are plenty of things we’ve learned in the nearly 20 years that some agile processes have been around in even informal forms. For example, I recommend teams use user stories as their approach to requirements. I recommend teams use story points for estimating. I recommend that the team pick a day other than Mondays for starting their iterations. I recommend the Szechuan Chicken at Spice China. But, none of these things is required for success with agile. Each may help a team be better, and I have reasons I recommend each. But, these things are not required.
So, my resolution for 2012: Make recommendations not rules. I’d kind of like to make it a rule that you join me in this resolution, but I’ve just resolved not to make such rules.