Virtual Teams and Dependencies
Having read posts I would like to ask you a few questions from Scrum POV, I appreciate your contribution to this:
Q: How does agile work with virtual teams that by default are not physically co-located, specifically with regards to daily stand up meetings and the like?
Q: In our product, we have a lot of dependencies; one new feature requires extensive co-ordination between our hardware, controller, traffic card and communications teams. How would you solve this problem ?
Regards
A: Virtual teams are always less productive than co-located teams. It doesn't matter if you are using Scrum, chaos or the most ultra-disciplined waterfall approach. You can expect to double productivity by putting everyone in a room together. Seriously consider this when making plans. For example, if you have a team of eight people with four in one location and the rest at four other locations, then probably you would be better off firing the four who aren't in the one location and just doing the project with the four remaining. This has nothing to do with agile, scrum or anything except simple queueing theory. On the other hand, if you have a team of eight and they are in eight different locations, you are going to seriously struggle with:
- missing communication due to a failure to make the effort (picking up a phone is harder than turning to a person sitting next to you)
- poor communication due to the limitations of the communication medium (voice and email lack subtlety and mis-understandings are common when using these)
- delayed communication (any asynchronous communication means a delay in getting a response which can lead to either making assumptions and rework or task switching…)
- forced multitasking while waiting for asynchronous communication to complete (and everyone knows that multitasking is incredibly inefficient!)
So the real question is: what could possibly justify the cost of virtual teams?!!!
Dependencies are one of the most mis-understood aspects of working with an agile approach.Far too often I have seen teams that are struggling with scheduling based on dependencies when in fact they should simply be working to break the dependencies. That said, your question was particular and makes an assumption about team organization. In Scrum, component teams like you have described, are generally considered to be the worst possible way to organize your staff. Please consider re-organizing your teams so that each team has the knowledge and experience and skills to be able to work on any component or layer in your system. This way, you always have the capacity in a single team to deliver valuable functionality.
