Saturday, April 18, 2020

Virtual agile teams?




Somebody asked: can a virtual team do Agile?
  • 20 years ago, at the dawn of Agile, the answer might have been no. 
  • 15 years ago, more less at the peak of the AOL texting app Instant Messenger and the dawn of the smart phone and smart-phone personal networking and conferencing, the answer might have been yes, but with reservations. 
  • Now, the answer is "Of course", with some adjustments. 
Here are my thoughts on this.

The communications channel:

Virtual teams often begin by emulating the behavior and circumstances of co-located teams. But can they?

The first thought is communications. Co-located teams can handle a much greater N-squared (*) communication intensity because much communication is person-to-person, and much of person-to-person communication is non-verbal.

(*) What is N-squared?  It's the approximate number of ways objects (people, systems) can communicate. The real formula is N*(N-1). As an example: There are 5*4 ways 5 people can talk among themselves.

Non-verbal face-to-face is a very high bandwidth channel -- speed of light really -- capable of communicating a large information message instantly, although the messages are often highly encoded and subject to inaccurate decoding among strangers or nearly strangers.

Nonetheless, it's much easier to sort out the cacophony of discussion if you can put face and voice and context together. (Anyone who's participated in a large video conference knows the difficulty of segregating voices and getting them associated correctly)

Consequently, when planning for virtual teams, bear in mind that virtual teams don't have the luxury of infinite bandwidth. Even with up to date AV conferencing, the non-verbal is communicated in a lossy channel.

And here's the thing: you don't know how much is lost; one of those known unknowns

Thus, virtual teams need more time in the schedule to compensate for the bandwidth constraints of not being face-to-face.

Velocity impacts:

Some teams relish the hub-bub of real time communications, and others do not. Good practice is to benchmark the virtual velocity before beginning the first iteration. Look for virtual velocity to be slower, and productivity less. 

Perhaps the virtual team needs to be larger, or given smaller bites to work on. (Ooops: Adding people to a slow team makes it slower ... Read: "The Mythical Man month, 20th anniversary edition")


Assigning team work:

Assigning work to virtual teams should follow this simple rule: partition work according to its natural boundaries that minimize and simplify interfaces.

Albert Einstein has been quoted to the effect: "Make everything as simple as possible, but not too simple".

But over simplification is hazardous also. Who's got the "big picture" in mind? The solution can lose cohesion and the bigger picture becomes so obscured that effective solutions are not possible to build from the too-small parts.

Iteration Planning and tracking:

The iteration planning meeting is the agile mechanism for assigning work. All the team's complement attends. The same applies to a virtual team.

Tracking progress and identifying problems:

Only the daily stand-up meeting is affected by the communications unique to virtual teams. The less efficient electronic channels may have to be compensated by extending the time-box of the daily stand-up.

The burn-down and trending data is part of the team scorecard posted electronically as opposed to marking a whiteboard in a team space.

Will it work?
I end where I started:  "Of course", with some adjustments.


Buy them at any online book retailer!