Don't bring a well known solution to an unknown problem

  • Article

Are you a SCRUM Master?  A PMI certified Program Manager?  Do you have a quick reference card for for the Microsoft Solution Framework in your wallet?  How many prescriptive methodologies do you know?   More importantly, have you been repeatedly successful with one particular methodology?

I have no research to back it up, but I believe it is human nature to fall back on what has been successful in the past as your first choice for solving your next problem. This is continuously re-enforced by reports of others success using your favorite process.  Their problems were so different from yours, proving your methodology is capable of addressing a wide array of problems... right?  I think not.

Two things prevent your favorite methodology from being right for your next recovery;

First, what are the odds that all of the complexities that make up the personality of your last project are exactly the same as the next project?  Are the user’s needs the same? Is the development team the same, with the same skills, and the same tools?  Do you have the same amount of time to succeed?   It seems statistically unlikely.

Second, what is your definition of success?  Do you think it is the same as those reporting success with your favorite methodology?  Were they adding features to an existing application where success was pleasing some of the users without diminishing the features of others?  Were they re-purposing old code?  Trying to get the features to integrate with the least effort and cost possible.  Or maybe it was an update of an in-place system where success was defined as implementing a dizzying array of cutting edge technologies.  What are the odds your next projects definition of success matches one of theirs?

What is a recovery lead to do?  If you can't use what you are most comfortable with, if you can't leverage the tools that brought in the last project.  Let's consider a few possibilities.  After reviewing the problem;

  1. Begin reorganizing the project to better align with your preferred approach.
  2. Consider a wide range well known methods such as Waterfall, Spiral, XP, etc... Selecting the most appropriate.
  3. Bring the team together and determine the approach they are most comfortable with and use that one.
  4. Breakdown the project needs and characteristics and compose an approach that will fit.

I am a fan of the option 4.  Instead of bringing a well known solution to a project, take the best of what applies without regard for its methodological roots.  For example, if the team has strong developers who have a history of trusting each other, XP's pair programming is a great fit. However the rigors of the environment may not support the planning game.  If the project has ambiguous requirements, iterative design and development can help but you may need to support the major milestones from the Spiral lifecycle.  Choosing well, based on well reasoned analysis, significantly increases your likelihood of success.