Ten Commandments of Agile
I've posted a few entries now about my unease with the fuzziness surrounding Agile and how I feel it needs some clarity so I thought I'd have a quick stab at it.
The following commandments would be my first stab at such a list which would apply to any person who is part of or interacts with an Agile team.
- Thou shalt not negotiate quality
- Thou shalt not prophesize without proof
- Thou shalt not falsify the facts
- Thou shalt not force thy wishes on others
- Thou shalt not discourage those around you
- Thou shalt not disparage the actions of others
- Thou shalt not work without committment
- Thou shalt not focus on more than a singular item
- Thou shalt not demonstrate incomplete work
- Thou shalt not act in isolation
Of course, this is just a bit of fun on my part, but I fail to see why there can't be a set of golden rules of Agile? This is also a very quick list, so who knows, I may revisit this at some time to refine it...
Also, please note, I'm not being remotely fuzzy about this... I'm not saying
"I value not negotiating quality over allowing any old crap in the code..."
Slack Is Important
I'm a very strong advocate for slack. I believe introducing slack as a policy improves the overall quality produced during productive hours compared with the traditional approach of applying constant pressure. Just like pair programming, it is actually very difficult to get managers to understand the real benefits of having 'slack'.
For me, slack is just another way to improve the transparency of an agile project and is also the ideal vehicle for introducing diversity, continuous learning and continuous improvement. Given slack, developers will naturally use this to either improve their own networks, improve their understanding on a topic they found difficult or explore new technologies. Any of these will ultimately add significant value to your project.
Simple isn’t Easy
After 2 days coaching on test first development within a legacy code-base (lots and lots of refactoring) it really hit home just how difficult it can be to do something simple. The English language doesn't help, because simple implies it should be easy, but in reality simplicity is extremely challenging. I suspect this holds true in many fields (physics springs to mind, how long did it take for e=mc²).
I'm left wondering whether it is something inherent in human nature that leads us to strive complexity or whether it is actually the way we are educated. Certainly, with regards to software engineering the majority of the agile techniques and practises appear to contradict what is being taught in universities. The comment I hear most often when coaching Test First Development is that the difficulty is in thinking backwards, suggesting that the practise itself isn't difficult per se, but it's the way we think that needs rewired.
Of course, not knowing what the problem is makes it difficult to formulate a solution - now there''s a real challenge for agile 
- Crackle and pop? There's a snap for that.
My Links
Recent Posts
- Thank you Rhod Gilbert
- The Agile Jigsaw Puzzle
- Enterprise Agile – Evolutionary Standards
- Keeping It Simple – Regression vs Acceptance Testing
- Top Tips – User Centred Automated Acceptance Tests
- “Natural Language” Automated Acceptance Testing
- Limitations of “Grow Your Own” Agile
- Functional Debt
- Vision >= Solution >= Problem
- Ten Commandments of Agile
Archives
Blogroll
- Alex Adamopoulos
- Alistair Cockburn
- Andy Hunt
- Ben Hoskins
- Dan North
- Dave Thomas
- James Shore
- Jim Highsmith
- Joel On Software
- Martin Fowler
- Michael Feathers
- Object Mentor
- Portia Tung
- Scott Ambler
- Stephen Walther
- Ward Cunningham
Tag Cloud
Rate This
