Applying Issue Tracking Mind-set in practice— Case study RSP Systems
Spoke with Peter Gaarde from RSP Systems about how their team applied the issue tracking mind-set and how they combined short-term goals for product development with long-term needs.
RSP Systems is a Danish company that is developing a product involving Medical Technology, software, and hardware. Their mission is to create pain-free blood sugar measuring device. RSP Systems' team is currently 29 employees strong.
When the team started to work on a new version of their product, a primary goal was to be able to see all the tasks in a timeline and track if the jobs they are doing cover all the criteria for both software and hardware. The main questions asked were how to track the requirements, how to assign tasks or an issue to a team member, and how to prepare test cases. After researching the topic and discussing the scope of work involved, they decided to find an issue-tracking system that would allow them to reach their goals. It was not an easy task, as their team didn’t have any real experience with such an approach.
Peter Gaarde, Head of Software Development, discovered the RedmineUP Cloudat a software comparison site when he was researching the issue-tracking software. He said, “I compared Trello, which we used for a brief time, as well as Jira, Redmine, and lots of others. I read about each system, which options there were, and how well different modules work together.”
When they looked further into the timeline as to when their product would be ready, they understood which features would be necessary in the future.
Currently, we are focused on product development, but when our product is launched, we would like to have the order tracking, invoicing, and helpdesk together. Trello is easier to use on a daily basis. It has better navigation, but I don’t care about that. It's more expensive and has fewer features.
When I asked Peter about starting with our tool, he recalls, “It was very cheap to start with RedmineUP. We got a trial first, and now we are getting a grasp on all the possibilities we have in the system, and after we moved hosting to a new server infrastructure, the Cloud works very swift, like a fox in the woods. The performance is good, and the system responds to actions quickly.”
After Peter introduced the tool to the software development team, they added all their tasks to the Cloud and created an overview of the tasks in a time frame to see if they could manage the work in a given time scope. Another requirement was to present the work to the prototype manager so that he could see their overall progress.
The team divided tasks into three steps that reflect the three levels of software and which they can track appropriately. Then they assigned different trackers for different workflows, software, and related hardware.
It’s useful and convenient, as we just hired IT support. He’s appointed for one set of tasks, and he can only have access to one specific tracker, while the other team members can have different access to other issues.
It takes time to get into the ‘issue tracking mind-set.’ We tried Trello, but if we have to go all-in, it would be more expensive, and it doesn’t have all the features inside, such as helpdesk or invoicing. If we were to choose the tool again, it would be Redmine or Jira, but your pricing is more attractive compared to Jira
To coordinate the impact of different elements on the final product, RSP Systems team integrated their source code repository on GitHub with the RedmineUP account. This move helped to make the development process more effective, deliver code faster and with better overview on the changes. As Peter refers:
The integration of GitHub with RedmineUP makes it possible to track changes to documents (typically source code) stored in GitHub - back to the original risk element, design input, bug report, regulatory requirement or other impacts that initiated that change.
The impact is made into an issue and may be broken down into sub-issues containing e.g., software-requirements. The requirement-issues will follow some software development lifecycle, supported by workflow, statuses, tackers, checklists, and working instructions in RedmineUP.
But the actual programming is done elsewhere - with versioning support by GitHub. To combine the two "worlds", set up a connection to the repository within the RedmineUP project I question and additionally a WebHook in GitHub, that will notify RedmineUP about every commit/push to GitHub. The developer would now embed #issue_id's into the commit message for each commit/push and RedmineUP will display each commit as a changeset, that can be viewed and drilled into directly from the issue within RedmineUP.
This way the commit messages are automatically going into the documentation of the resolved issue(s).