More on Culture

As I mentioned in my last blog post, one of the presentations at last week's P2P was on the challenges of implementing Agile in the Egyptian culture. Since I'm working with a team in India, I wanted to take a look at how Indian culture aligns with Agile.

One area of consideration is that of the self-organizing team. Indian culture supports team work. However, there is also respect for hierarchy, so the team may not feel empowered to make decisions. The team may feel the need to defer to a senior person for decisions. I have found that I am being asked to make more decisions compared to a US based team.

Indian culture also tends to avoid open confrontation. I think some conflict can be good as the team is developing. On my US-based teams, it isn't unusual for one developer to provide constructive criticism to another's work. This type of feedback should be delivered with a softer tongue for my off-shore team.

Another area that I have noticed relates to communications. Indian culture puts more emphasis on written communications. I know my off-shore teams have often asked for more formal requirements documents than what I expect from a US based team. One adjustment I've had to make is to provide more documentation for my off-shore team to work from.

Indian businesspeople tend to be tough, smart negotiators. While this conflicts the idea of customer collaboration over contract negotiation, successful negotiation is built on trust. However, building this trust can take time. In my case, I had time to start working on building that trust before the project work started up.

So what does this really mean? First, my points are just generalizations. For anyone working with other cultures, this type of understanding is just the starting point. You shouldn't rely solely on generalizations for determining how to work with your team any more than you would use New Yorkers as a benchmark for working with Americans from other parts of the US. For any cross-culture work, take the time to know the people you are working with.

Projects to the Point 1st Impressions

Day 2 of Projects to the Point has wrapped up and so far it has been an interesting conference. One of the themes of the opening day was change. Emad Aziz from Brisk Consulting talked about how change is the only constant. As project managers, this is what we have to deal with. Related to that, Dr Mohamed Tewfik Elmasri talked about organizations that are transforming (such as through a merger/acquisition) and how a key part of the change management process is communications; "People can deal with bad news, people can't deal with uncertainty."

Another interesting presentation was by Ali Zewail and ElMohanned Ahmed. They discussed the challenges of implementing agile in an Egyptian company from a cultural perspective. They even compared the principles of the Agile Manifesto to the cultural attributes of Egyptians. It made me think about my team in India and how agile aligns or conflicts with some of their cultural characteristics.

Motivation

I was re-reading parts of Daniel Pink's Drive in preparation for one of the presentations I am giving next week at Projects to the Point in Cairo. My talk is on what makes a good leader for agile projects and his book fits in good with his thoughts on motivation.

In the book, Pink sites why the "carrot and stick" approach to motivation doesn't work. You can read the book for the details, but in summary, this approach tends to drive the wrong behavior, only works in the short term, and kills creativity.

So what do you do to motivate people? There are three things people need to be intrinsically motivated; autonomy, mastery, and purpose. Autonomy is letting people decide how they accomplish their goals, or even what some of their goals are. Mastery is becoming an expert at what you do. Purpose is knowing that what you do has some higher purpose than just adding to the bottom line of a corporation.

One example that brings this home is the battle between Microsoft's Encarta and Wikipedia. Microsoft used money to motivate people to build their encyclopedia while Wikipedia was build by a bunch of volunteers. Encarta failed while Wikipedia is extremely successful. So if you have a team to motivate, money isn't the answer, nor is a autocratic leadership style. Providing them the tools they need to succeed, giving them the freedom to use those tools how they want, and providing a vision for what is needed are going to get you closer to your goal.