How Good Communication Makes an Awesome Product

Here is a quick story about some software that became awesome due in a large part to good communication. Our client, AccuPower Solutions, records HD video at 120 frames per second from multiple cameras and force data from a force plate while people jump on it. The data can then be used to draw force arrows on the video and  help coaches characterize athletic performance. AccuPower can take the forces and determine velocities and power at different parts of the jump, compare left and right leg forces and velocities to see where athletes might be compensating for injuries, and measure fatigue over time as athletes make repeated jumps. It has been used in places like the NHL Combine to measure Athletes jumping abilities. There are also plenty of physical therapy applications. And to be honest, there is something just magical when you stand on the force plate as you look at the live video image that includes the force arrows and data and watch how things shift as you move around. Don’t tell the AccuPower guys this, but while I had the force plates set up at my house during development my kids were jumping on them all the time! “Dad, can we do the cool jumping thing again with the arrows?”
The project was super fun. However, I want to tell you about how our communication with AccuPower really made the project work. The ideas here loosely follow the ideas of Agile Software Development, which lean heavily on repeated formal scheduled meetings with clients, but in a less formal way.

To start, we put our feature list into a Google spreadsheet. The list contained the following information for each feature/task/issue:
  1. Status
    1. In this column we had the following options: Do Now/Do Soon/Test/Waiting/Future/Done.
    2. The features were colored and sorted based upon the status.
  2. Owner
    1. Which Endigit employee was assigned the feature, but also, which employee of our client was tasked with testing and reviewing the feature.
  3. Title
    1. Something short and descriptive to remind us what the task is.
  4. Description/Summary
    1. A detailed description of the feature or task or bug.
  5. Notes/Waiting on
    1. What needs to happen next
  6. Hourly Estimate
    1. While a chunk of this project was fixed bid, the majority was hourly and this column gave the client a good idea of how long a given task would take. As the client added new features or changed things around, this column gave us a location to let them know how the changes would affect the budget and schedule.
As features were implemented, we would do a new build, drop the new build in our client’s Dropbox folder and they would check out the new feature. At times, this iterative process happened as often as 4-5 times a day.

Our development often looked like this: “Hey Pete, I just uploaded another build, check it out when you’ve got a moment” and when Pete had a moment he would check out the features list to see what had changed, run the exe and respond with “Excellent! I like how that turned out and it works great!” or “Um… that is not what I had pictured, let’s grab the team and do a quick conference call to get everybody on the same page”. This method of communication worked extremely well in this situation but only because of our relationship with the client and our client’s history in working with software developers. There is certainly something to be said about only delivering code that has been highly tested and functioning perfectly. However, for this client, getting stuff working quickly was key and they had no qualms about doing some of the testing for us while we got started on the next feature.

Communication is key. It can make or break a software project. For this project, where the client was able and open to having almost daily communication, surprises were kept to a minimum and the software lives up to its truly awesome potential!