Training materials for the workshop Agile Localization Fundamentals: An Integrative Approach @ Localization World London 2013. All rights reserved

1. AGILE
LOCALIZATION
FUNDAMENTALS
LOCALIZATION WORLD CONFERENCE - LONDON
JUNE 12, 2013
Alberto José Viralhadas Ferreira.
alberto.viralhadas@gmail.com

2. WHAT IS AGILE?
AN OPEN METHODOLOGY, AN ENABLER OF SELF-
GOVERNANCE OR A FACILITATOR OF CONTROLLED CHAOS?
Agile: “the quality of being
Agile; readiness for motion;
nimbleness, activity, dexteri-
ty in motion”.
Evolving from Lean manufac-
turing first, Agile has been a
trend in the software deve-
lopment industry for the past
decade. Its promises of in-
creased delivery results has
been an appealing factor for
many companies who have
decided to implement a reac-
tive mindset for sustainable
user-focused projects.
The Agile manifesto (Agile-
manifesto.org) inaugurated
over a decade ago the need
to focus on the basics of sof-
tware development with a
human slant. The four prin-
ciples came like a wave over
the traditional way that sof-
tware was developed in the
21st century.
As a incremental and itera-
tive development, it is also
multifaceted. The founder
of the Agile Alliance, Jim Hi-
ghsmith, creator of the Adap-
tive Software Development
method, has defined the Agile
hallmarks as follows:
1.The ability to deliver so-
mething useful and of value
to the client.
2. Committed stakeholders.
3. Leadership-collaboration
style.
4. Build competent, collabo-
rative teams.
5. Team decision making.
6. Use short timeboxed itera-
tions for quick delivery.
7. Encourage adaptability.
8. Champion technical excel-
lence.
9. Focus on delivery activi-
ties, not process-compliance
activities.
The emphasis of Agile is on
accelerated development and
deployment with low risk of
change and budget due to
its emphasis on empirical
processes and constant vi-
sibility of work progress. It
also demands open sharing
of information in a levelled
hierarcy.
Agile is often positioned as
an opponent of or replace-
ment for the traditional Wa-
terfall project management
methodology. Waterfall is, by
definition, a managed and he-
avily controlled process that
privileges a linear, sequential
process. It determines requi-
rements well in advance and
is primarily rational.
On the other hand, Agile is an
opportunistic feedback-loop
“free” methodology that em-
phasizes simultaneous and
overlapping processes.
Agile also aims to avoid the
creation of silos, with requi-
rements being cast “over the
wall” between development
team and product/project
management teams. Reviews
are held often and with as lit-
tle bureaucracy overhead as
possible.
IN AN AGE OF INCRE-
ASING COMPETITIVE-
NESS IN THE WORLD
OF SOFT WARE DE-
PLOYMENT, A PROCESS
FRAMEWORK THAT
ALLOWED COMPA-
NIES TO REACT MORE
SWIFTLY TO RAPID RE-
QUIREMENT CHANGES
WAS CREATED: AGILE.
HOWEVER, ITS REPER-
CUSSIONS IN THE SOF-
T WARE DEVELOPMENT
WORLD AT LARGE POSE
NEW CHALLENGES TO
COMPANIES.
02 AGILE LOCALIZATION FUNDAMENTALS - AN INTEGRATED APPROACH

3. WORKSHOP CONTENTS
Agile has established itself as the premier methodology framework for software development process. Scrum, XP,
Lean, and many other variations of the Agile methodology all rely on the same basic principles: release iteratively, work
in a more integrated way, speed up delivery through user-focus. It’s flexible enough that you can adapt it to your needs,
yet it provides enough a framework solid enough in order to control the “creative chaos” at its core.
The focus of this half-day workshop will be to introduce practical and hands-on strategies and techniques for in-house
localization teams working in the software development industry. In order to be able to respond to the fast-paced
delivery required in Agile software development environments. By the end of the workshop, you will have a broader
perspective on how to implement your Localization process in the ever-changing tide of requirements and customer
expectations – and still make every word count.
PART I Centripetal Forces: Agile Principles
• Agile: what it can mean for you
• Defining Agile Localization
• Assessing critical value stream issues
• Establishing vertical collaboration
PART II The Domino Effect: Localization Requirements in an Agile Process
• Using Personas to define your audience
• Source Text versus Master Locale
• Identify design critical issues
• Optimize estimations
• Establishing acceptance criteria
• Optimize resource management
PART III Chain Lightning: Story-Based Internationalization
• Auditing design for optimal localization
• Auditing source text localizability methodology
• Making the most out of style guides and terminology
• Adapting and optimizing text for translation
• Agile translation management
PART IV Critical Mass: Testing and Deployment
• Manual testing versus continuous integration
• Drafting localization test cases
• Testing strategies

