Project Potion 17 - Death of the Phone Call

Offshoring and the Technology Gap

Next week I'll be co-presenting at the Agile 2010 conference in Orlando, Florida with Thushara Wijewardena. Our presentation is called "Why you suck at off shoring, even with Agile". The plan is to discuss and debate some of the issues people run into when they are doing offshore projects. Thushara, who lives in Sri Lanka, will be covering the offshore side and I'll be handling onshore. We've both got a fair bit of experience in the area, but in order to make sure we'd covered all our bases, we interviewed a number of people to get their take on it. Heading into it, I felt pretty confident, based on my experience, that the majority of the difficulties that onshore managers and teams struggle with are brought about by their own approach and an assumption that offshore must learn to adapt to the onshore way of working. My basic argument was that the onshore teams really had to find a better way to adapt how they approached working with an offshore team if they really wanted to get the most out of them. Working with teams spread across the globe, in different time zones, from different cultural and educational backgrounds is never easy, but I do believe that the responsibility for enabling the offshore team falls largely on the onshore team's shoulders.

The most interesting interview I had was with a gentleman I know who comes from India and has been in the U.S. since the 70's. He has years of experience in testing out different ways to make offshore successful. Some of the lessons he has learned seemed to be directly counter to my assertion for the talk, but he had some very solid explanations of how and why he came to those conclusions.

One of the things he said is that there are certain job functions that an onshore team should probably never send offshore. Architect and BA were among these roles. By way of explanation, he offered a story...

The company he ran had been contracted to develop a POS system for use in retail stores in the U.S. He had one of his top leads head over to India to spend time with the team they had formed. The requirements had been fully defined, all the developers were trained and things seemed ready to go. During the discussion of the requirements, the lead asked the team how many of them had ever worked on a POS system before. None of them had. The second question was how many of them had ever seen a POS system before. Only one team member indicated that he had and when he was asked to describe it, he described the back of a cash register. So, while the team was comprised of experienced developers, and they had a full set of requirements, none of them had ever had experience with anything like what they were being asked to develop. Now, while this would not prevent them from actually executing the requirements, without some level of familiarity with what it would be like to interact with such a system, or what the job function of someone who had to use it was like, how likely is it that they'd be successful in their implementation? In this case, they were fortunate that their lead, although born in India, had spend several years in the U.S., knew the client, how they worked, etc. Without his knowledge of how this POS system needed to be used, the team would have been lost no matter how good they were.

What I found most interesting about this was that while I had been focusing on the idea of culture as being a significant stumbling block for onshore teams who are unable or unwilling to adjust how they work to adapt to the offshore teams, I had not considered how the implementation of technology in the day-to-day life of people in one country or another could have such a significant impact on the work. It wasn’t just a matter of the onshore and offshore teams respecting one another, or making sure they all knew how to develop in the same programming language, or that they had well defined requirements. In this case, the fact that none of the team members had ever run across a system of this kind presented a huge challenge and no amount of cultural sensitivity, or training was going to cover the gap created by the varying levels of technology implementation on a day-to-day level.

If you are planning on attending the Agile 2010 Conference in Orlando and would like to hear more of what Thushara and I have learned during our research for the presentation, please join us on Thursday, August 12 at 11 AM in room A-4.

And if you have any feedback on the above, I'd love to hear it.

Project Potion 16 - The Yeti

Project Potion 15 - Cloud Workers

Will The New iPhone Change How PMs Work?

A Project Potion Special Interview with Frank Illenberger

Project Potion - New Technology for Communication

The Art of War - Chapter 2 - Entry 1 - Knowing the Cost

"To raise a corps of a hundred thousand

 A thousand pieces of gold will be spent each day."

The second chapter of the Art of War begins with Sun Tzu laying out some basics about materials required to wage war. This kind of thing happens quite a bit throughout the book and it can be pretty distracting for Project Managers because our brains have been conditioned to start tracking these as requirements that we'll have to obtain at some point.  The run up of all these requirements  leads to the statement about the rate of gold per day and the fact that you can't even consider getting an army until you have that covered. The point of all this is to show that in war, there is cost, and that before you can start on the things you think you need to obtain (people to do the work), you first have to account for a whole bunch of hidden costs that you need to address before you go get people.

