Our customers seem to be developing software using waterfall methodology less and less, and seem to have embraced agile or kanban type workflows more and more.

From a localisation point of view, this actually is a win-win: we receive software localisations in small fortnightly chunks, which with modern Computer Assisted Translation tools are centrally translated quickly and consistently.

Much better than the bad old days, when a General Availability date loomed, the mass of software resources was not ready for localisation, and the time to do so shrank with every passing day. Nobody likes delayed software releases, especially not if caused by an external factor like software localisation. So why is localising agile software well such an issue?

Not just software localisation

It is an issue because no matter what software developers believe, there are other requirements needed in order to satisfy customer expectations, such as the necessity of supplying documentation, User Assistance, and localisation testing. The software itself may have testing incorporated into the sprint cycles, perhaps with the odd hardening sprint thrown in for good measure, but this just doesn’t work for User Assistance.

Authors need to wait until features are de-bugged before they can describe them in a Help System.

There’s a solution, right?!

Well, sort of, and it relies on good communication between the stakeholders. Software localisation and User Assistance authoring both become much less of a timing issue, if the sprint cycles can incorporate them.

With some development teams, User Stories are shared with the UA authoring teams and the software localisation provider, so the former can prepare the topics, and the latter check for likely issues, during active sprints.

Also a matter of communication is to know the impact downstream of each User Story ahead of time. Some User Stories with more user-interactive workflows will need more UA support and contain more strings that will need localisation. With planning, an amount of load-balancing is possibly to use available velocity.

Agile thinking is a fabulous working method that has changed software development and project management. And with good communication, the benefits can be extended to UA authoring and beyond.

But to develop software in a scrum, then waterfall the Help System and localisations? Not a good way to meet client expectations. Whether developers like it or not, the Product Manager, and more importantly, the customers, will only be satisfied once all work is integrated as part of an all-parties agile team.