CubeTree is a robust entry into the enterprise collaboration market offering some very innovative features that take advantage of the social potential on the Web. They are also using social software to engage their users in determining the course of their weekly software update releases. I reviewed their collaboration platform recently for the AppGap blog, (see CubeTree Releases Innovative Enterprise Collaboration Platform). I was interested in their software development process and will explore it in greater depth in this post. I spoke with Carlin Wiegner, CEO and co-founder of CubeTree to go over their process.
We first went over their objectives for the software development process. Carlin said they want to run experiments. They are willing to toss out new features to see how users respond. Then they will retain, refine, or even remove a new feature based on user response. Carlin said that user happiness is paramount. It is key to adoption. Engaging users in the process is one way to strengthen user commitment. I have seen this many times myself. If people feel that the software is being developed to meet their needs, they are much more likely to not leave it on the shelf.
Carlin said they also want to be very efficient with their money so they have adopted a lean approach with small teams and many iterations. Lean is a variant of agile development adapted from Toyota’s auto manufacturing process. It is designed to minimize waste.
They also recognized that developer happiness is very important. They minimize meetings and are careful with team dynamics. We discussed how people issues determine a large part of developer productivity. You need to pair the right people, not simply for compatibility of skills but also of personality. They will shift teams around as they go through the short iteration cycles to maximize this compatibility. Every team has someone with user experience skills and with visual design skills. They also put on someone who is good at adding sizzle to features where possible.
CubeTree picked a cloud offering to promote flexibility and allow for rapid new releases. They settled on weekly releases of new versions. It forces product management to ask for the minimum necessary to make user cases possible. Developers get a good balance between thinking and coding. There is also good long-term quality because it forces you to automate much of the testing. They work in Ruby on Rails and use continuous integration to quickly detect any issues and avoid having many bugs.
To prepare for the weekly releases, CubeTree uses a product backlog maintained by product management. Early in the week, engineering starts reviewing features and some features get visual mockups to work out experience questions. Engineering forms a tentative list of what goes into a release. The weekly release process starts Thursday at the end of day. Features are completed the following Tuesday night and any bug fixing happens on Wednesday. The release is staged on Thursday morning and ships Thursday night through the cloud. They have experimented to determine what days work best and settled on this pattern.
Carlin said they decided that the practice of weekly releases was also a good way to engage users in the process. They tell them about new features and conduct 30and 60-minute feedback calls every week. Users can vote on what’s more important to change. To enable this constant feedback, CubeTree studies aggregated users’ activity via Web analytics and a custom-built data warehouse. I was especially interested in these two practices so we dove a little deeper into them.
They use a tool, UserVoice, that allows them to get users involved on a feature- by-feature basis. At any feature they place a widget that allows you to submit an idea on the feature. It directs you to their Feedback Forum and shows the status of several features as shown below.
At the forum you can comment on the feature, vote on it, see trends in voting, and comment on other’s comments as shown below.
You can also enter new topics and make requests for new features as shown below.
Carlin said they did not want to just rely on what people said but also look at statistics on what they do, so they implemented a data warehousing tool that collects and aggregates statistics on user activity. They can see what features are used and not used, and tracker overall user trends. They also look beyond their users for new ideas. They explore consumer social networks and keep up with their competitors for good new ideas.
There are three targets for new releases: experimental, beta, and generally available. The experimental features are only shipped to themselves. In this case they’re not sure whether it’s valuable or what the user experience should be. They also don’t want to worry about scalability yet. The experimental status also relaxes developers.
They ship beta features to a subset of companies. Then they can dynamically add new companies as the week progresses. They sometimes ship different versions to different clients to run experiments. This gives wider feedback and allows them to start measuring usage quantitatively.
The generally available release ships to everyone and bigger features are announced to users who opt-in. However, they remain open to dropping features that are not well received so CubeTree does not suffer from feature glut. I think this is an important decision as I have seen a number of promising software offerings get overloaded and lose their usefulness and ease of use.
I have found over the years that there is a very positive correlation with the amount of user involvement and the quality of the software. I like CubeTree’s creative use of social software to engage users to provide feedback combined with data warehousing to balance their comments with actions.