The primary activities of software globalization are internationalization, localization, and testing.  We will describe how each activity maps to the Scrum process.

Software Internationalization (I18n)

Software internationalization is the process of architecting and writing software so it will function properly in multiple countries.  It involves designing software in a modular fashion so new countries can be easily supported by swapping out language packs and software libraries, rather than rewriting lots of code.  This is a primary engineering task, and is well-suited to being done with Scrum.  Requirements from international customers tend to change rapidly, so using Scrum to address these requirements in an agile fashion is a great idea.

Functional Testing

This is functional testing that is specific to the internationalization process.  This verifies that generic features can be used by international customers, and also verifies features that are specific to certain international market segments.

Functional testing is done using international test data and localized systems.  This type of testing may use “pseudotranslated content”.  This is content that has been tagged to belong to a certain language and has strings that are of lengths typical to each locale.  This allows engineers to verify that international content will be handled properly after translation and integration.  Localized test data will use international character sets, and country-specific formats for numbering, currency, addresses, dates, phone numbers, names, etc.  Also, functional testing will test using any third party libraries or modules required by target locales.

Functional testing can be done as part of a standard sprint.  For global requirements, a Test Driven Development (TDD) methodology can be applied.  In this approach, tests are written for each locale before any code is written for that functionality.  Code is then developed against those tests.  The code is complete when all international tests are passed.   These tests are often automated to ensure that any future changes to the code will not break functionality for international users.

International English Version of Software

The result of software internationalization and functional testing is an international version of software.  Often, the first target language for software is English.  The international English version of software has been tested to work with all target locales, although the user interface and documentation is still in English.  Some companies may decide to ship this version of software to international customers immediately to gain feedback on the product.  It is important to note that unless the software has been tested for multiple locales using localized test data and systems, it cannot be considered an international version of software.  Remember, if you don’t test, there are definitely defects.

Localization

Localization is the process of adapting content, including user interface and documentation, to target locales.  This task is often done by outside firms staffed by native speakers in various languages.  This work is usually billed on a per-word basis, with additional charges for document preparation, glossary creation, and desktop publishing.  Costs can increase rapidly if many changes are made to the content during project.  For this reason, it is best to wait until the definition of the software is fairly stable before proceeding with localization.  You may decide to develop new functionality across several sprints, and then submit the content for localization after the features have stabilized somewhat.  Of course, your international customers are just as eager to get new features as those in your base locale, so this can be a tough decision to make.

Localization may be done in-house or by an outside firm, so you may or may not have direct control of the process by which it is done.  However, you can see that if your core engineering is managed with Scrum, it is best to submit content for localization after a sprint where the functions in question have reached some level of stability to minimize costs.

Localization Testing

There are several types of testing done during the localization process.  These include linguistic, cultural, and cosmetic testing.  These forms of testing are usually done by an outside firm, so the process by which they are done may not be under your direct control.  However, many firms do in-house cultural and cosmetic testing using marketing personnel or country managers from each locale.

Integration and Deployment

Once the content comes back from localization, it must be integrated with the code and tested.  This last stage is suitable for being done in an agile organization.  However, you should avoid adding new requirements to the integrated software before release that impact the user interface or documentation because this will incur additional costs for localization.

Final integration and user acceptance testing can be done in the final sprint before release.  This ensures that the product is ready for end users in each locale.

Balancing Agility and Cost

There are trade offs to be made between the flexibility provided by Scrum to change requirements with the costs of localization for each change.  The ideal approach is to develop new features for all international customers simultaneously and verify this functionality with prudent testing prior to localization.  Once the features have stabilized, they can be localized with minimal cost.  Although final integration and testing may be done by the same team as initial development, care must be taken to protect the localized code from changes prior to launch.  New feature requests should be submitted and queued for future localization and integration in the next sprint.  This suggests an idea for two parallel pipelines: one for new functionality that welcomes new requirements, and another pipeline for integration of localized software that is more sensitive to changes.  The number of sprints between localization rounds and the length of each sprint can be adjusted to balance these trade offs.

This is a diagram describing the software globalization process. This was developed for Aeontera, Inc. Developed in Adobe InDesign CS4. Click to download a PDF version.

Video promoting Ubicom’s QoS technology for streaming media over a wireless network. I produced this using Adobe Premier, Photoshop, and Cubase SX3. It even includes an original music track!

Data on 3G subscribers is from Mary Meeker’s ‘Internet Trends 2010′ presentation from Morgan Stanley. Created using Tableau Public visualization software.

What can we learn from these charts?   First, let’s look at ARPU growth.  It seems there is fairly broad pressure on ARPU across the board.  The big players, however, are holding their own around 0% change in ARPU YoY.  The highest ARPU is concentrated among US and European service providers.  Note that AT&T’s wireline business is listed separately from the wireless business.  The greatest drop in ARPU last year was felt by the smaller regional players in Asia and India.

