Scrum Articles

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.

About 18 months ago I got really fed up about the fact that I had lost 3 SATA hard disks in the space of about four months. Fortunately no major harm done because at the time I had copies of my data all over the place. This was all managed manually but up to date enough that I never actually lost anything, although it did take a lot of time and effort to put it all back together. Perhaps I was a bit more diligent than usual after the first failure.

We know that commitment is essential in Scrum – but commitment to what? We also know all about commitment based planning. Both of these are good things, but when does incorrect application of the term commitment drive negative behaviour?

How many times have you been frustrated by a client or management team who shies away from value analysis or prioritisation because we know we have to have it all.? Usually this means that they have a pre-determined solution and very often this is a software solution and lose site of the fact that we want to deliver the maximum business value as quickly as possible with the minimum amount of effort.

Towards the end of 2009 I decided that I no longer wanted to be a technical director and really really wanted to be a full time agile coach. This had been a significant part of my last two roles and was the part I enjoyed most, and certainly most of my successes in this arena were attributable to agile transformations. But this meant consultancy, and there was one tiny little niggle in my mind:  could I retain my integrity and keep doing the right thing?

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.

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?