|
|||||
Supporting Agile in global-scale localizationAgile has become an important methodology for development teams looking to avoid high-overhead heavyweight software development methodologies. Focusing on iterative development and tight team-work between technical and business teams, Agile projects deliver working software revisions every 6-8 weeks. Because of the nature of Agile projects, truly supporting global-scale localization can be challenging. What is “Agile”? Agile evolved as a reaction to heavyweight software development methodologies – especially “waterfall” methodologies. Agile is not a formal standard but an evolving interpretation of the Values and the more fluid Principles. Although there are many facets to an Agile project, three concepts illustrate the difference between Agile and other methods; adaptability, iterations and collaboration Adaptability Iterations Collaboration
Although many translators and translation companies work successfully with Agile clients that isn’t the same as being integrated with Agile philosophies. Collaboration between team members is a key element of Agile typically with teams located in close physical proximity. Since localization production is outsourced to teams that are global in nature care must be taken to foster close collaboration opportunities between the Agile development team, the localization project management team and the dispersed translation production team. To be Agile a a centralized “core” of leads have to work in close proximity. The disciplines of Project Management, Localization Engineering, Linguistic Analysis, Testing and Digital/Desktop Publishing as well as QA /QC management have to be managed in a collaborative team fashion. Beyond this core-knowledge team, care must be taken to work on a daily basis with the distributed translation teams in country using whatever means are necessary. The iterative nature of Agile also brings problems. Traditionally localization has been project centric and largely monolithic especially in the larger localization companies. To support Agile the localization team has to become accustomed to short timescales, small drops and relatively small changes within large code bases. In addition to the changes in working practices to support small iterations the localization team has to be able to leverage technology beyond simple application of TMs to discern what has changed and what needs to be localized. Overall the implications for translation are that the translation team must be able to execute smaller incremental changes in strings, prompts and content which have to be completed within the time allowed for successful release of the iteration. Especially significant are the implications for testing – functional testing needs to operate seamlessly within the iteration requiring very close co-working between the test team and development team. and finally… Agile has a great philosophy behind it but the way Agile teams work don’t mesh directly with the way localization works. It takes some care and attention – but mostly flexibility – on the part of the localization team but with some creative thinking we all learn how to support Agile customers better and more in line with their development philosophy. Any posts from those of you experienced in localizing in an Agile world would be most appreciated. 2 comments to Supporting Agile in global-scale localization |
|||||
|
Copyright © 2010 Localization Best Practices - All Rights Reserved |
|||||
I would be very interested in any comments on this topic.
In my company, the whole of production is turning towards agile development also. I am responsible for the localization of my BU’s software and trying to get a feel with agile development and linguistic localization, or even becoming an agile department ourselves.
Hans -
If you are software exclusive in your department, agile development can really help you localize the system. There are several ways to specifically incorporate Agile into this project:
First, get superior level buy-in prior to beginning these changes! Preaching Agile and living Agile are two different things, and sometimes management’s “overall” view of the business forgets to take the day-to-day needs into account. Getting management support up front will ensure a better success rate of using “agile” in this project.
Second, break the project timeline down in to iterations. David mentions them above, and they are quite useful. Take a look at the timeframe you are being given to complete the project. Determine if it is feasible to complete an entire project in the given amount of time. If it is, gather your team and decide how you want to break the deliverables up into 2-3 week sessions. Write out what are included in the iterations and post them on a board that is public, so everyone is always able to see it, including management who need to understand what goes in to making the overall project happen. During those iterations, the team is solely focused on that specific part of the software. This is why managerial buy-in is important up front. Keeping the team dedicated can be hard in the realities of the business world. Having a champion in your manager makes it easier to pushback on requests and forces executives to prioritize, versus say “just get it done.” Typically, software iterations are broken down by functionality or, in the case of localizing, languages. If you are localizing the software into just a few languages, it may be easier to assign each language team with completing the functionality simultaneously.
Lastly, you need to set up daily meetings/conference calls with the key team members. Spend 5 minutes tops asking two questions:
1) Where are you at in the project?
2) What, if anything, is acting as a roadblock?
As the leader of the group, you are accountable for getting the roadblocks removed (much easier if you have managerial buy-in prior to starting the project).
I recommend in-person meetings, as a group if possible. Keep them short. The team needs to have time to work on the iteration to ensure completion. If you find the iteration is going to be too short, thesse meetings give you fair warning and a chance to approach management with either a) change in timeline, or b) request for additional resources/reduced roadblocks.
These are a few things your department can do on a long-term basis to move in an “Agile” direction. I agree with David that the actual translation duties are more difficult to work with in an Agile way.
I hope this helps, Hans