Now let’s look at market cap for service providers versus blended ARPU and number of subscribers.  It is interesting to see that firms with the highest market cap are placed along a line that maximizes either ARPU or number of subscribers.  The small players in the previous chart likewise show up with low market cap, ARPU, and subscribers.  They clearly have a long way to go to reach the profitable horizon of the big players.

Segmentation

How do you define your current market segments? How do you group customers? By industry, sector, geography, job title, age? What are the unique challenges faced by each segment?

Use Cases

A use case is a specific way that customers get value from your product. Why do your current customers use your product? What problems are they trying to solve? Key use cases should be fully documented, including steps the customer takes to complete the use case. Many use cases are specific to a particular segment.

Functional Requirements

These are requirements that describe how your product works to an outside user. This may include APIs, standards compliance, electrical specifications, functions, or other key features. Are any of the functional requirements specific to a certain geographical area? Many interoperability standards for software and hardware are defined by standards bodies with specific geographical oversight.

Pricing

What is the pricing strategy for the current product? Do you use cost-based or value-based pricing? Is the price of your product mainly driven by a competitor? Are current competitors strong or weak in other geographic areas? Are there taxes or tarifs that affect the price in the current market? Any of these factors may change in the new market, so it is important to understand the current strategy.

Support Model

How do you support current customers? How easy is it for customers to get support when using the product? Are support personnel located near the customer, or do they even work in customer facilities? Where are call centers located? What are support hours and turnaround time? Do you offer support forums or chat clients for support? Do you have a knowledge database of support issues and resolutions that may be used by internal personnel or customers themselves? In what languages do you offer support?

Partners

Are key features or services provided by a 3rd party? What are the geographical capabilities of your partners?

Sales Channel

How do you currently sell your products? Do you sell direct, through distributors, or sales representatives? How do you train field personnel? What margins or commission are expected by each part of the channel? How long did it take to build relationships with the customer?

Requirements Management

How do you select what features and capabilities are added to your products? Is there a requirements database? How are new enhancements prioritized? How is the roadmap communicated to customers?

User Interface

How was your current UI (user interface) designed? What steps does the user take to complete key use cases? Do you have formal design guidelines for the UI?

Next Steps

You will discover many more requirements and issues with your business model as you begin to explore your new markets. However, by having your requirements and process documented, you can check your assumptions much more efficiently.

Nassim Nicholas Taleb discusses this at great length in his new book The Black Swan.

What is the point of science if it cannot be used to prove things? In The Structure of Scientific Revolutions, Thomas Kuhn argues that the entire concepts of proof and progress are problematic.

What is the point of thinking of things if we cannot prove that our ideas are true? Because ideas are useful. Science seeks not to prove things, but rather to build useful models.Models, such as the idea of the atom, are useful because they correctly predict observations. As we adopt new models and cast aside our old ones, the scope of observations we can predict increase. What matters is not the individual conclusions, but rather the method.

This is also true in the world of business. The received knowledge of market segments, product strategies, business models, etc can be limiting. If we apply some rigor to the problem, we may be able to tease out some insights that were not obvious before.

If we ignore our current assumptions and ask questions like:

• Why do we group customers together the way we do currently?
• Are there profitable segments hidden inside of submarkets or segment we have been serving more generically?
• Could a particular product offering be split or combined with other offering to better address needs?
• Is there a different distribution method that may be better suited to a submarket, promoting it to a full segment?

A personal pet peeve of mine is that many people in the technology business do not have mastery of even the basics of marketing theory.

I still have not met a technology marketing person that could correctly tell me the difference between a segment and a submarket.

Here are my definitions of the two terms:

submarket: a distinct group of customers

market segment: a group of customers that may be addressed by the same marketing mix

marketing mix: an offering to the market composed of a product or service and its associated price, promotion methods, and method of distribution

We start our market segmentation above by simply listing the different submarkets in columns. Any definition for submarkets are fine, as long as the members of each submarket are distinct from those in another. Next, we list the range of product or service attributes that we may want to offer. Then we populate the table by noting what attributes are applicable to each submarket. What we discover is that often certain product attributes are applicable to multiple submarkets! Submarkets that may be addressed in by the same product attributes are what we call segments. We can assign a name to a segment that encompasses each its submarkets.

Most often what happens is when I ask someone what a segment is, they recite a list of submarkets. When I ask them why those are segments versus submarkets, they say “everyone knows those are segments”. This can limit one’s thinking and prevent insights into the right marketing mix for the market.

I’ll discuss some ways to use segmentation to generate new ideas in later posts.