Agile Project Management may be the ‘method-du-jour’ but it has actually been around and experimented with for over 50 years. Gaining traction with the software development community following the Manifesto for Agile Software Development (2001) this methodology is now well used and very well respected across many disciplines of project management.
From a localization point of view, it answers a lot of our prayers. Inasmuch as it moves localization upstream and no longer do we deal with translation/localization as a ‘waterfall’ afterthought. Instead, we are integrated into the development, code and management of the very product which we are helping to develop. This has to be a good thing as the feedback loop from local consumer to a global brand is encouraged.
The process itself breaks a large software development project into a series of smaller development “sprints”. These are designed to show tangible progress and allow evaluation/redesign which can improve the end result. Some of the challenges LSPs have to overcome when participating in Agile Projects include:
- Low volume, quick turnaround translation
- Larger translation teams
- Crowdsourced Validation
- Machine Translation, especially at early stages of the process, and
- Email-less Workflow integrated into the workflow and controlled authoring systems
The benefits of producing software via this method are well documented. For instance, in a recent paper Version claim that ‘four out of the five key factors contributing to project failure were associated with and aggravated by the waterfall model’.
Agile Project Management
Several times this year I’ve spoken at different events/conferences about Agile Project Management. It has far-reaching implications for the localization industry and its effects on management/leadership styles (which is a topic often overlooked).
As the year comes to an end I’ve put together this blog post as a collection of this year’s learnings, comments, feedback and possible suggests for the future of this exciting tool.
Background to Agile Project Management
I define a project as a ‘planned program of work which requires a definitive amount of time, effort and therefore planning to complete’. Projects have been around for millennia. The Pyramids didn’t just build themselves, they needed someone to organise massive (for the time) amount of resources together, motivate them, measure their progress, adjust inputs, etc. Project Management (as taught in business schools) has been around since WWII, based largely around the step based manufacturing approached used by the US Military. This was later adopted in civil engineering projects in post-war Europe and later still by engineers working in the computing world.
In the early 70s a computer scientist called Winston Royce wrote a book called, ‘Managing the Development of Large Software Systems’. In it he listed out the phases of project management to be; Requirements, Design, Development, Integration, Testing and Deployment. This later became the base for the Waterfall as it was understood that each phase should be completed before the next. Interesting to note that it wasn’t Royce’s intention that we should complete a stage and never go back to it, he does talk about iterations in his work (a prelude to Agile perhaps), however, it’s largely understood to mean this.
The Waterfall method stayed with us for a long time. Right up until 2008 it was the preferred (and taught) project management methodology. Around about this Standish Group conducted some research into the failure of software projects in the US. This found that out of the almost half a trillion dollars spent on software development in 2009 $109 Billion was wasted on failed projects. A new methodology was clearly needed.
My own mentor and professor used to tell our class that ‘good project management was boring’ that is you knew if you’d planned your project out correctly because the execution phase would be without hitch, ‘you would just be ticking boxes’. This is what’s different about Agile, it’s not boring, and it’s not predictable. Through the innovative nature of the tool things can change (and do change) mid-project and your team will explore new avenues which they’d have not considered if we’d spent a lot of time/money in the planning stage. I like this about Agile, it’s probably my favourite part.
Technology moves fast, especially the revolution we’ve seen in computing in the last 30 or so years. Moore’s Law (which isn’t a law but a mission statement) says that computers will double in power and capacity every 18 months and its worked out to be correct.
Just think of the crappy USB sticks you get at conferences that you give to the kids and compare these to the supercomputers from a generation ago. As these continue to grow exponentially it becomes harder and harder to develop software for platforms which are developing so quickly.
The Agile method focuses on early delivery of value to the client, continuous improvement of the project and product, the inclusion of the team (and their inputs), customer needs and flexibility. Think of it as an update to the way we’ve traditionally managed projects as project managers.
The Agile Manifesto
In 2001 a group of software and project managers got together in Snowbird, Utah, to share success stories and talk openly about how traditional project management tools were letting them down.
In doing this they created the Agile Manifesto which is a statement of values for successful software development. It is only 66 words and I’ve included it verbatim below:
We are uncovering better ways of developing software by doing it and helping others.
Through this work we have come to value:
Individuals and interactions over process and tools
Working software over comprehensive documents
Customer collaboration over contract negotiation
Responding to change over following a plan
That is while there is value in the items on the right, we value the items on the left more
It is important to remember these words. We have them printed out and displayed in the office. I periodically check my projects against these values to remind us of what we’re trying to achieve and how Agile is different from managing a project using the Waterfall set of tools.
Although this manifesto (and resulting ideas/tools) were developed to cope with the changing landscape the internet gave us Agile has spread way beyond software development and professionals from a variety of industries including pharmaceuticals, marketing, not for profits, and even found its way into construction.
Applying Agile Outside of Software
After discovering the benefits of the Agile philosophy we looked to apply it to projects outside of the software localization world. We found a few. One of which I talk about (partly because it’s a product we all consume and can, therefore, I hope to relate to) is providing translation to the retail sector. This sector by definition is a very dynamic environment in constant state of change. It’s an exciting environment to work in and as consumers are increasingly more informed about products and the ‘moment of truth’ can often make or break the sale.
Retailers need a dynamic approach to manage their linguistic assets which is why we consider this method of project management to be a good fit.
The project itself was to localize 8,000 food products in a dozen new languages. This meant that at any one time we had almost 100,000 products to track and control. The project itself took 18 months and when putting together the team to we presented an Agile approach (which the client agreed to). This is some of my key learnings from that process, I can’t share specifics due to non-disclosure agreements but do hope the reader can gain some information about the implications of running an Agile process outside of software.
Agile Localisation Project
Standardise the KPIs
Although the project involved a half dozen companies responsible for different delivery elements of the project all of the Key Performance Indicators were rolled up and reported on as one. This implied we had to align all service delivery contracts (including bonus and penalties) to all pull in the same direction. At the end of each month each Account Director reported on their own areas and how this affected other areas of the project’s scope. It helped us to have an appreciation of the project as a whole and the Agile approach led to us finding several very large areas where we could save the customer money and reduce the critical path by almost 30%.
Agnostic Translation Technology
It was important to all stakeholders that the technology applied to this project was agnostic of all the service providers, that is, no one supplier controls the workflow and technology of the others. This was approached by developing one modular system which linked very well via API to the other more specific solutions developed and utilised to carry out specific parts of the process by the different suppliers. The client saw one online system.
And some technology use evolved. We were surprised to see technologies such as WhatsApp being used to help teams to communicate but once it took to hold it provided a great way to distribute information about anything in relation to the project. Other ‘free’ technologies were used a lot such as Skype, Doodle (a great tool for planning meetings), phpBB and TWiki.
Close Knit International Teams
Its well documented that organisations who develop cross-disciplinary diverse teams perform better. In this project, we literally had hundreds of people working together in teams situated all over the world, in many different companies and at very different levels of management. to help us appreciate the complexity of these networks we used a model called the Johari Window.
The model was developed to help with personal awareness, I like to use it to help me to understand how teams form and perform over time. It sounds exotic but the name comes from an amalgamation of the two American psychologists first names
If you imagine that when you’re communicating with someone else there are things which are known to you and things which are unknown and things which they know about themselves and things which are unknown. If we then lay these out at right angles to each other we can create 2×2 with 4 different areas (or panes in the window) on it. We’ll work around the different ‘panes’ of glass on the window and I’ll briefly explain each one.
The first is the Open Area. In this area, there are things which I know and things that you know about me, for instance you know that I’m the CEO of K International and I’m a man.
The second pane is the Blind Area, in here we have things that I don’t know about myself but that is known to others, this can sometimes be things which annoy other people. This area can be reduced is through thoughtful and considered feedback. Its a skill to give feedback and not everyone does it correctly. It needs someone to give it and someone to be open to receive it and the right environment for this to happen.
The third pane in the window is the Hidden Area. This is an area where I hide information which is known to me to others. For instance, you won’t know (until now) that although I’m an Englishman I can’t stand drinking tea. The reduction is this pane comes through self-disclosure, often by sharing a little bit about yourself in a considered way will help other people to get a better idea of who you are and ultimately develop as a person as self-disclosure can lead to feedback.
The fourth and last window pane is the Unknown Area. This area is accessed through self-discovery. As with the two previous (feedback and self-disclosure) people start to take risks and discover things which they never thought possible. As a leader, it is your primary role to ensure the environment in which these things can happen is set-up and maintained. I’ve found that teams will always go through the forming, storming, norming and performing curve but by using a model such as the JoHari Window it speeds this process up. In the slide below I’m showing how teams change over time, you get the idea.
Closing Remarks
So… to sum up. Agile is/was a much-needed change in the way some projects are put into action. It’s well documented (and in our experience) to save the end client money and deliver remarkable projects on time. But it’s not an answer to everything. As with most things at work now as a leader, you’ll be dealing with human beings and you’ll need to think about any new concepts you implement given this context. Use your EQ as well as your IQ.