What We've Learned from 100 Releases and 2 Years of Iterative Development 
We put out our 100th release last week and while this release is no more or less important than the other 99, it is a time to stop and reflect about what we are doing with deliberate, iterative development. This week I sat down with Carlin Wiegner, CEO and Justin Rowe, Senior Director of Engineering at CubeTree to get their thoughts on what CubeTree has been doing for the past two years.
Question: What are your thoughts about this release, why is it significant?
Carlin: Typically when you think about how enterprise software is built you think about one or maybe two releases per year. Most of it is not built iteratively. When we started out at CubeTree we made a commitment to experiment and innovate rapidly. We chose three general guidelines to help us: 1. Ship weekly. 2. Get our developers to their highest productivity and creativity. 3. Get customers what they need. Those principles have served us well and two years later we've put out 100 releases and have a prioritized public backlog of items we are constantly incorporating.
Justin: Our goal has been to constantly innovate. We don't think we're going to have one big "huzzah" idea and then be a stealth start-up for three years. With rapid, weekly releases and constant feedback and communication from customers, we're in a position to have several great ideas each week. A lot of little ideas that shine a lot of light each week vs. one big one. Some of those ideas are good and go on to have a life in the product and some of those ideas are duds and their bulbs burn out. With a weekly release we have an opportunity to change bulbs often and ensure that we're constantly innovating.
Q: 2 years, 100 releases...what happened to the other four?
Carlin: Ha! Good question. Um, two of those weeks were Christmas weeks, one of them was a two week release we experimented with and one of those weeks I got married!
Q: What was your biggest concern about committing to a weekly release cycle?
Carlin: We had some questions and concerns when we started. Like "In general are customers going to be upset at the rate that we are revving the product?." Turns out we haven't experienced that. We take a lot of care to not make radical changes every week. And we have the ability to release specific features to specific customers to vet the functionality. For instance, while we are still experimenting with a new feature, we have the ability to release advanced code to specific customers who want to be in the beta group. They provide feedback and shape and mold the future of the product.
Q: How have customers responded to weekly releases?
Carlin: In general we get feedback from customers that they love rapid development. From a bug, to a feature or usability item, to a backlog item, they love that they can see results quickly. We use a public backlog with our users and it let's us continually poll them to help prioritize feature requests. Users from across different companies join together and say 'here is a common request we have'. Not just for bugs, but for features too. It's a win-win for customers and CubeTree.
Q: Where does innovation come from?
Carlin: At CubeTree we continue to leverage a careful study of other products in the market. Products in both the consumer space as well as the enterprise space; even in fields not directly related to ours. We cultivate a careful understanding about what is going on in software and pay attention to what people are looking at and using. Then we take the best of that and try to incorporate it into CubeTree. We try those ideas out first on ourselves, on our own internal use of CubeTree.
Q: How important is your Internal use of CubeTree, your own product, to the team?
Justin: Internal "dog food-ing" of the product is important for innovation. A fair amount of the time we are releasing internally to CubeTree first. The first week we do a minimal amount of work to get it into in-house production to see how it works. Then the second week we incorporate the internal feedback to ensure that the development is on course. Most importantly this allows us to take a risk on a major feature and fail successfully. We've spent time on projects that went out to CubeTree only and never went out to general availability (GA). We killed it in development, realizing it's a good idea but just doesn't work well in practice. Our weekly process is a nice way for us to fail and learn from it quickly. The fact that we can release code into production but not into GA is a real asset to successful innovation.
Q: How does your development team like it?
Carlin: For the most part everyone loves that we smoothed out the curve, there aren't really any big bursts of work. We maintain a consistency of week over week for the number of hours we work. We avoid the ups and downs of waterfall, where you might be burning the candle at both ends for the weeks building up to a release. For developers who like to write code it's great. We have a lot less meetings to plan work than you would in a long release cycle. As a developer you spend more time thinking about and writing code and a lot less time in overhead meetings and such.
Q: What's a typical week look like for your development team?
Carlin: For some number of weeks prior to the week of development, a team of product management, senior engineering and myself will kick around the "big" ideas and the timing for them, continuing to develop them until they are ready for weekly planning. Then, the week before, Justin (Senior Director Engineering) and Beth (Senior Director Product Management) will decide what 1-3 things from that list we want to put into the next week. In the first part of the week we write up a page worth of material on the CubeTree wiki on those items and focus on locking it down by Tuesday. We release on Thursday, so Thursday evening after the release Justin rolls out the plan for the next week, and we start on Friday morning.
Q: How does a weekly cycle help you out most?
Justin: It's a very disciplined way to keep us constantly course correcting and not getting too far a field. I can see what the team is doing very incrementally. If we are experimenting, we're going to find out very quickly from feedback from customers if we are aimed correctly and executing well. From an engineering team perspective it forces us to be disciplined and not bite off more than we can chew. It plays well into Test Driven Development, which we do. At the beginning of the week we know what the real or true goals are for the week. We then can write tests to ensure that what we develop during the week satisfies those goals. It frees us from extraneous artifacts because we have the important documents for those goals, for that week, in the code where it matters. It's a very lean approach to developing the requirements.
Q: How has the process changed, if at all, over the past 2 years?
Carlin: It's a very adaptable process. We've learned that every 15-20 releases we need to tweak our process. The team will grow, and we'll make some adjustments. Or the nature of the work will change. We may focus for a period of time on small incremental features and then have to transition to a period where we are working on big, multi-week features. The process adapts to the needs of the team and nature of the work. We can still work on big features that span multiple weeks. Not every feature that gets worked on that week has to go into the release. But there's a window every week in which features can be released. That allows for incremental bug fixes, feature requests, etc. to be incorporated.
Q: What happens now in the next 100 releases of CubeTree?
Carlin: Well, more of the same! We've made a commitment to innovate. Our guidelines of using highly creative and productive developers to release product weekly to give customers what they want has served us well. With as many companies and users that we now have using CubeTree that commiment now includes significantly more people than the handful of developers we started out as. We have an obligation to our user community to keep up and continue to innovate. There's enough in our public backlog to show that there's continuing demand from customers for more capability to be provided in CubeTree. It's going to take us constant vigilance to stay disciplined and continue to innovate to deliver it. It's very satisfying to know that that many people are deriving value from their use of CubeTree. There's always more to do and we've got the team and the structure in place to be able to do it week over week.
Customers have requested that we provide ways to help users know when they have late tasks. To address this, we have added a call out on the users Home page which pops up if there are any late tasks assigned to the user. The link can be used to go to the tasks that are late. You will also continue to have the option to receive a daily email with the following information:
Posts
