All processes have their pluses and minuses.  Many teams on each side of the ‘agile boundary’ think they’ve got it right, and they may, but it’s not which side of the boundary they’re on that matters.  What matters is that they’ve managed to find processes that work in context.

Maybe you’re on one of these teams.  Maybe they’re mythical to you.  Either way, what a stripped down process framework like Scrum gets you is an opportunity to find what works for your team not just because your processes/practices haven’t failed you yet, but because you’ve felt the pain the absence of that process/practice causes.  I’ll say that again because I think it’s worth repeating.  We want to be able to say our processes work not because they haven’t yet failed us, but because we know exactly what will happen if we remove them; because we’ve experienced it first hand.  A major advantage of the shortened feedback loops of Scrum (or any iterative process) is that it allows you to frequently look at your problems, find their root cause, and come up with a way to fix it.  I’ve seen time and again that existing “traditional” practices are quite often the remedy.  I’m not the first to suggest “home-grown” processes but I do believe it’s a good approach, perhaps the best if you can afford the effort and really dedicate to it.  Just like we wait to plan and estimate until we have the best information we’re going to have (i.e. ‘the last responsible moment’), why not apply the same methods to process adoption?

Now I’m not suggesting we start from ground zero, that would be foolish.  Obviously we use version control, somehow elicit and track requirements, some form of configuration/requirements management, etc, but those are all just tools.  The processes and practices that you choose to employ (i.e. Process Areas) should come from need.  Choose a responsible starting point and grow your processes as you find need for them from that point on.  If it’s required that you meet CMMI Level 3, so be it, but you should still revisit your processes frequently (and hope that whatever governing body levied that requirement is willing to accept the added cost and possible, or inevitable, waste).

It’s also perfectly acceptable to discard processes that cost more than the value they add, or to replace them with more appropriate ones.  That’s the beauty of retrospective.  After all, a failure across two weeks or even a month is better than a failure after a year of churning.  That is if you can course-correct as necessary.

No matter what side of the agile boundary your team works on, you should regularly evaluate your practices and processes.  Ask these questions with your team:

  1. Do we really need to be doing this?  What happens if we omit this?  Would it be responsible to omit this?
  2. Can we be doing this better?  If so, is there anything specific we can implement immediately?  Anything we need to investigate further?
  3. Does it feel like we’re missing something?  Is there a practice or process we can introduce to fill the void?
  4. Is something consistently going wrong?  Why x 5
I’ve found that keeping a consistent eye on these things allows us to make changes quickly and effectively without sacrificing overall quality, or any number of other benefits various processes can provide.  All processes aren’t all right for all situations.  Build what works from experience, from pain, from failure, not just because some book or group tells you so.