Rick Tonoli

My questions on agile processes

—

by

Rick Tonoli
in

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 ?

Comments

3 responses to “My questions on agile processes”

  1. Nick Avatar
    Nick

    I couldnt agree more that process is something that should always be followed and should be looked at all the time.

    However one of the biggest mistakes I have seen is the creation of processes with only one view point (development angle or business angle etc.) For a process to work it also needs to be practical.

  2. Rene Avatar
    Rene

    I’d review the process with the team during the next retrospective and check the impact of that process on the progress of your team.

    Starting communication with the department/team which dictates the use of the process is indeed necessary and i would arrange a with their SM or manager(without an agenda of your own apart from understanding their need for this process).

    If it is not a showstopper that needs to be adressed straight away, you can monitor the impact of the impediment during the next sprint and gather additional information about it. After the next sprint, take the other SM aside and share your findings. Personally i like to do this in an informal environment to avoid unnecessary tension. If he/she doesn’t care, talk to someone who has an invested interest in your project and inform them. Again, preferably informal to test the grounds. If it doesn’t help, do it officially. Afterall, you’re all part of the same company and want to get your products out of the door.

    We had similar issues and my SM counterpart was very surprised to see how much pain their process caused us. We reviewed it together and adjusted it since removing the process as a whole was not possible.

    Still, the team was happy that i took their feedback seriously, that we made cross departmental efforts to overcome the issue and in the end managed to change the process in a way that was less painful and time consuming.

    A practical sidenote: We added an impediment section on our scrum wall. Whenever an impediment came up, we added it to the wall as seprarate post it (I’d ask for a single line of description by the affected person these days). At the end of each sprint, we went through the list of impediments and reviewed the seriousness of its impact on the team and thereby the project.

    By default, i would review every impediment during the retrospective. It is one of the most useful aspects of SCRUM if done regularly and properly since it allows you to find the underlying issues. Of course you need a work environment in which the removal of those issues is welcome 😉

    Great blog, haven’t seen many where people share their experiences (and pain) so openly.

  3. Rene Avatar
    Rene

    Small addition: maybe the following is of help to you:

    http://jeffsutherland.com/scrum/Sutherland-ScrumCMMI6pages.pdf

    And a brief explanation about CMMI
    http://en.wikipedia.org/wiki/Capability_Maturity_Model

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.