You Want to Change Your Software Development Approach, But How?

changeseasonsIf your team follows a traditional, legacy approach to software development and wants to convert to an agile approach, how should you go about it? Let’s say you want to convert from a waterfall approach that uses a strict command-and-control model to Scrum that uses a self-organizing team model. How would you get from here to there?

There are many ways to undertake this change. None of them are quick or simple. Small organizations are more likely to succeed than big ones simply because they have less invested in the status quo. Big organizations have much to protect and preserve.

Here are two extreme examples of how you might proceed:

  1. Dump everything you’re doing now and adopt all new techniques. Don’t consider anything sacred or untouchable. Change everything.
  2. Change one thing, try it out, let it settle, then change something else. Approach the switch slowly and deliberately.

Which option is better? Which option will produce the better outcome? It’s up to you.

Advantages of #1

  • Gets all the pain and discomfort out in the open immediately. Lets everyone know what’s going to change.
  • Allows the team to focus in building competence with the new approach. There’s nothing to preserve.

Disadvantages of #1

  • Causes maximum disruption which might jeopardize a product or service release.
  • People may get confused and frustrated increasing the odds of the new approach failing completely.

Advantages of #2

  • Minimizes the pain and discomfort making the transition manageable.
  • Allows the team to focus on just one aspect of the new approach at a time building expertise as they go.

Disadvantages of #2

  • Spreads out the pain and discomfort over a long period of time creating a difficult work environment.
  • Increases the odds that the new approach will never be fully implemented.

If you select #1, be ready for plenty of turmoil. Offer lots of support, training and coaching. Be willing to accept some small failures and some employee turnover.

If you select #2, be vigilant. Keep pushing new ideas and new techniques. Do not accept “good enough”. Keep marching toward the final goal.

Updated: March 17, 2013 — 10:21 pm


  1. Those aren’t the only two options. You can do systematic iterative and incremental change within an organization to adopt agile. It would be analogous to refactoring a legacy code base. You would never say you have two choices 1) Refactor the code all at one time or 2) Do it over a long period of time and hope for the best. You’d likely have a plan or a strategy and implement that strategy over time. You’d get a small bit refactored and working and then go to the next small bit. I think this is the only responsible way to create lasting change.

    1. Great point, Mike. It’s usually best to avoid extremes and seek a middle ground. Coming up with a viable change plan is always a challenge. It’s still going to be a difficult transition though less risky.

      Thanks for taking the time to comment!

Comments are closed.