If you are working in software, app, or game development, for sure you came across Agile or Waterfall methodologies. Before jumping into the localization specifications, let’s briefly overview them.
What is Waterfall model?
Waterfall is a software development methodology in which the major activities (requirements, design, coding, and testing) are done in phases and executed serially. Each phase is gated, and it’s not possible to get to the next phase without fully completing the previous phase. This brought a sense of organization and engineering into software development. It would have worked wonderfully if we can fully define all the requirements before starting the coding phase; alas, this wasn’t true. This still isn’t true for many projects.
Waterfall methodology brought frustrations to many projects. It had such limitations as:
- There was a significant lag between design phase and the time the software was put to actual use.
- Many projects were canceled partway through.
- Some projects (though completed) were discarded because they did not meet business requirements even if they met the original requirements.
What is the difference between Agile and Waterfall?
Agile methodology came to life because of the shortcomings of the waterfall methodology.
In contrast with waterfall, Agile practice does not require all the software’s feature details to be defined at the outset. Instead, it focuses on the frequent delivery of working software. It documents the requirements to the extent that’s good enough and specific enough for coding to begin.
It’s common for Agile teams to time-box two weeks (sprints), implement as many features as they can within it, then show-and-tell. Then, go at it again for another two weeks, show-and-tell, rinse, and repeat, until all the features have been implemented. This time-boxing practice became known as a “sprint”. The idea is to produce a working build every two weeks, work out the kinks until everyone is comfortable with the stability and features.
The basic tenets of Agile can be described in the Agile manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- User collaboration over contract negotiation
- Responding to change over following a plan
Localization using the Waterfall methodology
The Agile movement took the software development world by storm — you can tell by the number of consultants who hung shingles offering Agile consultancy services — but localization remained an afterthought. To be sure, the dev teams went about their stand-up meetings, sprinted fortnightly, and breezed through every show-and-tell; but they still did the localization after all the features had been implemented. Not during.
A typical workflow for game development teams using the waterfall method is as follows:
- Game conceptualization.
- The design team comes in.
- When everything looks okay and complete (in paper), coding and unit testing begins.
- When the coding activities finish, that’s the only time the localization team sees the string assets. Localization activities kick in.
- After localization, testing and quality assurance begins.
- The game app goes through another review process.
- Gather feedback from the users.
- Update accordingly.
This is what localization looks like in the waterfall approach.
It looks nice and organized, don’t you think? Each phase cascading to the next in an orderly way, but it hides lots of problems.
- Localization comes after the coding and testing activity — in the middle and tail-end. It should be in the early stages; ideally, as soon as you gather requirements.
- There is considerable lag as well as time-elapsed between game concept, demo, beta testing, and official release. Gamers typically want studios to update the game every month, but with waterfall, studios usually take two months to update. This is a big problem.
- Everything is on the critical path. If one of these phases hits a major snag, you can’t move on to the next. You can’t iterate.
To make matters worse, many dev teams still don’t employ proper tooling for localization. They may have gotten down their CI/CDs, hooks on source control, code coverage tools, and other DevOps bells and whistles, but they’re probably still managing their resource bundles manually. That’s problematic in many ways:
- Devs need to import and export content manually from/into the game, which may make every release delayed.
- Lots of emails, calls, and messages.
- Lots of copy-paste; and it’s easy to mess up.
Agile localization workflow
If you were to integrate localization into your Agile workflow, what would it look like? It might look like this.
It will be front and center of your development efforts. In an Agile workflow, everyone works on their tasks, but there are no gated phases. Just pick up work when you’re able. The changes are done in short intervals.
Agile localization is often called continuous localization. This kind of workflow emphasizes continuous communication among team members. The coders, testers, proofreaders, producers, and marketing team needs to stay in close communication with each other.
Agile localization syncs the localization process with the development process. They operate simultaneously. You will need tooling to accomplish this; a CMS tool like Gridly with a focus on localization should do the trick.
The Agile localization process can then be done as follows:
- Devs write the code. Unit test the code. Push to repo
- Localization software recognizes changes to the String resources (new or modified), routes the work to the localization team
- If the localization platform supports translation memory, new or modified strings can be matched and filled in rapidly
- The content is translated as the game is developed—no waiting time.
That’s how an Agile continuous localization workflow might look like. It’s easy to fall in love with it because:
- Shortened game development time. This is the most significant advantage of all. For this alone, you should switch to Agile already. Agile focuses on MVPs (minimum viable product) that can ship.
- It’s efficient. The entire process is friction-less—no resistance nor bottlenecks. There aren’t any gates nor phases. You can drastically reduce slack — project managers love that.
- No more sending string resource files, CSV, or XML files via FTP, Dropbox, or email (yikes!).
- It’s easy to spot localization issues. When activities are not on a critical path and turnaround times for development activities are short, this happens.
- Less manual work from copy/paste. When you introduce tooling in localization activities, copy/paste will be a thing of the past.
- More user involvement. The Agile approach encourages interaction between the users and the development team
- Flexible deliverables. As mentioned previously, Agile focuses on MVPs; because of this, the deliverables are ranked by order of importance. If the users want to release the game with a basic set of maps, characters, etc., then that’s what the dev team will release
Tips for adopting an Agile localization practice
- Ensure smooth communication between your teams. The devs, LQA testers, proofreaders, marketing, and producers need to keep each other updated. Make sure the teams are dedicated—interaction over processes. Remember?
- Use translation memory to keep the content consistent. It helps the company control cost. You need to invest some time in the beginning to organize it, but it pays to do this. The benefits are in the long run. It will save localization cost and increase the game’s build quality.
- Use a localization tool/platform to manage the content; a CMS tool is ideal for this.
- If the localization system can improve both localization and devs workload, the cost of the CMS tool should be counted into the development budget. After all, it is a dev tool instead of a CAT tool.
When choosing a CMS tool for localization
So, you’ve already been converted and now sees the light of Agile localization and the benefits of localization tooling. What to look for then? Well, let’s start with this list:
- Powerful API – You’d want the API to be descriptive, robust, powerful, and easy to learn; otherwise, your team will spend a lot of time combing through documentation and tweaking their PostMan tests
- Cloud-based and easy to use – You don’t really want your dev team wasting time on setup and configuration, do you? Let the experts handle the platform, so your dev team can focus on feature development
- Language dependency - Dependencies are used to simplify the translation process. When a change is made to the source language data, dependent columns (target languages) are highlighted to indicate an updated translation is required
- Version control, branching, and merging – As you add, remove, and modify game/app features, the ability to rollback, branch, and merge code changes becomes increasingly important. You’d like the tool to have built-in capability for this.
- Translation memory – This will save you lots of time, effort, and money. Having access to strings that have already been translated, tested, and proofed before allows your localization team to match and fill new (or modified) strings rapidly
Challenges in Agile localization
- Short-term vision – Agile has a significantly shorter turnaround time (compared to waterfall). This has benefits, and it’s one of Agile’s strengths, but if you don’t have a large enough localization team to handle the sprints, you can miss deadlines. It gets even more complicated if your source language is different from English: in this case, you need to set up the multi-step localization process. You need to introduce tooling into the process to augment (even multiply) your team’s capabilities.
- Quality issues – Studios need to deliver quality games to their customers. The customers notice the quality more than they see the fast turn-around time. Localization teams need time to deliver quality results. This will become increasingly difficult with Agile’s shorter cycles. To mitigate this issue, you need to adopt modern localization tools to reduce frictions in your workflow, e.g., hand-off and hand-back of localization assets.
- Initial investment in tools – This can be tough to justify, even tougher to decide whose budget it’ll come from (devs of localization). Still, once you invest, it pays off by saving localization costs in the long run (and higher game quality).
- Takes time to realign processes – Another investment you need to make is time. Adopting Agile and replacing waterfall isn’t a switch you can turn on. It’ll be a process. Your team needs to acclimate itself. There will be teething problems. Like all process changes, you just need to overcome and adapt.
Which one is right for you? Agile or Waterfall?
Agile is more suitable if the following is true for you:
- You have easy (almost instant) access to the users. You need a lot of feedback, that’s why this is crucial.
- Game features and requirements are hard to pin down at the beginning. Agile is great in iteration. You can refine features over the course of sprints.
- You can prioritize (even reduce) scope. Agile focuses on MVPs, remember?
- There is flexibility on the schedule.
Agile, great as it is, may not be for everyone.
A point to consider for waterfall is if the project has a fixed scope and budget; you can’t do Agile if this is the case. Some teams may not be co-located in an office; they could be dispersed. It will be challenging to implement Agile when team members are across time-zones and regions.
If your team should be in constant communication with its customers, you can lean towards Agile methodology. Still, if you have limited access to the users, then you can’t get very good feedback — which Agile depends on heavily — then the waterfall method may be better suited for your team.