Monday, July 13, 2009

How do I move to new software development methodology and new platform and stiil keep existing reliability?

If my father were answering this he would say, "If its not broken, don't fix it!" OK, but he isn't a computer scientist and obviously there is a reason you are moving to a different methodology.





This is more than handing out the RUP or Agile book to your developers and saying go to it. You need to have solid written and posted up on the wall reasons for doing this.





You will also need a document/presentation on the differences between the two methodologies. Practice it because you will have to give it over and over. If your people really know the old one then they would benefit from this. You might also be selling the new one to them at the same time so go beyond black bullet points on a white slide.





You will also need a training plan that includes training for everyone with respect to their job type on the project and make that happen right before the switch. Usually the big fault with training is that it happens either too early or not at all. Schedule this first but schedule it at just the right time.





If you are hiring, make sure new recruits have and are stronger in the new methodology.





If you have a sideline project, you could start that one fresh with the new methods to get their feet wet so to speak.





1. Hire/Replace


2. Present Value, Goals and Differences


3. Schedule training, switch-over, role-reassignments


4. Get buy-in


5. Training


6. Switch


7. Weekly follow-ups on what is working and what isn't working (adjust your adaption of the new methodology)





Also, depending on how different or similiar they are you could change only elements out slowly like life cycle, code reviews, stability testing, paired programming model. You would have to break your training up into smaller pieces but this method might be good for you.


4.


0 comments:

Post a Comment