The Agile Jigsaw Puzzle
A colleague at emergn asked if I had any suitable pictures for some course brochures and I didn't. However, for a bit of fun (and to play with some new technologies) I had a blast at creating some imagery. My first draft is my take on the agile jigsaw puzzle. Rather than use the mona lisa, I decided to go for something more contemporary in the form of Jack Vettriano, largely because I love his work.
The Agile Jigsaw Puzzle
I was specifically trying to capture the idea that something beautiful can be produced a small piece at a time (and nothing more)...
I had great fun creating it and I hope you like it...
Enterprise Agile – Evolutionary Standards
Low Tech Evolutionary Standards
At the risk of being lambasted by the agile community I will use the words enterprise and agile in the same sentence 
This article largely follows on from some previous entries and in particular my entry on user centred test driven development.
It is often a complaint that large organisations trundle along painfully and slowly. Work can't start without following some process or other until you have sign-off. Part of this sign-off will probably involve agreement to follow certain standards and guidelines, but if these standards don't yet exist how can we start???
To challenge this and present an alternative approach, why not make the "standards" part of the delivery itself. Make it clear up front that rather than wait for the standards to be released (which would be the normal mode of attack in large organisations) you will actively work with whichever standard's body exists in the organisation to evolve just enough standards to support the actual work you are doing as you work through the backlog.
To make this work, COURAGE is imperative... Someone has to have the courage to put a stake in the ground early, recognising there is a small risk this may change. Developers should embed the standards into their automated testing as early as possible, this means that when and if a standard does change, there are tests in place which will assist developers in ensuring that all work to date is easily brought up to date...
The results of this is a design language that everyone can understand, when someone says they are writing a test which is looking for the jobs tag in the currently featured news article, everyone should know what that refers to in the wireframes, and also know how this will be identified and marked up in the implementation. This allows tests to be written before any code and even for the final "Look And Feel" to progress alongside development.
Of course, you're always free to continue in the traditional model and wait for three months until the standards body within the organisation produces a 300 page guidelines document before even starting that killer new feature that will storm the market... Or make totally random guesses, which are much more likely to be wrong, and be safe in the knowledge you have the traditional saviour of projects - Hope and Prayer!!!
Keeping It Simple – Regression vs Acceptance Testing
Another emergn coach asked me the other day how I distinguished between an acceptance test and regression tests. For me there is a very simple rule...
- If I write the test before I write any code, it's an acceptance test.
- If I write the test after I've written the code, it's a regression test.
- If I write code to make an acceptance test pass, it is now a regression test.
Keeping it as simple as this keeps you out of trouble, I've seen so many people try to retro-fit acceptance tests after they've written code only to write a test which is based on what they've written rather than what they should have written. It's a subtle but important point that writing a test for stuff you've written (which might be wrong since you haven't got an acceptance test) means you are potentially writing a test that the system always does the wrong thing...
Could Agile Have Evolved?
DNA
I've been researching material to support an article on my company blog entitled "Agile Dictators" and it left me thinking about how Agile started in the first place.
The more I reflect on this, the more I am left feeling that Agile is actually a mutation in software development and this is one of the major reasons why Agile is so difficult to master. I'm wondering whether agile would ever naturally evolve in a small team left to their own devices and I simply can't envisage it. Of course, this will now remain an academic hypothesis since Agile has now stamped it's influence indelibly on the DNA of software development.
Software development as a craft suffers from unnecessary complexity and I fear that Agile, which initially thrived in simplifying (or removing) this complexity, is now becoming itself encompassed in unnecessary complexity. Despite agreeing with much of the sentiment of the software craftmanship manifesto I just can't bring myself to sign up to it yet. I struggle to see the benefit of more fuzzy aspirational statements and would prefer to see a clarity of vision and roadmap to achieving it.
Fundamentally Agile is fantastic, but sadly the passionate discussions, raging debates and conflicting methodologies don't clarify anything. If Agile doesn't clearly define itself soon I fear yet another mutation may take centre stage and Agile will end up being just a blip (albeit a very significant blip, where we gained sight) in the evolution of software development.
Love Wave, Hate Google
I've not tried wave, but I'm already loving it, I can see immediately how it addresses one of my wishes from a previous post... But I'm hating the wait. I had always looked to Google as a very pioneering company and certainly assumed they applied agile principles. However, I can't see how such an important disruptive technology like Google Wave has managed to stay behind closed doors for 2 years...
I've been working on a few internal projects for my company of late and this has involved working in a distributed fashion (yes, pairing by phone), and during some of these sessions I can immediately envisage the benefits of using Wave.
Surely there is at least one complete, tested feature they can roll out to production? My concern is there are still some fundamental challenges facing the team, and I would not be surprised to find it being concurrency issues, so as the potential end-user of this technology I'm going to make it clear, I don't particularly care about have multiple users editing the same document in real-time with transparent, asynchronous updating... Let me edit, commit, refresh, etc as a simple starting point... But whatever you do, let me do something before I find a simple alternative...
To find out more about wave, visit the wave site http://wave.google.com/, and especially watch the google I/O presentation...
- 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
