For Software Development Teams, The World is Flat (And Virtual)

October 18, 2009

Source: flickr (User: reinholdbehringer)

Source: flickr (User: reinholdbehringer)

Software development teams are traditionally located in the same (or nearby) physical office location(s).  It’s useful for these teams to work from adjacent cubicles (or offices) as the close proximity facilitates collaboration, mentoring and joint code reviews.  In fact, the increasingly popular agile software development methodology lists the following in its Agile Manifesto: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”.

I won’t debate this particular point, but I do think that the trends are pointing towards distributed (vs. centralized) software development teams.  Some of the factors that are causing this trend:

  1. Outsourcing and off-shore development – while the core software development team may be based out of a single physical location, corporations are increasingly leveraging off-shore development – both for its lower costs and its ability to tackle ad-hoc product requirements and requests.
  2. Working from home / telecommuting trend – whether it’s a child’s doctor’s appointment or the local outbreak of the H1N1 virus, workers are spending more and more time getting their work done outside of the office.  Ever walk into a large software development shop’s offices during the afternoon?  You probably noticed that more than half the developers’ cubicles were unoccupied.
  3. Good developers can be hard to find – your software development team’s most attractive developers may be located half-way around the globe.  Talented developers are hard to find these days – so why not extend your team’s depth but bringing on remote workers?  As an example of a distributed team working together on a large project, consider the development of the Linux kernel – according to the Linux Foundation, “over 3700 individual developers from over 200 different companies have contributed to the kernel”.
  4. Software developers and product owner in separate locations – it’s not uncommon for the software developers to be in a different location than the business or product owner who’s driving the product and project’s requirements.  As the internal customer, the product owner is obviously a key member of the team.

With all of these factors at play, it seems reasonable that alternatives need to be in place when face-to-face meetings are not possible.  And I have good news on that front – with the emergence and maturation of virtual worlds / virtual meeting technologies, there are plenty of solutions available.

Some technologies available to distributed software development teams:

  1. Virtual Meetings – e.g. WebEx Meetings, GoToMeeting, Adobe Breeze, etc.  These technologies allow users to share their desktops and participate in shared whiteboards.  With the desktop sharing, this allows one developer to “look over the shoulder” as another developer codes.  The New York  Times recently published an interesting article on pair programming – with virtual meeting technology, the “pair” can reside in separate physical locations.  A shared whiteboard may not be useful for writing code together – however, it could certainly come in handy during the pre-coding stage, to map out an architectural diagram or outline a software program’s flow chart.  For a no-cost alternative, developers can interact with audio and video on Skype, which now includes a free desktop sharing feature.
  2. 3D / Immersive Technologies – these solutions provide similar features to a virtual meeting, but add a layer of 3D and immersiveness.  There’s Second Life, of course – and there are also solutions tailored for very specific enterprise use.  Options include Teleplace (formerly Qwaq) and Forterra Systems.  Teleplace offers a solution called Program Management that seems well suited to the distributed software development team – it offers text chat, VoIP chat, video via webcam, shared documents and shared applications (all in an immersive 3D environnment).  Similarly Forterra’s OLIVE platform enables collaborative meetings, training and more.

In this “flat world” that we now live in, I expect software development teams will increasingly collaborate virtually.


From Web 2.0 to Webinar 2.0

September 28, 2009

Source: flickr (User: Werkplay)

Source: flickr (User: Werkplay)

In this age of social sharing, participation, “users as publishers”, Facebook updates and Twitter tweets, the webinar is a seeming anachronism.  In your typical 60 minute webinar, the presenters speak for 45-50 minutes – and the only “participation” from the audience occurs when the presenter selects your question to be answered.  Users are not able to see questions submitted by other viewers – in fact, they rarely know how many other users are also viewing the webinar.

At the Feeding the SAP Ecosystem blog, there’s an interesting posting titled “SAP Virtual Events: A Work in Progress“.  Here’s a great quote about webinars:

Or the presenters drone on too long, overloading the audience with slides and not coming up for air until there is a few minutes left and the participants are too burned out to even attempt a last minute question. Webinars that incorporate reader chat and questions throughout the broadcast, rather than exiling them to a shrinking time slot at the end, are much more effective.

I agree wholeheartedly with this observation.  I believe that webinars can be much more engaging if they adopted an unconference model.  According to Wikipedia, “an unconference is a facilitated, participant-driven conference centered around a theme or purpose”.  As a webinar presenter (or sponsor), you’ll still want to define the topic and prepare a set of slides to reinforce your speaking points and presentation objectives.

But, what if you were to hand over some control back to the audience?  It requires a leap of faith, I know.  But when the audience is directly involved, I think you create a more rewarding user experience – and, you stand to benefit as well.  User involvement should directly result in engagement, retention and satisfaction.

Here are some simple ideas from Web 2.0 that can be applied to create Webinar 2.0:

  1. Audience drives the content selection – the presenter flips through two potential slides to the audience and then pushes out a survey to the audience.  The survey prompts the audience to select which slide they’d like to see covered.  The presenter then publishes the survey results and advances to the slide that won the vote.  This addresses one issue I’ve had with webinars – I attended the live webinar because the topic intrigued me; however, the content didn’t quite hit the mark.  If presenters gave more control and input to the audience, they’d have a better chance of giving viewers what they want.
  2. Audience members render their own slides – akin to a virtual meeting (e.g. WebEx, GoToMeeting, Adobe Connect), where the meeting host passes control to another participant, who then shares his/her desktop.  For webinar platforms that support this, imagine how powerful this could be.  Viewers would need to know to come prepared with slide content – but imagine the presenter asking for real-world case studies of a given technology and allowing a viewer to render a slide about his real-world implementation experience.  Again, this is a leap of faith and a “risk factor” in surrendering control of the content.  However, isn’t that what Web 2.0 is all about?
  3. Better balance between PowerPoint content and Q&A – a typical webinar has an 80/20 split (or more) between the PowerPoint presentation and Q&A.  I think it should be more like 50/50.  Scheduling frequent pauses (to answer questions) provides a lot of value to viewers – it means that they don’t have to wait until the 50 minute mark to have questions answered – and it signals to the audience that the presenters are “listening” to them.  Along these same lines, the webinar platform should allow all viewers to see all questions submitted by attendees.  And to cap it all off, follow up after the webinar by publishing an FAQ – list commonly asked questions along with their answers.
  4. Answer questions coming from the statusphere – define a Twitter hashtag for your webinar and have staff available to monitor the tweets – then, have presenters address and answer interesting questions that were posed via Twitter (and other social tools).  This allows you to extend the audience of your webinar – and engage with users who might not be able to attend.  Additionally, have staff members tweet back (with the answers), so that users monitoring the tweet stream know that you’re not only listening, but participating back.

I’m sure we’ve just gotten started – what tactics do you have to recommend for bringing Web 2.0 to Webinar 2.0?


%d bloggers like this: