Agile Habla Aqui?

Agile doesn’t speak English, Spanish, or Martian. It just speaks efficiency and speed to market. Here’s how to implement agile across languages.

As agile grows in popularity, many businesses are finding that one of its greatest gifts is its common vocabulary. Other methodologies often struggle to communicate across different languages, processes and cultures. But by working from a foundation of mutual understanding based on a shared language, agile prevents misperceptions, delivers the customer’s vision and accelerates time to market – all by implementing some simple yet highly effective practices.

So how does this common language of agile development work? While smart vendors and customers will make an effort to work with culturally compatible teams, the effort to synchronize expectations and processes can’t stop there. Teams from different regions, backgrounds and companies will still need to reach out and create a synchronized language.

The five agile practices below can help teams work across their differences to ensure a smooth, streamlined project cycle.

Provide real-world examples of what we mean

Effective agile teams will find a way to work around an unavoidable truth: we all define words and concepts differently. We come from different backgrounds, some of us speak different languages, and all of us are influenced by sources such as former training, bosses or projects. As a result, our viewpoints and definitions can vary widely, which can quickly lead to erroneous assumptions on a project. By using real-world examples to accompany our agile terminology and directives, any guesswork is eliminated.

Let us look at the following scenario. We recently entered a new software development domain. There is usually “shorthand” that has developed among team members when they have worked shoulder to shoulder for a long time. In this particular case, our customer’s team has worked together for over 15 years. So the terms used while expressing requirements in user stories are clear to them. For us as an external developer it would have been easy to misunderstand the meaning of that shorthand. However, the real-time interaction required of agile allows us to overcome such deviations due to misunderstanding in just a matter of hours.

Implement a framework like CMMI or SCRUM

On one project I found myself in Mexico with an extremely diverse team. Engineers, developers, economists and government workers all played different roles on this project, and everyone was focusing on a different piece of the puzzle. The viewpoints and ideas clashed to such an extent that I really doubted we could hit the project deadline or meet the customer’s goals. Yet in the end we did deliver a successful product – and it was because we implemented a framework that helped everyone understand and carry out their specific roles. The magic of implementing the right framework is that it defines parameters, institutes clear communication and spells out the right processes and directions. Putting a framework in place at the start helps dispel any confusion over priorities and roles down the road.

Define the literal language

This is absolutely necessary in a time-boxed iterative process. The reason is obvious; if we’re working with 14-30 day development cycles, even a slight misunderstanding can lead the project disastrously off course in a very short time. Once again, remember that we all bring different understandings to a project.

done-not-equal-doneThis is never as evident as it is with the word “done.” Generally, a team’s Definition of Done (DoD) is aimed at bringing a standardized quality to meeting client demands and making success repeatable throughout the project. But the standards themselves can differ from team to team. One team might decide that all coding, testing and peer review must be completed, before it can be called done. Another team might decide to split their DOD into additional levels of Done Done and Done Done Done. Still another might have adaptable DoD depending on the project type. To make sure that everyone is on the same page at every point in the project cycle, precise definitions are critical so take the time to develop them and ensure all team members use them.

Think of it like building a house

In the United States, you often pay for your house long before you move into it, since the house has to pass certain inspections and is only considered ‘move-in ready’ after those inspections. In another country, on the other hand, you might move in before construction is officially complete and then keep working on it while you’re in residence. Such different practices and expectation can easily lead to a misunderstanding – so you can see why it’s vital to clarify the meaning of our words.

Stay focused on the promise to the customer

True, a lot of businesses like to talk about their “promises” – but when it comes to agile, this isn’t just empty talk. Accountability is woven into every fiber of the agile model, while teams keep the customer’s needs in mind at every stage. The Promises Triangle aligns customers, providers and workers by ensuring the workers are both informed of the promise to the customer and empowered to fulfill it. The purpose of this diligent accountability? Avoiding a common pitfall of waterfall model, where the Requirements Document begins a promise that eventually winds through non-technical staff who then add in unrealistic promises – a process that often leads to disappointment in the final product.

Prioritize frequent communication and feedback

Agile cycles are built around user stories – first by gathering those stories, then prioritizing user needs, then deciding what can be delivered within the designated timeframe. Teams also constantly solicit and incorporate feedback to maximize customer satisfaction. On a practical level, this means that customers must be prepared for frequent interaction and able to deliver clear feedback, while vendors must be able to explain how element X affects element Y in a way their customers will understand.

Overcoming different backgrounds and conflicting expectations is important in any business endeavor – but in agile development, it’s absolutely critical for a successful product. By implementing thoughtful and effective strategies to align efforts, teams can eliminate potential missteps and fulfill their promises to their customers. In the end, it doesn’t matter what languages and backgrounds teams bring to the table – by following the above practices, everyone will be speaking the shared language of agile.

Guest post from Tiempo Development, which provides cloud-focused companies with a powerful, integrated platform of services that transforms the way their products are developed, deployed and supported.

Trackbacks/Pingbacks

  1. New PM Articles for the Week of August 26 – September 1 | The Practicing IT Project ManagerThe Practicing IT Project Manager - September 2, 2013

    [...] Peter Saddington hosts a guest post from Tiempo Development, on implementing Agile methods in multi-cultural work groups. [...]

Leave a Reply