Linking the left brain and the right brain

Don’t Change a Development Approach That’s Working

Should your software development team follow a single approach for all projects? Or, should they select the best approach for the situation? I believe the answer is ‘…follow a single approach’. Here’s my reasoning.

There’s a general philosophy that software projects facing significant risk factors benefit from agile approaches like Scrum, Kanban, Lean or XP. A few examples of significant risk factors are:

  • Project scope that is not well-defined.
  • Requirements that are changing and not expected to stabilize soon.
  • The need to ‘invent’ something or do something that the team has never done before.
  • Technologies and tools being used for the first time by the team.
  • Entering new markets to grow the company and expand business opportunities.

I could go on but the general idea is that as risk increases, an agile approach is usually safer simply because the team will deliver software for evaluation earlier. These early deliveries will spark conversations and crystalize ideas. There is no better way to define the solution space than to deliver working software — even if it’s incomplete.

This reasoning may result in a tendency to evaluate each new project and determine if an agile or waterfall approach should be used based on the perceived risks. On the surface, this makes sense. Pick the right approach for the task at hand, right?

Unfortunately, it’s not that simple.

Taking a team that is proficient in any agile or waterfall approach and forcing them to follow a different approach because it is deemed to be a better fit for the current project is asking for trouble. Software development teams work hard to master the approach they follow. They try. They fail. They adjust. They try again.

Once they find techniques that work, they should continue to use them until they find superior ones — even if the new project would be better served by an alternate approach.

Rather than switch to a completely different software development approach, a better idea is to adjust the current approach to fit the situation. For example, for a high-risk project, waterfall can deliver multiple small projects rather than one large one. Or, for a low-risk project, an agile approach like Scrum can define and estimate all of the stories up front, implementing them in several sprints.

Find ways to leverage the skills and knowledge that you have. Make major changes only when what you’re doing isn’t working. Make sense?

Updated: January 8, 2012 — 9:53 pm
© Damicon 2014 Frontier Theme