When it comes to the adoption of Rational Team Concert there are some typical questions that I often face with customers and colleagues in planning the solution design and rollout enterprise-wide.
I recently had to confront these questions for a big adoption of RTC as the new development solution. I want to share some of the important tips I try to take in count for a successful adoption as smooth as possible, avoiding known undesired paths.
If we “forget” for a moment in the discussion about all the decisions and tasks related with infrastructure, users provisioning … You will find yourself facing three main categories of tasks:
1. Process design
This is an important step in which you will be gaining understanding of the development process that your teams follow, and the peculiarities of their lifecycle. Some of the questions you will be asking yourself are “How my teams develop today and how they are supposed to work in the new process in RTC? How information is to be traced? What roles are involved in the development and how they collaborate? What process(es) templates will I use as base? What new information do I need to create to support my teams’ needs? … ” . RTC comes with a set of predefined templates covering the typical development methodologies and the supporting definitions (work item types, attributes, …). While this is typically enough for small teams to start working, for bigger teams you may find from the beginning that some tweakings are needed to accommodate it to their needs.
Try to identify the minimum set of information and processes to cover to leverage teams work. Perform the customizations needed to the base process templates and plan to start with that. Don’t try to solve all the complexity from minute 0. Sometimes the processes have been evolving and getting complex unnecessarily and this is a good moment to try to get away of these practices; other times it is just not manageable to try a silver bullet from the beginning.
2. Teams and assets organization
This can be HUGE topic in your work, depending on several things like: development technologies, teams involved, information sharing and visibility constraints, applications architecture, outsourcing teams involved …
Focus on a – minimum – set of applications that can serve as model. Consider in that study the visibility constraints, information trace needed and reporting expected and try to model with the teams involved for the identified applications. By the way, the less administration overhead for new developments to start, the better.
3. Migration of assets and code from your current system
How to migrate, what assets, how many versions, … ? There are different technologies you may be migrating from, and RTC offers help for the most typical ones. At the end you have to come to a reasonable agreement with the teams; just keep on top of your head that replicating your current environment data in the new one is most of the times not doable, and always simply not affordable.
Try to figure out the migration process in advance to have some idea of times, and how hard will be to get the data from your organization. That will speed up your discussion with the teams.
OK, so now we (ideally) have enough information of all these pieces on top of the table, with a reasonable idea of how model teams in your organization will work, how their assets will be organized and what data needs to be migrated … Now it comes the time to think how to plan the solution adoption for them: when planning this effort a first advice comes to my mind: don’t plan for a big bang migration process, it simply doesn’t work!. What are the models that work then? There’s no magic wand but there are some practices you can try to use in your in your solution adoption planning to make it as smooth as possible:
- Choose an isolated team with no critical deliverables and which works on applications we identified as “models” in the enterprise: isolated means that we try not to impact neither have dependencies with the work of other teams (or code), not yet in the new solution.
- Plan with the team(s) the adoption of the tool identifying some stakeholders to periodically check status with them, solve misunderstandings and iterate in your process with their feedback to evolve the solution to fit their actual needs.
- Depending on the situation, teams’ needs and complexity, you can try to think of incremental adoption of RTC features: first just adopting work items and planning? Use legacy build system for a while with RTC SCM? …?
- Based on previous points, schedule the adoption by the rest of the teams with the lessons learned in mind, again in an iterative way. You won’t want to get buried trying to solve same issues with lots of teams at the same time.
Adopting a new development solution in an enterprise is always a “different story”, each has peculiarities, a different culture, legacy systems, user resistance to change … But at the end, trying to have these simple ideas in mind may help you face the process in a smooth way (I hope so 🙂 )