Thank you Rhod Gilbert
I have to let out a massive thanks to Rhod Gilbert. I was watching his video "Rhod Gilbert and the Award Winning Mince Pie" and he provided me with a phrase that eloquently describes what happens when you continue to build upon technical debt (deliberately or not) or to defend a flawed design or architecture (which can also happen in agile projects). So cutting to the chase:
"not so much polishing the turd as gold plating it and framing it"
Love it...
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.
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...
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..."
Big Red Button
Here's my little user story:
As a blogger,
I want to use Threely as my url shortener.
So that I get more letters on Twitter.
Pretty simple story, and also very simple to implement, but impossible to test? I can certainly test the API to twitter, but given I use a wordpress plugin (developed by someone else) to do the auto-posting is it worth the effort for the addition of 6 lines of code?
For me, the pragmatic solution is to take the risk based approach. I'm going live with Threely (http://3.ly) (again, fixed a small typo), but have an escape plan (extremely important when there are known risks) which is the ability to revert if anything untowards happens and revisit my approach.
So, here goes, pressing the big red button
Delivering Early

The MMF wasn't quite complete.
I've seen plenty of fancy graphs demonstrating how agile provides faster ROI through early delivery and while this can certainly be true in some cases, it doesn't necessarily hold true for all cases.
Just because a feature is done, doesn't mean you could, or even should deliver it... The Minimal Marketable Feature set (MMF) is very important for determining when to go live. When you take the MMF into account, then agile doesn't deliver any value until the MMF is complete and this certainly won't be within the first iteration.
Of course, once the MMF is done, agile will win hands down delivering new functionality, enhancements and bug fixes (what bugs?)...
So what went wrong in the picture? What was the MMF
- Wheels/Chassis
- Engine/Gearbox
- Steering
- A Seat
And guess what, they've ticked all the boxes, I'm so excited I'm going to run off now to my local dealership and snap one up...