4. IMAGE 1
In an Agile process, like Scrum, or Kaizen,
all stakeholders are affected by the actions
and outcomes of the team. Localization
plays an essential role in this synergy.
IMAGE 2
An abriged version of the Agile Manifesto
basic principles.
AGILE LOCALIZATION
A STRATEGIC PEER
Localization is frequently linked to the end-of-chain stage, interspersing time
constraints with role diffuseness, leading to severe quality compromises in
most cases. Since Agile demands constant proactiveness, responsiveness
and the ability to adapt to changing situations, the production process is ef-
fectively never over as long as the project is on-going, which means that late
requirement change is an expected and even a desirable cog in a chain that
relies on communication and stable interchange of information. While mono-
lithic development and requirement unspecificity often compromise results in
traditional development structures, Agile’s focus on productivity and decom-
posable work items enables a richer and more quality-oriented development
process.
In this sense, Localization is an essential partner. Corporate-wide linguistic
strategy is a must in this case and Localization departments can help drive
this effort by supplying much-needed geopolitical assessments and asses-
sing the effort behind localizing a given product in a given language.
.
“GRAND PRINCIPLES THAT GENERATE NO ACTION ARE MERE VA-
POR. CONVERSELY, SPECIFIC PRACTICES IN THE ABSENCE OF
GUIDING PRINCIPLES ARE OFTEN INAPPROPRIATELY USED.”
(JIM HIGHSMITH, AGILE PROJECT MANAGEMENT: CREATING INNOVATIVE PRO-
DUCTS, 2ND ED.)
Localization is often thought of as a more or less sophisticated translation
management process applied to software localization. Not only is this untrue,
it is dangerous in Agile environments.
From a design point of view, localization must be one of the stakeholders in
the User Story if it is determined that it affects any kind of text resources in
the application, either directly (i.e. text changes) or indirectly (i.e. impact on UI
design or graphic arrangement). From a maintenance point of view, this relies
on pre-planning and resource assignment from an early stage. Localization is
the primary link between a software application and its international marke-
tability, and should be taken into account as early as possibly in the software
development process.
1
04 AGILE LOCALIZATION FUNDAMENTALS - AN INTEGRATED APPROACH
2

5. THE BASIC PRINCIPLES OF THE AGILE MANIFESTO
Individuals and interactions over processes and tools
“Build projects around motivated individuals. The most effi-
cient and effective method of conveying information to and
within a development team is face-to-face conversation.”
Working software over comprehensive documentation
“Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.”
Responding to change over following a plan
“Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage. “
01
02
03

