Continuous (Process) Improvement – How Often & How Much?

Posted: July 7, 2010 in Agile
Tags: ,

Reading and practising agile within a team, the aim is to promote collaboration and commitment to delivery on a sprint basis. Process improvement is what all team’s should strive for, making the process ‘lean’ will allow the team to take on more work or deliver increased complexity. I’ve come across a couple of interesting articles, that highlight the case for doing something and the case for doing nothing until you have a question to answer.

The first article from tool vendor VersionOne – highlights the need for constant improvement to keep the process fresh.

The second article My Flexible Pencil – shares a different view, that sometimes doing nothing is the ‘best’ thing that could happen to the process.

From my point of view, I’ll take a few splinters, and sit on the fence with this one; though if I had to commit, I’d probably fall on the side of My Flex Pencil.

The important thing for me is that process change has to be worthwhile, and display a tangible benefit to the team; whether that be reducing admin overhead or encouraging collaboration through workshops. The outcome of retrospectives is an important one, small; achievable tweaks to a process on a sprint by sprint basis should easily show tangible benefits. Vast overhauls of process, can lead to the dangerous position where team members become lost; in turn affecting delivery.

So in summary, ‘how often’ should be driven by the outcome of retrospectives. ‘How much’ depends on the evolution of the team; has the team ‘outgrown’ the current process? If yes then a major overhaul maybe the answer. If no, the retrospective tweaks may be sufficient, but the team will decide…..

  1. adrianng3 says:


    > but the team will decide
    Your conclusion sounds very weird to me.
    In the Software companies I know, the team has decision power only on what you call the small tweaks. I never saw a team of software developers hiring (for example) a requirements engineer or and SCM specialist to extend the team. I did see retrospectives where the need was detected. But it died there. No one on the team specialized in that direction and no new hire was allowed.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s