All

Open source software is free and the licence terms permit distribution of the source code. This means that users (both individuals and organisations) are able to change the software and submit these changes and bug fixes for inclusion in the next release. For popular products this effectively means an unlimited development team and the biggest challenge is managing the change.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This is the first principle behind the agile manifesto. Most organisations claim to be customer focused and driven by the needs of their customers. But are they really? It is interesting to look at the measures these organisations use. Who do these measures actually serve? Do they answer the question are we satisfying our customers, or do they provide management information?

Today I joined many London based workers in working from home. Using the bike would make me too vulnerable and public transport meant changing trains at Clapham, one of yesterday’s scenes of violence. Like many others I had a 24 hour news channel going in the background. For the past 24 hours the usual media blame game had been diluted by the shock and outrage of the last few days events.

I have just completed an evaluation of a .NET tool. This was planned to be a review of the tool in question but I have managed to get sidetracked by what is one of the biggest debates amongst software developers. After all real developers write code – they don’t generate it. Some take this to the extreme and won’t even use third party tools or components; after all we are paid to develop software why should we pay to use someone else’s.

This is a question that often pops up on internet forums as well as real life. Lets start with the dictionary definition of the word:

agile adj 1 quick in movement; nimble. 2 mentally quick or acute. – Collins

I often hear business managers reject agile processes because they cannot accept vague estimates. These same managers are usually surprised to  learn that agile estimation is far more accurate and disciplined than traditional methods.

Using a One-Handed Clock to Convey Project Goals

We all know about the so called “iron triangle” and the relationship between the sides. Mike Cohn has a novel way of expressing this and getting product owners to express the relationships as a part of the project objectives.

This is a question I am often asked by organisations in the early stages of the transition to agile processes. The question usually stems from the ingrained command and control mindset, and the real question is How do I know who to blame when it all goes wrong?