Saturday, August 1, 2009

How to roll out a process for large global teams?

My role as a program manager demands communication in various forms within organizations. I have seen and used various approaches, some effective and some not when a new process is rolled out. I would like to share my experiences and at the same time would like to learn from your experiences.

My definition of a process, is a systematic and disciplined way of doing things that creates a positive impact on how the overall business is conducted. Some examples are scrum best practices, transitioning to a new tool, generating org wide common metrics, etc. Now consider rolling this out to a large (150+) engineering team (development,QE, project managers, etc) spread around the globe (America, Europe, Asia,...). The impact of a new solution depends on what mode of communication is used.

Email communication: I've noticed email communication works out better for general announcements like org changes, something to do with HR activities. However it has not always been as effective for process communication. Again, it depends on how big the change is and what type of impact you are trying to make. Email guarantees that a new process lands in everybody's inbox, but does not guarantee that everyone will adhere to this new process. Why? Because as my new manager says, "every individual is wired differently, has different ways of doing things and has different attention span" -( I think I am going to take her offer to read a book on Human Dynamics). My experience has also shown that for email communication to work effectively, multiple reminders at constant intervals are needed for a process to be part of an organization's DNA.

Meetings: From my experience, this approach seems to be most effective. This can be implemented in various ways.
  • One approach is to roll out a process in phases. Select couple of high performing teams and educate them on a new process. Monitor and measure their progress for a short duration (2 to 3 weeks). Once you feel comfortable, use their success stories and start rolling out the new process to all teams by conducting further meetings. This also gives you an advantage of making tweaks to the process based on working experience of these teams. The cons of this approach is, it takes a while until the entire organization comes up to speed.
  • Another approach is to form a team of key players like managers, team leads, scrum masters for Agile development across the organization that can be trained and educated on a new process. The next step is to hold them accountable as well as responsible for rolling out this new process to their teams. The trick to making this approach successful is to ensure that these subset of players talk and have same understanding of the process. If not, its difficult to get consistency, as each team will be trained differently based on the version of the new process understood by these trainers.
All hands: This forum can be a very effective and can make a huge impact if senior management briefly discusses the new process and enforces the importance of implementing it successfully for the organization. Honestly, I have my reservations on implementing any new process this way. Why? One. just because getting every participant in a room or on a phone in global teams is almost impossible due to timezone differences. Secondly, sharing minute details of a process and opening the forum for general Q&A is not viable.

Individual Goals and MBOs: Making everyone in the organization take a shared goal of some healthy percentage i.e 10 to 20 % almost guarantees that the new process will be effective. By tying dollars to a new process, everyone has equal stake in making the process work. However this can be an extreme step, as it can make lots of folks unhappy if the shared goal has to be marked incomplete.

In summary, there are multiple ways to roll out a new process in a large global team. The best way to ensure that everyone within the organization is in unison, is to use a combination of the above methods.


1 comments:

Anonymous said...

I prefer the first approach of rolling out Agile in phases. It will also help you to learn a lot more prior to rolling out to the entire organization.

It is also very important to get the upper management buy-in. As you said, tying it to individual goals makes sense. In addition, the Scrum Master must have the authority to determine if teams are Agile compliant or not?

Post a Comment