Lean Software Engineering

{ 5 }

Comments

1. Dew Drop – August 7, 2009 | Alvin Ashcraft's Morning Dew | 07-Aug-09 at 5:12 am | Permalink

   [...] Multi-site teams: travel and the half life of trust (Bernie Thompson) [...]

2. Matthias Marschall | 11-Sep-09 at 1:36 am | Permalink

   There is one important difference between open source projects and corporate settings that is often overlooked.

   In an open source project you usually have _individuals_ working together whereas in corporate settings, you usually have _teams_.

   In my experience it is very important to understand the team dynamics at all locations as they re-enforce the “us vs them” feelings.

3. Bernie Thompson | 30-Oct-09 at 10:25 am | Permalink

   Hi Matthias – very good point. And, in fact, where you do have “teams” within open source – usually people working for Canonical vs. Red Hat vs. Intel, etc. — those tensions and “us vs. them” feelings definitely rear their heads (e.g. see http://video.google.com/videop.....7824733336 ) The “pressure valve” is the choice to (at least temporarily) branch and deliver competing versions — even if it’s not always the right thing for the technology or for the end-user. And that happens all the time in Open Source. Commercial companies tend to force their teams to deliver just one thing.

4. Trent | 28-Oct-10 at 10:56 pm | Permalink

   It can be difficult enough to manage multiple teams at the same location. Once you spread out to separate locations, especially across timezones, things become just shy of nightmarish. Whatever can be done to mimic the qualities of same location (video conferencing, travel, etc.) is worth the effort.

5. SaaS | 23-Jan-11 at 12:12 pm | Permalink

   Bernie brought up a good point about the “us vs. them” problem, but that is not the only problem in that arena. The cultural differences and the way english is understood by other cultures is a problem that is not often identified and dealt with. There are words and phrases that just do not translate between languages. And often the way others learn language is incorrect. In software development those differences can manifest themselves in clients not being satisfied with the end result and support costing more than just money. Thanks for the post.

Post a Comment