My questions on agile processes

Something I have found very interesting in today’s “agile environments” is the adoption of processes.

I’m caught in an endless loop on my thoughts around the place of processes and how they should fit in a team.

Generally processes are put in place in order to protect the team, sort of like a safety net.  Given this chain of thought people should be interested in following the process, and should try following processes as close as possible. At the end of the day, Its almost like wearing a safety belt.

This is where it gets tricky though, in many cases developers, testers or any other team members may not not see the need for this process, they may believe it is more of an impediment than anything else.

How should this be dealt with ?

Should the team be wholly responsible for the decision to keep or lose the process ?

Should the team be educated every time a process is put in place ? ( Its too often I have noticed that people simply follow processes mindlessly)

In true scrum nature it suggests that the team make these decisions. What if some of these processes have been put in place by parties outside of the team ? Furthermore  these parties that may have a good understanding for the need of the processes ?

So I go back to my safety belt analogy, sure its a pain to put it on, but if you are unlucky enough to be involved in an accident I can assure you that you will wish you had been wearing it. Unfortunately in scenarios like this it seems its only when its to late when one may value the process ?

Another question  I have is around how often should the necessity of a process be revisited ? Is agile not about constant improvement, about constantly looking at what went well and what could have been done better ?

Here is my take, but please add comments im really excited to hear other opinions on this…

I believe that  processes should be revisited constantly, possibly with each scrum retrospective, its important to remember when doing this to consider the impact of failing to implemt and follow the process.

If the process is enforced by external party, and you feel that you dont see the need for it, discuss this with the party responsible and try to understand why it is they deem the process necessary, it may turn out that you have already covered the risk that this very process is trying to prevent. After all is this not what scrum is all about ? COMMUNICATION ?

Fresh blood

The activity on this blog has been, well, lacking of late, so I’ve decided to expand the list of contributors. This blog will become a multi-contributor blog focused (initially) around Agility in the Software Industry. With that in mind we’re adding a new contributor by the name of Nic, someone I’ve personally worked with and trust to add some good value to this blog.