Last week, I was on a business trip to China with a colleague of mine. We met multiple local IBM teams and visited a couple of financial customers.
During our customer-facing sessions, questions raised by the customer were technical in essence which is… fair enough as we’re part of the RETT (Rational Emerging Technologies Team). But some questions revealed:
- some misconception about the product (RTC / RTC EE)
- some reluctance of parts of the customer organization for adopting a newer, yet different but more modern tool with safer workflows.
As an illustration, it appeared that the technical lead in charge of the RTC EE adoption at one of these customers still used the terms of checkin/checkout for RTC SCM when discussing with us.
- RTC does NOT have a concept of checkout (although RTC does support resource locking – currently at the stream-level)
- Customer organization had started migrating to RTC EE almost 2 years before…
I see multiple drawbacks in this:
- Sticking to the terminology from a previous tooling in technical discussions about the capabilities of a newer tool is confusing. It basically assumes features that are not present in the product or, at least, not as is… As such this mismatch is a brake for adoption of the new features.
- Actually, I was even more concerned that this speech was coming from someone in charge of the adoption of our tooling. Assuming that most of developers in the customer organization would share the same terms…
As a result, I decided to clarify and made the point that in RTC, you load projects and components, you checkin change sets, and deliver them to a stream. This change in emphasis made it simpler to discuss business scenarios to be implemented in RTC EE (SCM here) at this customer’s.
A disconnect in terminology is more important than it seems:
- It introduces a gap compared to the proper concepts, which are basic prerequisites for elaborating the right workflows in RTC to implement a business scenario.
- It’s a good indicator that trainings and pilot phases missed at least some targets. Basically the “infusion” of the up-to-date concepts that match the tools used by developers on a day-to-day basis.
I came up with the following ideas:
- Answering customer initial questions is only ONE piece of the solution.
- Other aspects (not raised by customers) need to be addressed with the same attention:
- the return over experience in the training area,
- the return over experience in the pilot projects,
- the management of the change (from various point of views: organizational, managerial, etc. ),
- the adoption in general.
Taking the whole combination into consideration is key for success.
In the contrary case, an ultimate bad effect would be that SCM management simply do not trust their developers wrt. their usage of the new tooling. Possibly triggering… a second bad effect : having the SCM management to try enforcing too much process in the tool to substitute the lack of training of their developer. Not the right route anyway…..
As a recap, here are the simple things that should be kept in mind when adopting RTC / RTC EE:
- Even if adoption is accomplished in a stepwise manner, make sure everyone uses the RTC terminology asap in your organization.
- If you’re in a team focusing on adoption of RTC, make sure you replace questions/feedback/concerns of your developer in the correct terminology.