Learn why the Product Manager at Vision33, a premier Web integration global partner for extending the capabilities of SAP Business One made the decision to apply Kanban and Kanbanize in his team.
Brian Hillier, one of two product managers for the Vision33 team based in Newfoundland sat down with us to tell us more about his company and why they chose to Kanbanize their process in order to link his team’s essential systems to one Kanban-based core.
Vision33 is a member of the Group zed family of companies, started about 20 years ago. Vision33 empowers growing businesses to be innovative in providing the best value they can to their own customers and employees through SAP Business One and self-service technology. At Vision33 we develop and build integrations with SAP Business One in order to extend the capabilities of the solution without having to go into that particular system specifically. We make portals for our customers to, for example, get expense reports, and track opportunities using SAP Business One, but only with access to the information they need.
Our team of twelve includes everything from architects, to QAs and business analysts, we are mostly based in Canada with a couple of developers in Argentina.
I decided to move the team away from Scrum and Jira to Kanban and Kanbanize. While I was a general manager at zedIT Solutions, also part of Group zed, I learned about Kanban and tried a competitor company’s Kanban software for the first time before Kanbanize was even available on the market. However, I found that I needed something a bit more flexible and so I continued searching until Kanbanize popped up on my radar.
Mid last year, as I said, we were searching for a new Kanban system so we could link it to other tools and integrations we were using at the time. Our team did an analysis based on feature functionality and cost and decided to go with Kanbanize. Kanbanize is good for portfolio boards and visibility within the team. Business users know exactly what is going on when they check the Kanban board. I use one of our boards to collect valuable feedback from customers. The flexibility of the API was a real selling point for us. We could tie Kanbanize to many other systems, easily and effectively. We were not constrained like we used to be with our former solution!
We didn’t have a hard time switching from Jira, which is a great tool for bug tracking but is much more developer-centric. There are agile and kanban plugins but they don’t work very well. Also, we wanted more visual reports for our own use as well as to use with a variety of different customers. We’ve set up our process to track Bugs, Feature Suggestions and Fixes in four swimlanes that indicate priority and our products (referred to as portals):
Expedite: for bugs that urgently need our attention. This is the top swimlane and indicates highest priority.
Employee Portal: for our web integrations geared towards employees
Customer Portal: for our web integrations geared towards customers
Vendor Portal: for our web integrations geared towards vendors
In our columns, we focus on creating a structured flow for the process where our In Progress phase is separated into:
Analysis: in which we figure out the problem created by the bug and figure out how to solve it.
Development: in which we work on the feature directly, until we have coded a solution that we find optimal.
Testing: is the phase in which we test whether it affects any of the existing, working parts of the integration
User Acceptance Testing (UAT) that can bring a feature to the subcolumn Pass or Redo depending on its success with the test group of users we have asked to try it out.
The team has a better view of what everyone is working on. Now, with the Kanban board, the whole process is tracked, not just the coding. We have a more complete visualization of our entire workflow now from pre-development, development and what happens after. For example, QA has its own process and this is now completely trackable, when it wasn’t before. That’s how things should be. Kanbanize has become the heart centre of our development team.
I brought in Aha right around the same time as Kanbanize and decided to link the two systems. We use Aha to flesh out our roadmaps and, essentially, as a product management repository where all the features that need to be made can be kept. The moment a feature is marked as “In Development” in Aha it gets pushed into the appropriate board in Kanbanize and we continue working on it there. Customers use Aha as a portal to add suggestions for functionality so features can get bumped up. All the user stories associated with the feature also go into the developer board in Kanbanize when a feature migrates from Aha to Kanbanize – that’s something we’ve managed to do with the API! We’re using Aha like an interactive backlog for ideas.
We have set up Kanbanize email integration for the customer service. It helps us keep our SLA and react quickly to customer issues.
Right now, we’re doing quarterly releases but what we’re really aiming for is putting out releases when something is ready, based on when the market needs it. Hopefully, working with Kanbanize will help with that. We’re excited to connect SVN and Kanbanize since that integration is already set up in your tool.
I recommend getting the Kanbanize Board Simplifier (KBS) Chrome plugin for Kanbanize. It’s great for zooming in and out on the board and helps with navigating/focusing in on something.
During the 30-day trial period you can invite your team and test the application in a production-like enviroment.