6. For companies in transition from waterfall to Agile, User Stories
can follow an acceptance criteria and function like small, mana-
geable requirements. For all the emphasis on de-regulation and
adaptivity, Agile is actually a fairly well-bound field with a set of
principles that can be replicated throughout projects.
Drafting User Stories
A user story describes functio-
nality that will be valuable to
either a user or purchaser of a
system or software. User stories
are composed of three aspects:
• a written description of the story used for planning
• talks about the story that serve to flesh out [its] details
• tests that convey and document details and that can be used
to determine when a story is complete.
User Stories Applied - For Agile Software (Mike Cohn)
Any User Story implemented in a product has several compo-
nents that demand different expertise from a multi-specialized
team, which can be either contained in different departments
or, optimally, working exclusively together on given parts of the
product. In this setting, product localization is a concern from
the get-go thanks to constant involvement with the core deve-
lopment team and product stakeholders. Project management
duties are distributed and the Product Owner’s vision is instru-
mental in the whole process.
Agile Roles
The naming of roles often varies between different Agile me-
thodologies. There are three basic actors: the Customer, the
Developer and the Team Facilitator. For Scrum, the Customer
can be a combination of the Product Owner and the end-custo-
mer. They specify the infal requirements. Specifically, the Pro-
duct Owner creates “the project’s initial overall requirements,
return on investment (ROI) objectives, and release plans [and]
is responsible for using the Product Backlog to ensure that the
most valuable functionality is produced first and built upon”
(Agile Project Management with Scrum, Ken Schwaber).
Meanwhile, the “Scrum Master drives the scrum activity, espe-
cially in the beginning of the project [...] to counteract obstacles
to task completion. [...] As a fa-
cilitator, the Scrum Master will
keep the various scrum activi-
ties on task by invoking the ap-
propriate rules and procedures.”
(Scrum Project Management,
Kim H. Pries, Jon M. Quigley).
Iterations and Reviews
“An iteration typically lasts one to four weeks and has four di-
stinct phases: Planning, Development, Review, Retrospective.
During the Planning phase, the Product Backlog items to be
developed during the iteration are selected, and the goal of
the iteration is formulated. During Development, each require-
ment selected for the iteration goes through definition, coding,
and two types of testing.
Automated unit tests are written to confirm the new code wor-
ks as designed. Once unit testing is complete, acceptance or
business testing occurs to confirm that the requirement meets
the functional needs of the user.
During the Development phase there is also a daily status me-
eting known as the daily standup. In this meeting, each team
member states what they did the previous day, what they are
going to do today, and identifies any existing or foreseeable
roadblocks.
When the iteration nears completion, a review meeting is held
with all stakeholders to demonstrate the new software and
receive feedback on it and the functionality that has been de-
veloped. The last phase, or Retrospective, is a postmortem for
the team to discuss how the process could be improved.” (Agi-
le Excellence for Product Managers, Greg Cohen).
THE TRADITIONAL WATERFALL METHOD
TENDS TO RELY ON DELIVERABLE HANDED
DOWN THE PRODUCT DELIVERY CHAIN LATE
IN THE PROCESS. ITERATIVE DEVELOPMENT
CANNOT RELY ON THIS PARADIGM.
THE LIFE OF A USER STORY
ACTORS AND STAKEHOLDERS IN AN AGILE PROJECT
06 AGILE LOCALIZATION FUNDAMENTALS - AN INTEGRATED APPROACH

7. IMAGE 1
A standard Agile workflow.
Source: http://en.wikipedia.org/wiki/File:Agile_
Software_Development_methodology.svg
IMAGE 2
Roles in the typical Agile team. Note that
the Technical Owner is sometimes the
Software Architect or Team Lead
Source: http://www.netobjectives.com/blogs/
product-development-team-and-voice-
customer
1
2

