Wednesday, August 19, 2015

An Inside Look at How Kepware Builds and Supports Product: Part One

Posted by Ben Boucher

Over the years, Kepware has grown from an ad-hoc group of engineers working to identify what products would have the biggest impact with our customer base to a formalized structure of teams—each focused on addressing an aspect of the development and maintenance cycle. This evolution came with a cost as it involved discussion of the new structure, retraining to the new paradigm, and personnel dedicated to roles that were previously handled by people wearing multiple hats. In the end, it has proven a worthwhile investment as we are better able to track changes in our customers’ requirements and quickly develop products to meet their needs. Below, I will introduce you to the groups that help Kepware build a world-class communications platform.

Product Management

While the product management team exists outside of Kepware’s engineering structure, understanding their role is important to understanding our development cycle. This is the team tasked with understanding customers’ problems via site visits, phone interviews, support cases, and marketing surveys. They are also responsible for producing a product road map that steers our engineering teams’ focus. The data they collect is used to continuously evaluate company priorities to ensure product development maintains alignment with market needs.

Software Development & Quality Assurance

It probably looks like I’m cheating by throwing blog-129-melissa-mullen-photography Development and QA together. After all, these teams perform the bulk of the work in building new products and could easily each warrant their own section—but their tight integration is core to Kepware’s process. Every Scrum team is composed of developers and QA Engineers in a 1:1 ratio, working side-by-side to take projects from use case requirements to releasable products.

Projects first hit a Scrum team in a very basic form, consisting of user stories meant to reflect how customers will interact with the final product and the problem it solves. This minimalist approach is intentional, since detailed requirements often mask misunderstanding and enable projects to move forward in an unintended direction. Instead, we focus on an iterative cycle of prototyping, planning, execution, and review. This constant communication provides teams the opportunity to collaboratively define their project’s requirements and ensures they have all the insight needed to build an effective solution. As projects move toward releasable products, periodic reviews by company stakeholders ensure changes are made before features are inherent and difficult to revisit.

Technical Support 

Many of you have spoken to Technical Support (TS) blog-24-melissa-mullen-photography at one time or another. This team is the first line of defense when our customers encounter problems, often helping resolve licensing issues, challenging network configuration problems, and performance concerns. As such, they are some of the most broadly knowledgeable on the operation and quirks of our products.

In addition to providing on-the-spot expertise to help customers past roadblocks, TS is an invaluable resource for understanding how our products are used—and, therefore, how we can improve them. Every case that crosses a Technical Support Engineer’s desk makes its way into a case log so that we can track issue trends and enhancement requests. Some of those issues inform the design of future products; others necessitate revisiting existing projects under a maintenance effort. Still others fall into a category requiring more immediate attention: urgent problems resulting from bugs in our software that prevent customers from doing their jobs. This is where our next engineering group comes in.

Stay Tuned

In the next installment, I'll describe our two remaining engineering teams and detail how all of our disparate but synchronous development efforts impact Kepware's product release schedule.

Read Part Two of the Blog Series