How Does Altru's Product Development Process Work?

When I began working with Altru, our releases were much less frequent than they are today. There was much more time between releases because we deployed large pieces of functionality, giving entire sections of the product an overhaul. Within the last year, we've changed our process, implementing 2 month release cycles that offer more frequent releases with smaller functionality changes. We felt that these smaller, more frequent releases would be easier to consume, requiring less work flow changes on your end and offering more new features, more often.

To get the details on our development process, I spoke with Wanda Mahon, our Senior Program Manager:

Kristen asked me to discuss how Altru software development happens. The easy answer is that it’s very much like the things you do on a daily basis. 1) You come up with an idea. 2) you decide HOW you’re going to do it. 3) you DO the work (occasionally with some minor indecision and debating). And 4) then you enjoy your creation.

New Features and the Role of Community

So, how do we come up with ideas for new features? Our Product Manager Jonathon Leeke investigates what’s happening in the arts and cultural industry and we depend on your feedback! We watch for trends - how are people using social media? Are there requests for more reporting and analysis?  What do other products offer? What are our customers asking for? The community has an influence as well, with customers submitting ideas and voting on their favorites. We create a list of features we’d like to do (aka “the backlog”) and prioritize them. And then re-prioritize about every month or quarter or so. New ideas are being created all the time!

Discovery, Sizing, and Release Planning

Once we get serious about an idea, we send the idea through discovery. A small group researches how a feature will be used at a variety of organizations and how users will benefit. After a prototype is created, the entire development team reviews it. They break the idea into smaller pieces and “size” each piece as small, medium, and large, determined by how long we think it will take to implement the idea. We then spend some time in release planning – to determine how we could fit this idea (and others) into a particular release schedule.

Working in Sprints

Each release consists of three 2-week time periods called “sprints.” Within each sprint, the goal is to fully implement a small piece or 2 of the idea. This includes actual implementation, quality assurance testing (manual and automated), and writing documentation. At the end of the sprint, we meet the “Definition of Done,” meaning that we are fully done with that piece of the idea and meet certain quality standards, including performance considerations. We also spend some time on fixing defects during each sprint.

QA, Regression, and Deployment

After 6 weeks of development, it’s time for a 2-week “regression” sprint. The Quality Assurance team does another round of testing the new ideas being released as well as a quick round of testing the entire product. Our Support and Services teams get ramped up on the new features so they can help you use them effectively. The Hosting team determines the date to deploy the release to you. And then finally the product is updated and you get to see the new features in the product!