The Agile Manifesto – Values and Principles are the foundation.
My Maxims are not meant to distract from or replace them. My Maxims are just another way to for me to frame my thinking.
I spend a lot of time scrutinizing the things I value to make sure I can minimize my blind spots and unknowns, at least the ones that make the most difference. Seems I am usually my own worst enemy.
I share my Maxims so I can get feedback from you and learn where I can improve. Please be kind.
Agile Open So Cal 2012 at UC Irvine.
Once again I have been able to participate in the Agile Open So Cal at UC Irvine. Great fun, great people, great sessions, great etc. Several people had seen me tweet these “Maxims” or heard me talk about them before, and asked me to present them again. It takes VERY LITTLE URGING to get me to talk about Agile, Lean, Clean Code, or anything programming. So, I proposed a session – and here are the notes:
Title: The 8 Agile Maxims of Software Development
Byline: This time it’s personal. With Woody, it’s always personal.
Here they be (in no particular order – you can mix and match):
1- It is in the doing of the work that we discover the work that we must do. Doing exposes reality.
I live this daily. Thinking about stuff is obviously worthwhile – I don’t discount that. But doing is way more important.
2 – “Responding to Change” is impossible unless code is easy to change, easy to maintain, easy to fix, and easy to enhance.
The “easy qualities” – I learned them from the greatest programmer I have ever worked with: Fred Zuill, my little brother. Back in the 90′s he used to do a talk on the Qualities of Software that was pithy, meaningful, and wickedly sardonic. If you ever get a chance to hear him speak, do it. If you see him please remind him he owes me $18.
3 – Question Everything – put special focus on our deepest held beliefs. What we trust most hides our biggest problems.
I’m pretty good at getting comfortable in my ways. Gotta work at keeping that from blocking improvement. When I really believe something, I’m likely to be fooling myself. Lets keep things uncomfortably wonky.
4 – “Working Software” is software that users are actually using. Until it’s in use it is truly useless.
This is my understanding of how “Working Software” should be thought of (as in the Agile Value of “Working Software over Comprehensive Documentation”).
Let’s not fool ourselves: “Potentially Deliverable” is a lot like “The check is in the mail”.
5 – Stress at work diminishes value. Crunch-time is a symptom of harmful and counter-productive attitudes.
Nuff said? I hope so.
6 – We are the innovators of our process. Learn what works for others, prove it for our self, innovate beyond.
Just a suggestion: Don’t wait until you are an “expert” to innovate. Just like Jello, there is always room for innovation. (You remember those ads for Jello, don’t you? Dang, you young people really missed out on the best days of television. You remember television, don’t you? Dang… I’m getting old, so it seems)
7 – The object isn’t to make great software, it’s to be in that wonderful state which makes great software inevitable – Robert Henri, paraphrased
This is a paraphrase of the well known quote from Robert Henri. Just replace “great software” with the word “art” and you get the original (and much more meaningful) quote. I replay this one over and over in my head all the time. Wish I was the one who had said it! I was introduced to this quote many years ago by Donald Faast, an amazing show-card writer and sign man. I think he is in Colorado now. If you see him, just say thanks for me if you would.
8 – The more we work at the work we do, the less capable we become -Repenning/Sterman – Make time for improving capability
Dang. If you haven’t already read the paper “Nobody Ever Gets Credit for Fixing Problems that Never Happened: Creating and Sustaining Process Improvement” by Repenning and Sterman then please click on it and read that now: http://bit.ly/Qd3NmR - It’s a pdf file.
9 – I reserve the right to add, remove, change, improve. (This one has been added since the session).
I expanded on these greatly during the session, and invited feedback, observations, and discussion. Unfortunately I was not able to take notes. Overall, I feel it was well accepted and if it was not, my memory has already painted it much better than it actually was. Thank you memory!
Remaining Puzzles, Recommendations, Next Steps:
I pointed out that these Maxims will change and grow, and invited the participants to add, remove, change, improve
Also… A BIG thanks to Drew LeSueur – @drewlesueur – from Integrum Tech
Drew has been very encouraging to me, and on his own he quickly put up a site and posted the Agile Maxims: http://agilemaxims.org/ - Remember, this whole thing is just me thinking out-loud.
[NOTE: To make sure people are paying attention, I always purposefully put a hidden typo in my posts... see if you can find it.]