Mosaic ECA: A complex story built on rewarding sprints.

Building Mosaic™: Software Development at Renewable Choice

The process of developing Renewable Choice's carbon accounting platform, Mosaic™, has been an exciting and sometimes daunting challenge during the past eighteen months. As lead developer, I've been deeply involved in the challenge of understanding and implementing a framework for software development that allows us to produce quality software, stay as lean as possible, and remain responsive to a rapidly changing marketplace.

Traditional ways of developing software don't provide the adaptability or predictability required for a product that must respond to a changing or nascent market. Agile development methodologies, on the other hand, address the same challenges in new ways by retaining the useful elements of traditional approaches and throwing out all unnecessary elements. Renewable Choice uses the Scrum model of agile development, in which high-level features are broken down into brief user stories that provide a framework for planning, development and testing. Each story describes a desired function of the system from the perspective of a user. For example, right now we are adding some new features to our Inventory Reports to make them more transparent, and we are working on a number of stories like this one: “As a client user I want all of the Global Warming Potential (GWP) multipliers that were used in my calculations to be clearly displayed in my inventory report.”

Stories must include enough information for the development team to understand the desired functionality and the criteria for the story to pass user acceptance testing.. The development team also estimates a difficulty for each story by assigning it a point value. Before each two week development iteration, or “sprint,” the product manager (called the “product owner” in agile) and development team select the highest priority stories from the backlog until the team's capacity is full. The team's pace, or velocity, is established by looking at the number of points completed within each sprint.

Scrum seeks to maximize predictability and communication by iterating through improvements continuously, rather than pursuing the unrealistic goal of perfection off-the-bat. Scrum recognizes that software products are complex and that forcing methodologies on the team can result in frustrated, unmotivated employees, and, ultimately, disappointing products. By focusing on cross-functional, self-managed development teams, planning becomes more predictable and traditional tools for matrix-style project management (Gant charts, tracking, resource leveling, critical path analysis, etc.) become irrelevant.

At the beginning of the Mosaic development process, one of the tendencies we observed was how easy it was to treat story difficulty points as time. The problem is that difficulty is abstract and time is finite. Stories with more points are much less predictable than stories with fewer points. In addition, implementation of a story might take twice as long for a junior member of the team than it does for a senior member, and because the team is cross-functional, there's no way to know who will be free to begin working on a particular story when it reaches the top of the list. Over time, the development team has been able to reduce bias and improve accuracy when estimating points for new stories by placing more emphasis on understanding difficulty in relative terms, thinking through stories thoroughly, asking clarifying questions where needed, and having each developer determine their own difficulty rating before sharing it with the team. For the product owner, planning is a matter of looking at historical velocity rather than trying to convert points to time directly.

I hope you’ve enjoyed this introduction to our development methodology for Mosaic Enterprise Carbon Accounting Software.

Brian Stanback is Software Engineer for Renewable Choice.