Process

There is nothing like a discussion about process. Everyone has their own ideas, every company works differently.

I have recently taken a lot more interest in process. Last month I became a Certified Scrum Master and those who know me will know that I am a Scrum advocate. I think its a fantastic process. I have worked on a couple of projects that used Scrum and it has proven itself to be very successful.

Its a deceptively simple process which is far too often badly implemented. A poor implementation of Scrum is more damaging than not using Scrum in my experience.

I am not going to attempt to explain how Scrum works, I will leave that to the Wikipedia. Whilst not the best explanation, it will suffice. I personally enjoy using Scrum as it involves doing lots of small pieces of work which are well understood and can be fairly accurately estimated leading to reasonable expectations from clients and higher quality end product. I also believe that the speed with which issues can be surfaced is a massive benefit.

Doing Scrum badly will lead to more problems than if you were not doing Scrum at all. It is for this reason that most Scrum trainers will suggest that until you are experienced at using Scrum and implementing it well, you should follow the Scrum process pretty much to the letter.

A bad implementation of Scrum can force issues down and stop them being surfaced, can lead to inefficiencies as everyone attempts to work out what is going wrong and instead of opening up the process for all to see, it closes down the Scrum team and cloaks the detail in useless rhetoric.

I want to work on projects using Agile with Scrum. I do not want to be agile when I should be Agile nor vice-versa. I make a distinction between agile and Agile and its an important one.

When talking about agile with a lower case "a" I mean that I will show a more literal agility - responding to change, trying to prototype quickly and generally being flexible. This is great for a client but dangerous. Too much agility will lead to timelines slipping or the dreaded overtime!

Agile with a capital "A" on the other hand is a process and a set of techniques including but not limited to Scrum and XP. When I am being Agile, I will not respond to change in the same way, the person requesting the change has to follow a specific process, a simple process and one which is totally transparent. I have never heard a client complain about having to do that when the result turns out to be a better product. The process protects me and my Scrum team from being distracted, allowing quality to rise whilst also forcing the clients priorities to be my priorities.

From this realisation I have chosen to be Agile not agile.