Sunday, June 9, 2013

Big rewrites: Summing things up

My last several posts dealt with migrating technologies, people, and skills considerations. Certainly, a few posts can't do justice to something as complex as a system technology refresh.  On the other hand, there are a few principles that can be helpful guides as you navigate the the complexity.

  • Iterate
    If possible, break the rewrite into smaller chunks.  Determine the smallest amount of business value you can deliver and start there.   This allows you to stay focused on software delivery fundamentals and to use the new technology in the real world.  Release management, branching and merging, and patching are just a few of the processes I've seen atrophy after years of rewriting software without a delivery.
  • People
    A blended team of existing folks and new hires is desired, but comes with issues that require supportive, yet firm, management. The technology transition is going to happen - that is where you must remain firm.    It is not reasonable to expect your existing team to learn a new technology stack in the context of significant business implications.  You will have acquire skills and that will cause friction.  These new folks have to be integrated into a new, combined team.
  • Skills
    The existing team members are a key to success due to expertise of the system, customers, and industry.  Your commitment to their education, skills, and to be blunt - employment, is the supportive aspect. Show them how they will participate in the transition itself, as well as their contribution in the new world after the change.  Provide them a picture of their role after the new technology is in place to assure them that they aren't helping the "new folks" build the system that is putting them out of a job.
These principles provide you a start at identifying the core issues you will face regardless of technology or industry.  For example, iteration is simple in theory.  In practice you have to address factors such as, "What is the least meaningful value I can ship to the market?", "How can I deliver 'less than everything' alongside existing software?", and "How long do I really have in the market with the existing product?"

The questions that follow from the principles are the real power.  Conversations surrounding the questions and their answers will do more to increase project success than all the project management during the project itself.  After all, if you don't have the right skills, your team is demoralized, and the project is a multi-year science project, your project status reports are going to be the least of your worries.