The agile software development method, when understood properly and fully embraced, can do wonders for teams working on the language localization components of any agile software localization project.
Without diving too deeply into the foundations of agile (read the Agile Manifesto opens in a new window and dig into the twelve founding principles opens in a new window if you’d like more information), agile software development can be thought of as a framework that fosters self-organized, close-knit teams in continuous communication with one another, and close cooperation between the development and commercial sides of any given project. The aim of a software localization service utilizing agile is to build quality software quickly (through incremental sprints) that meets the end user’s multilingual needs by rolling out translated and localized content when software and software updates are released.
When contemplating this process, rather than think of localization services as a separate part of the main development workflow, agile localization should be thought of as an integral part of the entire project, incorporated into almost every step along the development path.
Understanding the Team-Oriented Nature of Scrum Sprints
What exactly is Scrum (in case you don’t already know)? “Scrum is a type of agile,” Mike Cohn, an expert on the subject from Mountain Goat Software, explains. “Think of agile as being like the word ‘refrigerator.’ There are a lot of brands of refrigerators —Samsung, LG, Kenmore, Haier and so on. Scrum is just a brand of agile.”
Software localization fits into the Scrum framework as development teams try to finish a set amount of functionality with every sprint, while also including localization in the sprint process. The heart of a sprint, according to the Scrum Guide opens in a new window, is “a time-box of one month or less during which a ‘Done,’ usable and potentially releasable product Increment is created.” Sprint duration should be constant throughout the development process, with a new sprint beginning “immediately after the conclusion of the previous sprint.”
When looking at translation and agile localization as part of the process that goes into creating multi-language software, teams need to take localization into account pretty much from the get-go, rather than later in the game. “Ideally,” Cohn says, “that means localizing the new features is also done within the sprint.”
Scrum is very different from traditional, more linear “waterfall” software development approaches, where software localization services aren’t brought in until later in the process. When agile localization services are brought in toward the end of a project, they have to get up to speed in a hurry, and often have to handle the bulk of the software translations in one go, while sometimes lacking vital information (i.e. a few steps behind the rest of the team) needed to complete the project on time.
Integrate Language Localization Development Teams Early On
Rather than waiting until the software development process is already under way, a core team comprised of smaller teams (software, localization, business, marketing, etc.) taking advantage of the agile method, along with Scrum, can reap many benefits from constant dialogue and interdisciplinary teamwork. This methodology allows agile localization experts and translators to spot language and cultural problems, plus other inconsistencies early on, which lets programmers deal with these issues as they arise. An agile sprint that addresses localization issues on a consistent basis is the goal that should be aimed for here.
If and when software localization services are integrated into as many steps along the developmental path as possible, some significant changes crest the horizon for developers and language localization experts who’ve never worked with a scrum master (the main architect of an agile development team) before, or dealt with the self-organizing nature of a team committed to agile. It can take some getting used to, but the advantages of the agile method can save businesses time, get their software updates ready to push out sooner, and ensure the release of high quality products and higher customer (end user) satisfaction.
Implementing Agile Software Localization
“A lot of organizations get hung up waiting for the perfect project on which to pilot agile,” Cohn says. While he acknowledges how tough adopting agile, or any organizational change can be, Cohn suggests that for those tempted by agile, they ought to dive right in. “The perfect project is the one you’re on right now, especially if that project is facing a deadline you probably won’t make.”
From creating user stories (short, simple descriptions of desired software features) and dealing with a product backlog (a list of prioritized tasks) to sprint planning and the sprints themselves, if a software localization service is rooted deep inside the agile framework from the very beginning, it will have a greater chance of contributing to on-time software delivery and success.
Implementing the agile software development method means the localization workflow will have to be reconfigured from older development styles, along with likely changes to how automated tasks are handled, allowing for a continuous transfer of information between different teams involved on a project. These changes usually require some initial work, but when development teams and localization services truly commit to agile, a foundation is laid for a close, ongoing partnership among team members that can redefine, and improve how multilingual software is created and updated.
If you are looking for a team that can help you develop or implement an agile localization process, consider us for this task!
This whitepaper presents you with straight forward metrics that will help you determine the budget and schedules needed for translation and localization projects. Don’t request a bid without reading it first! Get it now for free!!