The Evolution Of Project Management: Waterfall To Agile To Continuous Delivery

For as long as there have been projects, there has been project management. Although the technology and strategies have evolved over time, the goal has remained the same — to ensure projects are handled as efficiently as possible. One of the newest strategies to pop up within the translation and localization industry is continuous delivery. Continuous delivery is a new solution to some of the difficulties of past project management strategies, but no solution is perfect, so what are the new challenges it brings about and how do we manage them?

First though, it’s important to consider how project management has evolved and how we came to continuous delivery in the first place.

Waterfall Methodology

The waterfall methodology is the grandfather of project management strategies. It is synonymous with adjectives such as linear and sequential, since the movement flows in one direction, like a waterfall. In waterfall project management, each stage of development has to be completed before moving on to the next stage.

This means that localization can only happen at the end of the development process once the product is completed. Content is moved around in giant boxes, the source code is frozen during localization to avoid scope changes, and you have time to test the application thoroughly once the content is localized.

Does the waterfall method work? That’s a matter of perspective. There are waterfall loyalists who remember the good old days when there was enough time to get familiar with the product. In waterfall, there is a clear understanding of how many people are needed to work on a project and because of the rigid structure, the workload is clear for months to come.

The notable downside of this methodology is that many projects miss their deadline. If even one stage is delayed, it has a trickle-down effect on the whole project. On top of that, making any necessary changes is difficult and time-consuming, and delaying testing until the end of development means that if a problem is found, it’s not easy to fix – resulting in further postponing the release.

Agile Project Management

Agile was the answer to the drawbacks of the waterfall method. With agile, the idea is to start small, iterate, and pivot until you reach a good product. Agile is a more flexible approach to project management and is focused on continually improving the product. In an agile framework, content for localization is moved around in smaller boxes and the localization team can either work embedded in the sprint (which is rare) or as a subsequent step at the end of the sprint. So rather than all localization happening at the end of a project, it happens in time with development.

Does agile work? One benefit is that speed. You can quickly identify and fix problems and easily adapt to changes, resulting in faster turnaround times. However, the organization of the localization processes must adapt in the background and is a challenging transition.

The new challenges agile has brought about:

  • Project Size: The size of projects has shrunk, resulting in an increase in overhead. Project managers now have to manage more projects of 200 words instead of fewer projects of 20,000 words.
  • Context: Product familiarization is difficult when you’re not working with the project in its entirety. There is less time to understand it and see the smaller translation within the greater context.
  • Staffing: The risk of volume fluctuations makes staffing tricky, causing delays or higher costs if not mitigated upfront.
  • Quality Checks: Quality Assurance (QA) policies have to be created before a beta version is available, resulting in a lot of guesswork. Additionally, there is not a lot of context during translation and the localization quality checks are rushed.

Not all companies have succeeded in transitioning from the waterfall framework to agile, but those who have managed to get it right have developed well-oiled processes and technologies and – most importantly – they are well prepared for changes.

Continuous Delivery

Those changes are coming in the form of continuous delivery. Continuous delivery is a subset of agile whereby the product is developed in a way that ensures that it is ready for release at any time – unlike agile where the product is usually released at the end of a sprint. Developers don’t want to wait for days to get the code QAed, localized, and LQAed, they want to release as soon as they are done and move on to the next item.What does it mean for the localization teams that were working in sync with the sprints? It means that they have to learn how to manage a continuous flow of content instead of larger drops, and localization management should focus on removing the long-term obstacles to this process rather than managing requests.

What kind of obstacles can we expect?

  • Internationalization: The cost of a localization bug like a truncation, a font issue, or hard-coded strings can be exponentially expensive – in both time and money. One of the key principles in continuous delivery is moving to QA as soon as possible – even before sending content for localization – so it’s necessary to run some good old pseudo-translation or even MT to avoid unpleasant surprises.
  • Staffing: In continuous delivery, you don’t necessarily know when localization will happen or how much effort will be required from the team. It’s important to work with a good team who knows the product and is available when localization is needed. Agreeing on the goals, commitment, and a fair compensation will help ensure that the team is ready and available when you need to scale up.
  • Technology: It’s important to choose technology ready to support this process – the infrastructure which allows the content to flow back and forth. Look for automation features to reduce human errors, contextual information so the localizers can easily understand the strings, and a strong API to customize an integration with any third-party tools and applications.

Leave a Reply

Your email address will not be published. Required fields are marked *