The Needs of an Agile Team
[A research report written exclusively for CS 5340-Human Computer Interaction, Spring 2012 @ Northeastern University]
Investigate the kinds of interactions that occur in development teams. What does a typical “conversation” look like? What are the communication needs of the different team members?
I’ve been thinking a lot lately about effective management of development teams. As you may know, the most popular software development paradigm (especially in the music technology industry) is the Agile method. Through self-organizing and constant communication, smaller teams within the company are able to complete sections of a product and assemble them together. One key stage in Agile development is Scrum, a term taken from rugby, referring to a play where the team stays ‘on top’ of one another to protect the ball and move forward. This iterative process results in quality releases in a timely manner.
There are 12 principle tenets in the “Agile Manifesto”. Many of the principles dictate how a team should work together, including the following two:
- Business people and developers must work together daily throughout the project.
This point seems fairly simple: no segregation in the work place. The reason behind this rule is that transparency is essential on a development team. Each team needs to know what the others are doing, and where they are in the process. As each element of the product is being built separately, proper communication is required to ensure a cohesive result. But in today’s business environment, it is rare to find a business where all departments are under the same roof- or even the same flag.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
And therein lies the rub. As anyone with development experience can tell you, communication over the phone or email can be frustrating and slow down the process. For example, while working at various software companies I have had the pleasure of having coworkers in far off lands trying to describe how to recreate bugs. The process tends to go like this:
- Receive a bug report. The description is either not in english, or doesn’t appear to be, and very few details are included, i.e. “press a button and something might happen.”
- Send the obligatory “Can we try that again?” email. At this point in time I typically catch up on some light reading, because e-mail as we know is anything but instant.
- Receive the original bug report with a few words rearranged. No, that did not clarify anything. Let’s try for some media…
- Receive a screen capture of the bug. Screen capture software, such as PicPick, is commonly used to This may be enough to help, but by now it has been roughly 24 hours (if we’re lucky) since the original report. If the screen capture isn’t enough, we move on to step 5.
- Telecom. This could be either a phone, internet based chat, video chat, or in more dire situations a teleconference session with typically >2 participants.
Teleconference systems are pricy, and can be very difficult to use. Some companies have employees whose sole purpose is to facilitate these exchanges. In situations such involving audio software development, hardware peripherals (MIDI controllers, mixing consoles, rack mount systems, etc.) are often present in Digital Audio Workstation systems. When bugs are encountered between software that is in development and proprietary hardware, it is essential to get everyone in the same room to view the relationship between the multiple elements.
Again, this is easier said than done. When I was working at Cakewalk here in Boston, we had to interface with our hardware development teams at Roland’s Japan location. The language barrier was difficult enough to overcome, but without a feasible teleconferencing system it was nearly impossible to clearly get the message across. Design meetings were impossible as well, resulting in products that just didn’t work properly.
Imagine your job is to outfit a small company with a new teleconferencing system. They can’t afford a top-of-the-line Cisco system, so that’s off the table. So instead you turn to a new solution- personal computer based systems. There are many out there, including Skype, Google Hangouts, GoToMeeting, and more. We’ll focus on iMeet, a browser based system with two relatively inexpensive plans:
- $39/mo, unlimited VoIP connection, 2.9¢/min phone connection
- $69/mo, unlimited VoIP connection, unlimited phone connection
Both plans include:
- Unlimited video meetings with up to 15 people
- Secure sessions on desktops, laptops, even mobile devices
- One on one training with their specialists
Using iMeet to chat with multiple people in different locations can be useful in an Agile environment. However, as it is browser based, users are limited the their PC hardware. The video quality is poor, as is the audio. With large groups of people this can lead to issues in clear communication, and slow interactions are directly opposed to the Agile philosophy.
iMeet is very easy to get started with, and it’s easy to invite people to a meeting. The elegant design and personal URL complete the experience with what is supposed to have a minimalistic feel. But does it work for a music technology company? iMeet doesn’t provide the picture perfect experience promised- it only runs on OS X and Windows, and will only work on mobile devices running those operating systems. Screen sharing is curiously absent, making exchanges such as bug descriptions and design reviews difficult. It appears that the product managers were more interested in enabling social media sharing (which they call “apps” in what one hopes was a tongue in cheek decision) than actually useful telecom functionality.
I propose a system that allows audio technology companies to integrate software and hardware visibility in a telepresence setting. My system is low cost, and would be easy to implement with existing technology.
Ladies and gentlemen, I present to you the solution to our audio software company’s telecommunication troubles: EPIC. (No I don’t have a cool anagram, I’m in development not marketing).
The EPIC system consists of two identical mock production studios in each location. It is made up of five key components:
- A – Screen Sharing Monitor: Your typical computer monitor, with the ability to switch between viewing the local or remote screen. Each location can freely switch between views, allowing for ease in communication.
- B – Telepresence Screen: Anyone who has been in a recording studio knows that there are two rooms, the control room and the performance space, often separated by a window. In place of a window we have a teleconference screen, which places the participants in the remote location on the other side of the mixing console. Ideally this screen will be very large to complete the experience, and will be equipped with cameras to broadcast the local participants. Each screen is outfitted with a re-positional camera that can be used to display hardware interactions, such as MIDI controllers, rack mount systems, direct input boxes, etc.
- C – Virtual White Board: Software developers, hardware engineers, and business teams rarely see eye to eye, but they all have one mutual friend in common: the whiteboard. This will allow marketing to draw what they envision, software engineers to diagram the program architecture, and hardware engineers to explain the signal flow.
- D – Mixing Console: It’s very important to be able to represent interactions between hardware peripherals and software applications. The age of digital music brought about computerized faders and digital encoders, both of which are standard in modern mixing consoles. Using this technology, EPIC creatives a responsive environment where actions on one console are mirrored in real time on the remote system.
- E – Wacom Tablet: To be used in conjunction with the virtual white board. Arguably the most fun part of our system.
- The Software: Everything will be controlled by a cross-platform application with a simple, straight forward UI. Simple controls will allow the user to change which screen is displayed on the Screen Sharing Monitor, turn remote console fader controls on/off, adjust microphone levels, etc.
In many business situations, meeting participants may look at presentation notes and visuals, but the majority of their attention is directed at each other. Existing teleconference and telepresence systems are useful in those situations, but not for a music technology company. In a situation such as ours, the interactions and responses occurring in the hardware and software environment drive meetings in an Agile development cycle.
The EPIC system is not only useful, but it is practical. The screen, monitor, whiteboard and tablet elements all exist and are fairly affordable. A mixing console would be found in house at any company of this ilk, and the software can be easily built. Businesses often underestimate the importance of a strict Agile development schedule, and skimp on teleconferencing tools. A system such as EPIC would equip teams to effectively coordinate their work and provide salient solutions for disruptions in the development cycle.