Communication in Diverse Teams
Organizer: Miki Tebeka
Participants: Absar, Ville and Petri

We've talked about how can you be agile when your team is spread over several locations, some of them are in a different time zone and there may be cultural differences.
We've talked about methodologies and tools to solve these problems.


  • High level documentation help the team to know what
  • Team members MUST meet face-to-face from time to time, good times are:
    • When you start
    • Doing stories / use cases
    • Retrospective
    • Planning
  • Project management tools like JIRA, eXtremeManager and trac help the teams
  • know what is going on
  • Continuous integration system help teams to know what is the last "good" build
  • Tools:
    • Email is bad
    • IM/IRC is good
    • Helps when there is a language problem
    • Make sure you log the conversations
    • Wiki is mostly good
    • Forum/Newgroup/maillist are good
    • Again make sure to log everything
    • Have an RSS feed
    • Continuous integration helps
  • You NEED a good version control
  • VNC + phone used for pair programming
  • You can use tests for documentation
  • Video conferences don't work well (mainly form technological reasons)
  • You can take pictures of the white board and place them in the Wiki
    • Need to tune the writing to show up good in the picture (colors, size)
    • Search is problematic on pictures


Agile Organization Change
Ahmed S. Elshamy

Open Space Session 6/20/2006 12:00 am. (Yes, it was scheduled at 12:00 am)


We have been successfully implementing agile within a team.  Once we cross the boundary of the team we encounter mismatch between the organization rules and structures and the agile methodology.  This mismatch inhibits team efficiency in delivering and achieving its goals.


The agile team is a self directing team.  The organization should allow the team to make his own decisions regarding process, technology, priorities and valuing customer needs.

The agile team is a self sufficient team.  To solve lot’s of the external dependencies the agile team should be self sufficient.  The organization should allow the team to have his own DBAs, QAs, BAs, IMs and Devs.  Sharing team members can lead to inefficiency in the agile implementation and increase the waiting time on external dependencies for shared team members.  In case of a necessity of sharing team members agile team request from shared team members should be fulfilled in a reasonable manner.

Organization manifesto should match the agile manifesto.  The organization should value the same values as in the agile manifesto.  For example: employees’ evaluation should be based on the same values as the agile manifesto. Different departments should set their priorities according to the agile manifesto.

The bubble approach

In a reactive mode, we start with an agile team within an organization.  Assuming the team is implementing agile 100% the team will start to interact with the outside boundaries of the team.  When the team needs are fulfilled in a timely manner we can consider this part of outside boundary is also agile.  With time the team will interact more with different parts of the organization.  As this interaction with the organization grows the more the organization would become agile.

In a proactive mode we can think of how the team would interact with the organization and we can prepare the organization to react to this interaction in a timely manner.

-         Deployment procedure.  As the team is expected to have frequent releases, the organization should allow a fully automated deployment procedure to speed up the deployment of a new release.  Smart client application should use the existing self updating technologies.

-         DBA administration should allow the team to work efficiently.  Any DB request should be fulfilled in a timely manner.  The DB design will evolve during development.  Intermediate DB design should be acceptable during development.

No external QA is necessary for a new release.  The organization should trust the internal QA team and the customer proxy who tested the application before release.  Internal QA would have a better knowledge about the application and that will eliminate unnecessary documentation.