8. DESIGN
LOCALIZATION AND DESIGN ARE
NOT SEPARATE WORLDS.
08 AGILE LOCALIZATION FUNDAMENTALS - AN INTEGRATED APPROACH
BELOW
The process of drafting User Personas as
applicable to localization requirements.
IMAGE 2
String typology of a typical software project.
Text is an essential part of a complete multimedia
system that includes image and text. Visually and
linguistically, text plays a major role in the user’s
perception of a product. The most refined and so-
phisticated UX can be wrecked by careless localiza-
tion and haunted by issues and bugs. Fonts are lost,
carefully complimentary labels suddenly ap- pear
juxtaposed, HTML is improperly adapted to target
locales.
Therefore, internationalization is key to a consi-
stent user experience in a multilingual product. In-
ternationalization defines the set of processes and
techniques that are implicated in making a product
capable of adaptation to different cultures. This
is where UX implementation is at its trickiest. No
sound internationalization- friendly design can be
adequately implemented without an accurate stu-
dy of localization prioritization. Define which lan-
guages and cultures you want to localize into and
include both immediate priorities and future plans.
This will enable you to optimize layouts for cultural-
ly-sensitive graphics and indications or – optimally
– to change requirements in the light of new market
strategies.
Discuss with the Product
Owners on the User
Personas used in the
project. Synchronize
expectations and focus targets.
s
Ow
e
o
t
s
O
e
o
t
s
O
e
o
t
s
O
e
o
at
s
O
e
o
at
s
O
e
o
a
s
O
e
o
a
s
O
e
o
a
s
O
e
o
a
s
O
e
o
a
s
O
e
o
a
s
O
e
o
ta
s
O
e
ro
ta
s
O
e
r
ta
s
O
e
r
ta
s
O
e
r
cta
s
O
e
r
cta
s
O
e
r
ct
s
O
e
r
ct
s
O
e
r
ect
s
O
e
r
ect
is
O
e
pr
pect
is
O
Pe
p
pect
is
O
P
p
xpect
is
O
P
p
xpec
is
O
P
p
expec
i
O
P
p
expec
i
O
P
p
expec
i
O
P
p
expec
i
O
P
p
expec
i
O
P
p
expe
i
O
P
p
expe
i
O
P
p
expe
i
O
P
p
exp
i
O
P
p
exp
i
O
P
p
exp
Di
O
P
Di
O
P
Di
O
P
D
O
DDDDDDDDDDDDDDDDDDDDDDDDD u
ne
na
Sy
d foc
u
ne
na
Syn
d foc
u
ne
na
Syn
d foc
u
ne
na
Syn
d foc
u
ne
na
Syn
d focu
u
ne
na
Syn
focu
u
ne
na
Syn
focu
u
ne
na
Syn
focus
u
ne
na
Sync
focus
u
ne
na
Sync
focus
u
ne
na
Sync
focus t
u
ne
na
ync
focus ta
u
ne
nas
ync
ocus tar
u
ne
nas
ynch
ocus targ
u
ne
nas
ynch
ocus targets.
us
ne
nas
ynch
ocus targets.
us
ne
as
ynch
ocus targets.
us
ne
as
ynch
cus targets.
us
ne
as
ynchr
cus targets.
us
ne
as
nchr
cus targets
us
ne
as
nchro
us targets
us
er
as
nchro
us targets
us
er
as
nchro
s targets
us
er
as
nchro
s targets
us
er
as u
nchron
targets
us
er
as u
chron
t t
us
er
as u
chroniz
us
er
s u
chroniz
us
er
s u
chronize
us
ers
s u
chronize
us
ers
s us
hronize
us
ers
s us
hronize
us
ers
s us
hronize
us
ers
s us
hronize
us
ers
use
ronize
uss
ers
use
ronize
uss
ers
use
onize
uss
ers
use
onize
ss
rs
used
onize
ss
rs
used
nize
ss
rs o
used
i
ss
rs o
used
ss
rs o
used
ss
rs o
sed i
ss
rs o
sed in
ss
s o
sed in
ss
s o
sed in t
ss
s on
ed in th
ss w
s on
ed in the
ss w
on
ed in the
ss w
on
d in the
ss w
on
d in the
s w
on t
d in the
s w
on t
n the
s w
on th
th
s w
on th
th
s w
on th
h
s wi
on the
s wi
n the
wit
n the U
wit
n the U
wit
n the Use
with
the User
with
the User
with
the User
with
the User
with
the User
with
he User
with
he User
with t
U
with t
U
ith th
U
ith thth theth theth the Ph the Prh the Producth the Productthe Productthe Productthe Productthe Producthe Producthe ProductP d tP d td
USER PERSONAS
Research on the focused
users and their experience
and cultural background.
Interact with software
users (if possible, with
interviews or surveys).
Synchronize with
Marketing.
Draft specs for
User Personas based
on linguistic ability and
goals and attitudes.
Draft guidelines
for Personas based
on methodology:
Quantitative (large
sample of interviews)
or Qualitative (small-scale
research).
Draft the Persona with
description, photo,
domain-specific data,
like literacy,
language proficiency
and previous experience.
Bring the persona to life:
think of it as psychological
profile.
Sync with Product Owner.
Update internal
style guide and
localization requirements.
Use - Repeat - Iterate.

9. GUI CONTROLS
INFORMATION
MESSAGES
LOG MESSAGES
ERROR MESSAGES
USER PROMPTS
INTERNAL
CODE & MARK-UPS
2

