Merging Team projects: numbers and final thoughts

I will now conclude and share my thoughts about this whole operation. But before that let’s have a look at a few numbers.

Numbers

Volume

  • 13 branches moved (only the Main branches were moved), approx 800Mb of source code in total
  • 250+ builds moved with their msbuild scripts (they were legacy, highly customized builds from TFS 2008)
  • 134.000+ work items moved (I announced 120.000, but this has raised faster than I had planned)
  • Average WI migration rate: 900 work items per hour, that is 5 full days, but a bit more in practice, because I split the workload in chunks
  • 162.000+ WI links restored, covering 134.000+ Work items
  • Average WI link restoration rate: 400 WI processed per minute

 

Investment

  • 28 days to plan, conceive, communicate, set up and execute the migration
  • 4 days of external help
  • a few meetings
  • 50 days of development into total to bring back the evolutions into the newly created dev branch (story here)

Benefits

  • Increased productivity for everyone, having multiple team projects for the same final product was a bit confusing
    • Developers
    • Code integratorsimage
  • The starting point to have a unified documentation of all internal processes (simplified by the way), and the starting point of many other ALM improvements
  • Morale of troops: this move was the proof that managers cared about their dev infrastructure, and new comers would not find a mess

Conclusion

Given the costs and benefits, I think my client did the right choice. I was so much convinced it was the road to follow. I admit I spent more time on it than initially planned, but people around me were really motivated into doing this, it was the first time something big was done for the sake of industrialization without carefully calculated benefits (just like agile processes). This was also the starting point for other work streams about ALM improvements at my client’s.

If I had the chance to find the kind of articles I’ve just posted, things would have been a bit easier. I’ve given:Package by Anonymous - Package icon by Fr�d�ric Moser. From old OCAL website.

  • An overall approach and methodology for every aspect
  • A procedure and work-arounds for moving the branches
  • Tools and technical info for moving the Work Items
  • A sample tool for moving the build definitions
  • Concrete numbers to help planning

I finally encourage the readers that are interested to merge their team projects if they feel that the projects are part of a single big product (from an external point of view), it’s just like an agile practice, an investment to make things more cohesive and, with time, avoid wasting time and money, because technical things are just reflecting reality. I just hope you’ll find these pieces of information useful, feel free to ask any question, and good luck with your migrations!