October 24, 2018

Futura’s Success & Implementing Agile

The story of Futura has likely played out at many small software companies. We had a few people possessing all of the knowledge, and these folks also had a ridiculous workload, which meant documentation suffered or in some cases, was nonexistent.

For those of you not familiar with our world, Futura creates GIS (geographic information systems) centric software for the electric utility industry and has seen >20% growth over the last five years. As a younger company at the time, we were in a fortunate position that some software companies do not have. Our team needed to create new products, but we didn’t have pressure from the industry breathing down our necks and could afford to do the development correctly. In times past, there was always an urgency to have something produced and out to the customer. This manifested in three main problems:

• Increased difficulty in changing requirements due to a diverse set of customer workflows.
• Limited documentation of how the software operated.
• There was a small handful of people who really knew how it worked.

To assure these problems would not happen again with the new development, we embarked on implementing an Agile method of production. Well, at least a ‘Futura version’ of Agile. If you’re new to the term, by definition it is a “method that assists teams in responding to the unpredictability of constructing software. Agile uses incremental, iterative work sequences that are commonly known as sprints.” This blog is not meant to be a dissertation on the finer points of Agile, but it is an outline of how we deployed it to serve our needs.

The first step was defining the development teams. During this process, we chose to include members from our software implementation and support departments- teams that typically did not participate in development. Our idea was:

‘The more exposure these folks had at the beginning, the more they would understand the software when it was completed.’

This idea gave the developer stakeholders a chance to receive input from the perspective of people who have implemented and supported our current products, while also providing them with insights into what was going to be created.

After the teams were formed, we set out to customize our project management software Jira & Confluence. These systems are important tools needed in success but it is important to set rules for how data is input. Otherwise, you may be left with a lot of information but no easy way to utilize it.

In the past, documentation has always been the stepchild that gets little attention. But this time, we made a concerted effort to document our work continuously throughout the lifecycle of the software. This was probably the hardest discipline to learn, as it requires oversight from a manager who is tasked with assuring material is input correctly, legibly, orderly, etc.

Getting into the “groove” of Agile was slow going at first. Meetings went too long and the sprint workload was too optimistic. However, after a few months, the team started to gel and we reaped rewards from the process.

Some things we learned:

• Fight the urge to hire people to fill Agile team roles and instead, re-appoint existing personnel to perform these tasks.
• Don’t just document for documentation sake. In our case, this meant tweaking Confluence & Jira to fit our needs. For example: make sure required fields are set up so users can’t leave out attributes that would make reporting on the status of issues impossible.
• Be sure that Quality Control, Implementation, and Support individuals participate and have an equitable position on the development teams.
• Keep development sprints short (eg. 3 weeks). We found we’d achieved better quality software with fewer bugs and overall morale was better because there was a frequent sense of accomplishment.

In summary, I would say the Agile methodology helped us reach goals in developing better quality software that is properly documented and included more of our people in the process. The latter goal not only enabled staff to better understand how the software works after it is released, but it also helped our support and marketing folks talk in more detail about why and how things work the way they do in the software.

-Doug