10. HOW FREQUENTLY SHOULD
WE HAVE LOCALIZED BUILDS?
For testing purposes, the stock
answer is “as often as the master
builds”. Invest on MT for pseudo-
localization in order to test inter-
nationalization requirements early.
For release, agree with the product
owner on the frequency for exter-
nal testing.
SHOULD LOCALIZATION BE A
PART OF THE BURNDOWN CHART?
Localization is not a service, but
an accountable effort held in the
sprint’s overall development. LSP
effort should also be tracked, pre-
ferably as Tasks under the relevant
User Stories,. This will enable you
to predict effort and get metrics for
internal and LSP evaluation.
SHOULD WE USE AN AGILE
PROCESS FOR TERMINOLOGY?
It depends on the project nature.
Terminology is never frozen, but
it should be optimally standardi-
zed with devoted effort before the
translation stage. Get customer
feedback and define approving ro-
les clearly. Automate tool-based
terminology extraction.
BETWEEN HAND-OFFS, INTERNAL REVIEWS, AND
LOCALIZED BUILDS, THE TRUTH LIES.
HERE ARE SOME OF THE MOST OFTEN ASKED QUE-
STIONS IN AGILE LOCALIZATION.
SHOULD WE ESTIMATE BA-
SED ON DEVELOPER EFFORT?
Never. Even the simplest GUI im-
plementation can have major re-
percussions in the internationa-
lization front. A combo box can
require a complex layout restruc-
turing in builds for right-to-left
scripts. Audit User Stories inde-
pendently and communicate often.
SHOULD WE RELEASE LOCALIZED
VERSIONS SIMULTANEOUSLY OR
PRIORITIZED? In most cases, the
testing done for the Master Loca-
les spots most of the internatio-
nalization issues that abound in
the localized versions. Test and
release simultaneously whenever
possible. The global market does
not wait for latecomers.
HOW OFTEN SHOULD WE SEND
HANDOFFS TO OUR LSP? In gene-
ral, it is more cost effective to do re-
gular deliveries than sending mul-
tiple small translations projects.
A more complex workflow with a
first-run translation and second-
stage correction is also possible.
Use MT to leverage testing with
pseudo-localized builds.
10 AGILE LOCALIZATION FUNDAMENTALS - AN INTEGRATED APPROACH

11. SHOULD WE INTEGRATE LSP IN
REVIEW MEETINGS?
No. However, Sprint Review reports
can be drafted with key information
on specific issues that propped up
during the sprint (delays, language
quality issues, bad file handling).
Similarly, informal meetings can
be held with the LSP throughout
the sprint. These are essential per-
formance and reporting aids and
should be handled systematically.
SHOULDWETRAILDEVELOPMENT
IN SEPARATE ITERATIONS? A de-
lay in sprint assignment can be
useful and benefit the language
quality for immature workflows. It
depends on the internally agreed
Acceptance Criteria. However, be
aware that this directly affects si-
multaneous shipping and the ove-
rall testing for the entire project. If
at all possible, localization should
be handled within the iteration.
HOW SHOULD THE ACCEPTANCE
CRITERIA INTEGRATE USER OPI-
NION?
The beauty of iterative deve-
lopment is that change requi-
rement is an integral and even
desirable part of the software de-
velopment cycle. The Acceptan-
ce Criteria can be redefined with
user opinion after the initial itera-
tions. Prioritize feedback based on
agreed User Personas.

12. 12 AGILE LOCALIZATION FUNDAMENTALS - AN INTEGRATED APPROACH

13. TERMINOLOGY
OR, THE ART OF
CONSISTENCY.
MAXIMIZE YOUR
TRANSLATILIBITY.
Use consistent, simple, and task- focused
terminology.
Use plain language (in advanced workflows,
this can be complemented by implementing
Simplified English as source for transcrea-
tion).
Space for culture-adapted text should not in-
troduce inconsistencies.
Idiomatic expressions should be concep-
tualized and consistent (e.g. interjections,
expressions, proverbs should be tagged as
such and used in a consistent context).
Avoid incomprehensible technical jargon.
Use plain language (in advanced workflows,
this can be complemented by implementing
Simplified English as source for transcrea-
tion). Avoid excessive wordiness. Use pri-
marily short sentences with only one or two
phrases.
Avoid repetitive text and branding.
Conciseness is essential in order to convey
your message effectively. Use “more” when
comparing and avoid stacking or hyphena-
ting words in your messages. Punctuation
should be used sparingly.
Always use the full form for new terms show-
ing in the interface.
Present the abbreviation or acronym in pa-
rentheses following the fully spelled-out
form. Avoid contractions and abbreviations.