Bottom line...whether it is war, or a project, getting things done is expensive and there are going to be things that are less obvious or sexy that need to be covered. Before you take anything on, make sure you have a firm grasp of the cost. 

"The cost of an interpersonal Challenge is primarily an emotional one. Nonnegotiable conflicts can be very painful, since success generally comes through ending the relationship or changing ti into a very different one. Therefore, careful evaluation and acceptance of the emotional costs of your Challenge are essential to your success."

For Sun Tzu, the cost includes the lives of the soldiers and all the people who are going to have to work so hard to support them. While most project managers are not normally putting team members into direct mortal danger, the cost of the project may mean other projects do not get done... and depending on what choices are made, the business or company could be at risk, which does pose a direct threat to people's ability to work and earn a living and places them in harm's way.

We need to understand the cost of what we take on and what the ramifications of what we are doing are so that we can make responsible, informed a choices while managing the project.

Quotes are taken from The Art of Strategy by R.R. Wing

Project Potion #14 - Vuvuzela

Why an Iteration is Not A Mini Waterfall

When I am working with Project Managers who are in the throws of trying to learn Agile, there are certain discussions (debates), which can indicate that the person is going to have more of a struggle with making the change. These are usually the PMs who quickly grasp the flow of the process, but immediately begin second-guessing the system, and all of this usually happens without the PM even realizing it. After all, if you have been around a bit, and you are a halfway decent PM, you look at everything that enters your path as a potential threat to your project and start working out how you are going to get around it. This is what we are taught to do – find a workaround.


I think the bigger issue though, usually stems from the fact that the PM often does not recognize how their own expertise can be the obstacle. One of the ways this often manifests itself is through a question or declarative statement/argument about how the PMBOK is clearly, already Agile and these iterations or sprints we are talking about are nothing more than mini-waterfall projects.


Just in case any of the mini-waterfall people happen upon this… I mean you mo harm. I spent about 8 years inside that argument. Please bear with me a few minutes and this will make more sense.


I have learned my lesson about trying to engage in an argument against the perception that a sprint (or iteration) is just a mini-waterfall. I don’t agree with it, but it is perception, and my experience has been that getting pulled into this one kind of like trying to debate whether Sammy Hagar was a better front man than David Lee Roth.


To me, the real issue comes down to something completely outside the steps of the process itself. A traditional PM can make all the arguments they need to in order to maintain their death grip on the belief that everything in the world can be broken down into a traditional (waterfall) project. But, no matter how much Kool-Aid they’ve consumed, there is one thing which cannot be avoided, and which they cannot deny…


A waterfall project schedule is nothing more than a guess.


"…But little Mouse, you are not alone,

In proving foresight may be vain:


The best laid schemes of mice and men

Go often askew,


And leave us nothing but grief and pain,


For promised joy!"

(from "To A Mouse" by Robert Burns)


Yes, it is an educated guess and yes, there is usually math involved and we all know that if there is math, it must be true. Math aside, a traditional project schedule is just a guess based on what we think we know will happen, made at a point where we think we know enough to predict the future. (And I think we all know how good we project managers) are at predicting the future.



So, in managing a project, a significant part of the PMs gig is to come up with this educated guess and then do his/her very best to make sure to bend the very fabric of reality to match the guess. The idea is to manage to the plan.


In Agile, we focus more on the team and what we can do in order to better support and enable them, because it goes (Theory Y Alert!) that if you’ve got a bunch of smart, motivated people, you give them what they need, a clear objective and the power to make smart decisions, that the rest will take care of itself. (Remember – it says Theory Y above, not Theory X).


So, regardless of the steps in the process, the whole value system is completely different. A PM who is looking at the world through a waterfall will see the steps in the process as the thing that exists to make sure everyone stays on schedule as planned. An Agile PM is one who looks at the process as something their to support the team’s ability to perform. At the end of the day, both sides need to get stuff done, but a traditional PM uses the schedule to do this, an Agile PM enables the team to do this.


To me, if a PM is locked into the vice-grip of trying to prove that Agile is something that is already covered in the PMBOK, working their way out of that Gordian knot is usually something they will have to work through on their own, but if they can see the variance in the structure of the value system, and how that vantage point impacts their actions on the project, it is definitely a step in the right direction.


(And yeah, I’m willing to throw down for Hagar any time, anywhere.)

Project Potion Special Interview with Johanna Rothman on Agility and Programs