Mention at London's XP Day 2004

I got a mention at the recent XP Day 2004 in London. Clarke Ching presented a workshop on Goldratt's Theory of Constraints - a very interesting session judging from the slides. In the referenced PowerPoint (slide 4) I am quoted from a post to the Scrum Development Yahoo group about putting process problems on the whiteboard for mention every Scrum meeting until resolved.

Unfortunately I couldn't be there myself, but thanks for the mention Clarke, and thanks to Tim Marston of Hurst (UK) Resource Management for letting me know.

Half-Life 2 is Truly Amazing!

That's it really. Just thought I'd share. :)

IS NOT - is so!

I was recently reading an item on The Register about Microsoft jumping on the patent band wagon. It commented that Microsoft had registered a patent for the IS NOT operator.

Now, I've got a background as database admin and I thought IS NOT was pretty simple. Sure, it was a long time ago but statement like WHERE COLUMN IS NOT NULL are fairly simple and easy to understand.

Then I checked out the patent - all 15 screen pages of it (at 1024x768). OMFG, is really that hard?!? I guess Patent Writer is one more career I won't be considering any time soon!

UPDATE: It's been pointed out that this refers to BASIC not SQL (I didn't actually read the patent!) It still doesn't change the fact that "If a IsNot b Then ..." is not eactly difficult to understand!

Agile Contracts

Ok, so my commercial knowledge of contracts of any type is miniscule, so if none of this is new (and I’m sure most of it isn’t) my apologies. However, we covered some of this on the recent Lean Software Development course I attended in Scotland and I thought I’d pass on some of the ideas and references. I don’t think there is anything earth shattering but it might help when consultancies are negotiating with clients to avoid the ‘fixed price vs. time & materials’ argument (as neither are the best option for Agile).

One of the main points made was that a contract cannot substitute for a trust relationship. This is clearly stated as part of the Agile Manifesto as "customer collaboration over contract negotiation". Attempts to make it so watertight that companies who mistrust each other can work together will almost always fail. It should provide a framework on which to build the trust. The iterative approach in Agile can help establish trust early – as it did on a recent project – by demonstrating real deliverables after just 1 month. This leads to the idea of, at least initially, having single iteration contracts (or maybe a larger contract with interation work orders called off) that effectively timebox and costbox the work. Once the trust factor has been established, this can hopefully lead to something more manageable for the consultancy.

As an aside, I just read an interesting post about using this early delivery & trust to sell Agile. Lookout for a future blog entry on this very subject.

Another key part is that scope cannot be fixed! This may start alarm bells ringing but it is the reality of development whether customers like it or not. Since ‘fixed price’ usually means ‘fixed price and scope’, it really doesn’t work for agile projects (or any for that matter) since in anything vaguely complex, requirements will change. Agile development actually encourages change to ensure best fit for the business. The key to resolving this may be to look at the project at a higher level and measure its real value to the company (ROI) to determine its success or failure. As an aside, the idea of measuring what you can influence not what you can control, i.e. at aggregated levels to avoid local sub-optimization, is one of the key principles in Lean manufacturing and is very well described in the Lean Software Development: An Agile Toolkit book.

One of the best, basic types of contract for agile projects appears to be target price – pretty much what we had for the already mentioned project. This works well since it naturally aligns goals – deliver the best solution for a given budget. There are lots of variation on this theme, particularly around dealing with what happens when the project goes over or under budget. This is where the trust factor comes in - if the scope is variable, how do you identify when the project is actually finished? As already mentioned, this needs to be by measuring at a higher level and could be as simple as having a defined objective - "increase efficiency by at least 10%", "reduce data entry errors by half", etc.

There are some interesting links on the Poppendieck LLC website. Also, an interesting post by Martin Fowler about dealing with a fixed price contract with a new client who insists because of being burned in the past.

My First Blog Post

Well, it's happened at last. This is my first ever blog post. It's actually quite cathartic so I may well add more. As the description says, I see this as mostly for me but if you, dear reader, find something useful or interesting then that's good too.

Most of my posts here will be cross-posted to my employers blog host except those not related to software development.

I guess that's it. Lets see how long the second post takes to arrive!