14. 14 AGILE LOCALIZATION FUNDAMENTALS - AN INTEGRATED APPROACH
1
2
3
When creating a test strategy, you have to accurately define the QA
processes and their integration in the lifecycle. An early involvement
and understanding of specs, requirements and the product scope will
feed the production of an accurate test matrix, complete with pre-as-
sumed configurations and locales, starts at the User Story creation
level, where the product scope actually materializes.
At its drafting, the User Story already needs to already integrate loca-
lizability and internationalization concerns, by way of specific lingui-
stic and functional testing. These criteria are an integral part of the
final acceptance process and the successful implementation of the
User Story must be predicated on its fulfilment.
Regression must be mitigated through unit testing and automation
as early as possible. Given the tight timelines involved in Agile deve-
lopment, preliminary localizability testing must be done in advance
before the implementation of the User Story in order to reduce effort
with later regression and workflow adjustments.
AGILE TESTINGQA IS NOT AN OPTION WITH RAPID DEVELOPMENT.
LEARN HOW TO ESTABLISH LOCALIZATION TESTING
STRATEGY.
WHEN CREATING A
TEST STRATEGY, YOU
HAVE TO ACCURATELY
DEFINE THE Q A PRO-
CESSES AND THEIR
INTEGRATION IN THE
LIFECYCLE. AN EARLY
INVOLVEMENT AND
UNDERSTANDING OF
SPECS, REQUIREMENTS
AND THE PRODUCT
SCOPE WILL FEED
THE PRODUCTION OF
AN ACCURATE TEST
MATRIX, COMPLETE
WITH PRE-ASSUMED
CONFIGURATIONS AND
LOCALES, STARTS AT
THE USER STORY CRE-
ATION LEVEL, WHERE
THE PRODUCT SCOPE
ACTUALLY MATERIA-
LIZES.
COSMETIC TESTING
Truncated strings
Content design
Branding consistency
Layout
Excessive text
FUNCTIONALITY TESTING
Installation procedure consistent
Menus and hotkeys duplicate
Functionality replicable in all languages
Input correctness
Correct character encoding
LINGUISTIC TESTING
Capitalization
Cultural adequacy
Spellchecking
Style/register
Terminology

15. The implementation of different testing methodologies
depends on the resource availability and the project
needs. On the tool level, an integrated test and deve-
lopment environment, as well as common issue tracking
systems, is a pre-requirement for valid reporting, as well
as the configuration and implementation of specific au-
tomatic testing.
Specifically, automation is essential on the source code
level, where the semantics of string implementation are
initially checked. In a test-driven development envi-
ronment, development unit tests are routinely run du-
ring program compiling and building, and can already
provide reports on missing and incorrectly implemen-
ted application strings. Automation can also assist with
specific user interface issues, as well as functional text
issues such as script rendering, blacklists and hotkeys.
Agile focuses on usability that brings value to the end-
user, so localization testing should primarily focus on
helping to deliver this value, as it is defined in the pro-
duct scope by the stakeholders. In a continuous de-
ployment environment, the emphasis should rely on
preventing the occurrence of problems and reducing
regression costs, so pre-planning, early engagement
and a solid communication flow are key to the testing
process. Testing is not a separate focus, but rather an
essential component of everyday methodology, and the
organic feedback loop between result, assessment and
adjustment enforced by Agile can be a powerful tool for
producing quality multilingual software prepared for the
demands of a global market.
BELOW
An example of an Agile test strategy.
PAGE OPPOSITE
As the iteration progresses, testing spikes as different types of testing kick in for different
project priorities.

16. Alberto Ferreira
Charlottenstrasse 15
Friedrichshafen
Germany
t +49 15 222 486 556 t twitter.com/AViralhadas
e alberto.viralhadas@gmail.com
GET IN TOUCH
PROJECT MANAGEMENT.
LOCALIZATION RESEARCH.
CULTURAL ACCESSIBILITY.
GLOBAL SERVICES FOR A GLOBAL WORLD.
LOCATION
Currently based in Bodensee,
Germany.