Localization and the Wild Wiki
By: Kåre Lindahl (Venga) - Venga Global
27 August 2011
Kåre Lindahl recreates how Schneider Electric created a Support 2.0 community between company and users to meet demands from an agile environment and localization requirements. Kåre elaborates on his GALA Webinar Series discussion with Stanislav Kalianov, Localization Manager at Schneider Electric IT Denmark ApS.
The evolution to Support 2.0
In the nineties and early 2000s, Support 1.0 was the buzz word. Customer support teams began using tools of the Web to provide documentation digitally. Now smart companies have evolved much further, shifting toward a relationship in which customers and end users are actively involved in the support process. Support 2.0 positions customer help squarely in a world of community interaction in which customers are in control.
Now the goal is to create communities in which sophisticated business-to-business customers and developers interact with the support teams using wikis. In such a scenario, the various entities within the community—the user, the technical writer, the customer support team—may influence the development team in real time, especially if the team is working in an agile environment. The pace is quick yet the quality must be high.
What does this mean to the localization team? Just as in other agile environment situations, the localization solution provider (LSP) must be involved early in the development process. The challenge for the LSP in the world of Support 2.0 is to provide translations and localization for the wikis in real time to ensure both users and developers can interact smoothly and quickly.
Schneider Electric, with the assistance of Venga, is doing just that. Exploring new frontiers of Support 2.0, localization and agile development, Schneider is creating a global community of developers, users, support personnel and translators, all working in real-time and in concert with one another.
Background on agile software development and its impact on localization
Agile software development shortens the time between the beginning and end of a project. To meet the demands of a specific customer more effectively, smaller product increments that deliver specific features have become more the norm. While there is still a place in software development for projects 12 to 18 months in length, agile’s penchant for two- to four-week sprints is making large projects go fast and small projects go faster.
This adaptive approach is people-oriented and allows for close interaction with customers. For language service providers, the impact is significant. In its recent report on localization in the agile environment, analyst Common Sense Advisory found: “The localization function is integrated more tightly with the development group in those organizations where it [Agile] has been implemented, according to 46.1% of our respondents. With smaller and more frequent hand-offs to localization teams (42.2%), service providers can start their work sooner in the process (31.8%). There is added communication required for virtual teams distributed worldwide to make the new process work (27.9%), but Agile has allowed 27.3% of respondents to improve the quality of localized products and 25.3% to increase their rates of simultaneous shipment (simship) of products in various languages.” (Source: “Global Product Localization,” Jun10, Common Sense Advisory, Inc.)
Combining agile with the Support 2.0 community
Meanwhile, customer support and help have advanced dramatically. Support 2.0 offers many benefits for developers, localizers and users alike. It allows for greater collaboration and better collection of user feedback that can then be fed back into the development process in real time. Byproducts of Support 2.0 include improved business-critical metrics and greater search engine optimization.
When agile is combined with Support 2.0, it is possible to have a continuous dialogue between the company and customer, ultimately providing better support for customers. The fact that customer input is valued and actually used in the development process can drive sales and, in the end, improve the bottom line.
Companies must consider Support 2.0 a community of equals. User generated content is a crucial element, not just an ‘add on’, and collaborative authoring is the norm. Social incentives encourage participation in the community and managers of the community are able to track content and community analytics. Ultimately, Support 2.0 should exceed customer expectations by providing the right information, in the right language, in the right format, available to the right people at the right time.
How Schneider Electric addressed the challenge: Agile + Support 2.0 wiki
Developers in Schneider Electric’s IT Business switched to an agile environment around four years ago. Schneider Electric is a global specialist in energy management offering a number of management solutions for data centers in areas of power, process and machines, IT, building and security. Software and documentation for IT business applications are typically localized into nine languages.
The localization teams work hand-in-hand with the development teams in the agile environment. In the initial attempt with Agile it took eight drops of localized user documentations and 15 drops of the user interface. By grouping content from multiple sprints, they were able to reduce the number of drops back to 2-3 per project.
Testing of the localized versions takes place early in the project. Almost every sprint contains something new to test – user interface, functionality, global-readiness, documentation, but it may not be necessary to translate results of every sprint. With Agile it is also possible that some of this material would be re-written.
However, in every sprint content is evaluated, scope of translation is measured and pseudo-translation takes place. It is easier to ask a developer to fix localization-related problems in last week’s code than in last year’s code, so Agile increases the potential for resolving these bugs in the programming phase rather than in the operation phase after release.
Unfortunately this approach of grouping sprint results did not work well for user assistance; in those cases, Schneider Electric found that a significant amount of words out of the total 20-30,000 words needed to be retranslated. Retranslation was grossly inefficient. Translations were happening too early; however, postponing translation of user assistance until later in the project would bring it too close (or sometimes past) the release dates.
The solution was to separate user assistance from the application. By moving user assistance online, Schneider Electric was able to begin translations later and release user assistance independently of the product releases. Moving user assistance online also gave the opportunity for adding user input, collaborative writing and essentially forming a user community around each product.
Ultimately the Schneider Electric team added the Support 2.0 wiki to have greater dialogue with the user community and to include user contributions throughout the agile and localization process. Support 2.0 also allowed for collaborative writing.
But how to do it? The concept is so new there was precious little precedent for Schneider to follow.
The Support 2.0 community was created around a product documentation wiki because the customer base interested in interacting and influencing development was advanced enough to adapt to that environment. Product documentation in this case was providing common ground for interaction. The Schneider Electric team had previously created documentation using structured DITA and already used an internal wiki for developers’ communication. When they found out that converting the user assistance content from DITA to a wiki was relatively simple using available and open sourced tools, the decision was made to go wiki.
The internal wiki had been developed using Atlassian Confluence; converting it to an externally facing community was straightforward. The content was converted from structured DITA to wiki, the team started to write directly in the wiki; applications were linked directly to the wiki.
Now as a new version of software is released, comments, and user contributions are available directly to the development and localization teams and fed right back into the process for the next version of product and user assistance.
Users can link directly with the developers, contribute to the writing and provide direct feedback.
To help users, developers and localizers alike adapt to the change, change management was also employed. Schneider Electric adapted the style guideline for writing to the wiki and is in the process of creating a guide for non-technical writers participating in the community. Internally, the shift to the externally facing wiki was not difficult because developers and writers had been using a wiki; the mindset simply needed to shift to accepting real-time edits and comments from the external community and to invite customers to become part of a new community.
Initially, it took some time for users to adapt to the wiki and begin seeing it as a real tool. But as communications and training about how to use it progressed, Schneider Electric saw a major jump in activity not only in wiki, but on all company external web resources.
For more information and graphics showing the Schneider Electric Support 2.0 community and localization of the content, please see the Venga Red Paper, “Localization and the Wild Wiki” at the Venga Knowledgebase. There also is a LinkedIn community to continue the discussion on wikis, localization and Support 2.0.
Kåre Lindahl is the CEO of the Venga Corporation and has over 20 years' globalization experience working in the ERP/SaaS industry. He has served in executive roles within global information content development and globalization for such companies as Venga, Oracle, PeopleSoft, JD Edwards, and Hogia, which gives him a unique perspective from from both the client and vendor side. Based on his work in globalizing the information content development chain and localization of ERP and SaaS offerings, he has extensive first-hand experience working with requirements from most countries around the globe. Kåre grew up in Sweden and lived in the UK for 10 years before relocating to the US in 1995 to join Oracle’s applications division.