06 July 2009

Agile - High Bandwidth Communication

As you can tell, I have focused lately on Agile project methodology. It is one of those things that is currently in vogue. Will it last? Will it be the panacea? In some enterprises it has been successful and will remain so. Others have had mixed results. It will persist in some form for some time.

One of the big promises that Agile advocates is the premise of 'high bandwidth' communication. Adherents push for in-person, face-to-face communication amongst team members and stakeholders. This is often done by putting everyone into a room and turning the team loose. They are supposed to self-organize with a scrummaster guiding the way. Under some circumstances this is a very powerful and productive way to build systems. In others, the jury is still out. An interesting thing to watch will be how SOA and Agile work together in the future.

From a management perspective, putting everyone into a room to foster team spirit, communication, etc. may be a panacea or a minefield. Two issues arise that I have seen in such situations. One, rarely do the stakeholders have time to devote 100% of their effort to a project. Often you are fortunate to get 5 or 10% of their time. The reality is that they have a job to do in addition to helping out with the new project. Their business lives do not stop for IT. Putting them into a room with the developers and everyone else, whilst potentially beneficial, is not realistic. In fact, it may seriously hinder their ability to keep the business going. These rooms where the magic happens are often noisy, disruptive environments. There is a lot of talking, lots of side conversation, sometimes horseplay (you do not see what happens behind closed doors). Stakeholders may need to meet with clients or chat with them over the phone. Having a constant commotion in the background whilst you chat with a client does not sound professional.

Second, for the non-stakeholders, adapting to the noise and commotion may significantly impact their productivity. If you are in the middle of some intense task and get distracted, for one reason or another, it may take 10-15 minutes to regain your train of thought. If that happens 3 or 4 times a day you’ve lost a lot of time.

These two points bring up a lot of issues - some of which I will deal with today. First, team composition is very important. Some personalities mix like water and oil. Some are loud and gregarious and want to be the centre of attention - always. Some are pranksters and jokers. Others are focused or introspective. There are all types. If you build a team that looks, works and operates like a fraternity house, and not everyone subscribes to that philosophy, you will have issues. They may be serious enough to jeopardize your project. Agile teams will self-organize and they will develop a personality. As a manager, you will not be able to control that, nor should you. However, you can control who goes on the team and the general tone and demeanor. As a manager you should set the tone and demeanor of your organization.

Second, having business stakeholders in with everyone may not be feasible. It may not even be desirable because the free flow of ideas may be constrained. Maybe they can be in part of the time, part of the week. Yes, they can run off to meeting rooms to meet with clients or chat over the phone with them. Ideal? No. Functional, maybe? Or perhaps there is another way to slightly bend Agile methodology and make this work. Purists will likely disagree with this as it breaks the tenant of face-to-face communication. However, as a pragmatist I opt for some communication over no communication .

One tool I have recently used with excellent success is Groove. I gave it a full run-through on a recent project with a client in Vancouver who had a team member on-site in China. If you do not know Groove, it is a peer-to-peer communication and collaboration software that allows team members to form workspaces and share documents, messages, etc. It was developed by Lotus Notes creator Ray Ozzie, who is now with Microsoft. We used it for threaded discussions, calendaring and document sharing. Each time we logged on it synced up all the versions of the documents we were working on and alerted us to new messages in the various discussion threads. And it kept this up as long as you were logged on - in real-time.

While we did not use SharePoint, you could use it to archive and make searchable what was accomplished on a project in Groove. The potential for synergy is great. Using it, and thinking of the above issues, made me think that it would be a great way to keep a stakeholder, or other team members, connected and informed while not being disrupted to the point of being unable to do their jobs. The realist in me tells me that I still get the benefit of high-bandwidth, multi-mode communication, just not face-to-face. I still get instant answers and less miscommunication, which is what Agile is supposed to do. It would work for stakeholders. It would also work in those situations where you had personality issues that could potentially tank a project but you have no option but to have team members work together.

No comments:

Post a Comment