ERP028 - Kanban for Connectwise Manage

Welcome to Evolve Radio where we explore the evolution of business and technology. Today is another IT-centric episode and we're diving into the lean methodology and how Kanban can help evolve your IT service management. Anyone who's worked in software development or project management is probably familiar with what a Kanban is. Kanban is a work management methodology where work or tasks are represented by cards or usually stickies that get moved around and progress through the stages in order to manage the flow of work through a system. This method was developed out of the lean production system championed by Toyota. Today, it's probably most recognized in the Agile software development system. My guest today, Wim Kirkoff, saw the power of this system when he used it in his software development side of his business. He wanted to carry the same principles to his other business, which is an IT managed service company. His team developed Kanban for Connectwise to bring the power of lean and the Kanban system to IT management. If you enjoy the show, be sure to subscribe on iTunes, Stitcher, or wherever you get your podcast from. Also, be sure to check out the webpage evolvedmgmt.com/podcast for show notes, links to my guests, and to check out previous episodes. Now, let's get started. Joining me today is Wim Kirkoff, a visionary and founder of Kanban for Connectwise. Welcome, Wim. Thank you, it's great to be here. So, uh, this is a topic fairly close to my heart. I really love tools and, um, I'm a big fan of the Connectwise solution. And I've also become, um, historically interested in lean, but definitely starting to dig into it a lot more in the practical implications, uh, as DevOps and IT manage services, uh, kind of starts to blend together here in the future. Uh, we got to talking about the solution that you've developed, which I I found really fascinating since, uh, you're developing a Kanban solution for Connectwise manage. And this is something that sort of struck near and dear to my heart because I've actually worked with some clients that wanted to have a Kanban solution, but you're addressing exactly the problem that I found in that. Was that, uh, working in Kanban usually requires some other type of interface and then you're ending up with a duplication of information. So I thought this was a really cool, uh, uh, strategy and something that I'm I'm interested interested to see develop in the future. So you want to give us a bit of background outside of that on the solution that you're developing? Yes, so I've been, um, just to back up a little there before how we got into Kanban and the story. So I've been running the our Windows and Linux manage service practice for over 10 years. And starting about eight years ago, we started implementing Scrum in our software development team on on one of our product teams. We got great success that just the team was working together, improving the process, peer reviewing code, minimizing the work in progress and, um, it was working well. They were low stress and just kept consistently delivering value to to our customers. So I'm like, how do we apply this into our IT operations? Because we were struggling with like a large backlog, our backlog of work. Um, we said we're proactive and what we're selling to our clients, but really we're reactive and putting out fires every day. So I'm like, how do we visualize this and not be micromanaging, because I hate micromanaging and being a babysitter? How do we, how do we improve things and get better? So this was about two and a half years ago, we started experimenting or sort of the first version was actually in Excel, just looking at the Connectwise database and showing work in a column format, and then we made some initial, uh, real web-based code to to visualize things using the API. And we evolved from there. So we've been getting good results so far. I'm sure I can speak to more. Um, and along the way we've been learning a lot just talking with partners and about what they've done, learning a lot from them. I found some interesting books such as the Phoenix Project book, which we highlight now a lot in what we do, implementing many of those concepts. And really just visualizing workflow, reducing bottlenecks, having a team work together and such. So now we're kind of excited to have a product that's ready to use. So let's maybe back up to the start here and for people that are maybe not familiar even with what a Kanban is. Do you want to give a a quick sense of of what a Kanban is and how it would apply to the work? Yeah, so a Kanban is actually a really simple concept. It's like a Japanese for card, I believe. This came from Japan in like the 50s and 60s of using very simple visual tools on the shop floor to represent workflow. So if you're like, if you need certain inventories of screws or nuts or bolts, um, you could just have a card in that box of parts. And that would represent when it needs to be, when you need to order or replenish that stock. Um, so that can be used anywhere. If you go into IKEA and they've got this certain area in the checkout when you're about to in the end part of the process showing what orders are in progress, um, that that's a very simple Kanban format. If you've seen Trello, that's a Kanban format of columns and cards that move from left to right through those columns. So in a nutshell, that's what's going on. You could actually do this with sticky notes on your whiteboard. Just get a a ruler and a a black marker, draw some lines on it. And start throwing up your work there using sticky notes. Right, so this is uh anyone that's worked in DevOps, uh or software development. Uh some to some extent this is used uh in project management as well. Like you mentioned Trello, that interface is pretty popular. People recognize that. But it definitely is more reserved for the software dev side of the world. And the DevOps side of things. Uh, how did you really sort of make that first foray into the the work around uh it being in IT management? Was that a difficult step? Were there what were some of the hurdles that you may have experienced in adapting that work style towards the IT management side? Um, sort of the thought process is I started I realized we we've actually first thought of doing Scrum. Which is very typical in the software development world, doing like a two-week sprint, deciding on your work. And going for it, I don't think we ever tried it. We realized it wouldn't work because things are changing too much in the in the operations world. Changes are coming, there's last minute things every day that you have to deal with that Scrum doesn't handle very well. They don't want you to be changing your scope in a sprint. So I started researching what how are people using Scrum in IT operations and I found Kanban pretty quickly. And sort of looking at the pros and cons. And I realized it's basically removing the the time box requirement and it's more about minimizing your work in progress. So instead of each technician having 10 tickets in process, like how like how do we get that down to like one or two? Do a really good job, move on to the next one. And that's maybe one of the the parts that I see as, um, potentially difficult is is people, uh, tend to, uh, the text tend to have a lot of, uh, tickets queued up. And in the Kanban, the the lean strategy approach that you're, it's more a pull than a push. So the traditional approach is that we're just pushing, uh, into the text queue and they have to kind of clear the load as quickly as possible. Um, do you, uh, do you have any concerns or did you see any issues with moving to a pull strategy that it actually slowed down the work? That that, uh, instead of there just being this large queue to to dig through that you actually had to pull tickets into the queue and did that slow things down or or create inefficiency at all? Um, not that that that itself wasn't an issue. Um, we've been, we're still working through that transition from a push to a pull, to be honest. Um, we're still stuck in some of the traditional ways of having your Connectwise statuses mapped out on your service boards. Um, actually on the way back from IT Nation, the week before last, I just started fleshing out how to actually do it, uh, completely pull-based. And and baking in like the proactive steps into it. Um, I should we should maybe do a screen share sometime and go through that once I've implemented more of that. Um, but being of pulling the work through, even triage pulls it into their queue and they put it into a waiting spot and then somebody, let's say dispatch, will grab it from that waiting spot and pull it into their process rather than pushing it to the next person. Um, so we're still, like I've, the the Connectwise defaults are very push-oriented. And that's just what's gets ingrained into you after 10 years, so it's hard to shed that. Um, so it's, you have to work through that thinking as well as how do we be very explicit on your flow. Uh, so the status we've had it, the statuses we've had until recently are, uh, a more, here's a backlog, that we call it queued. Then it goes to a ready, which is sort of this week, next week kind of thing, prioritized, and then it goes into in progress. Uh, we need to, it's kind of vague to everybody as to what should be in which status. So that's something we're working on right now is to get crystal clear on when you move between the statuses. Um, and what they're used for. So I think we'll actually end up with more statuses when we're done. Hmm, interesting. Okay. Yeah, I I find, uh, statuses in in most of the implementations that I see are pretty dirty, people have a very loose sense of what they're actually for in most cases. So one of the the the advantages that I see to any type of process change or process improvement is that it really forces you to kind of review what exists and make adjustments or make changes. To either to adapt to that model or just really to to shed some of the the weight and the legacy information that you have in that system and be intentional about what you're actually trying to set up. Yeah. Yeah. So we we sat down a month ago, we mapped out our current flows between all those statuses. And it's basically a a spider web, everything goes to everything. So I think by redesigning that flow, it should be more linear from from left to right. Um, and then combining with visualizing it, we can see what needs more attention. So if we're doing let's say a completed ticket review or the the technician says, hey, I'm done with this. Then what's next? Let's visualize that as well. Yeah, and you bring up one of the the powers that I see in in a Kanban approach is the visualization of the work. Uh, and that's something that you've found in your team was really helpful. Um, from the DevOps, uh, you guys are using, um, uh, the lean strategies in in other parts of your businesses and running huddles. And I see this tool being really helpful as a visual representation of what the work is, where the work exists and what needs to be actioned. Is that an area that you saw a lot of advantages as well? Yes. Yeah, for sure. That's our huddles have been very powerful like the last six months or so is, um, being able to have. Let's say, a team of 10 people in a huddle in under 10 minutes going through all your work and seeing what's blocking or hindering the flow of value through that system. That's a big part of lean thinking is looking at what is value and what is waste. Eliminate the waste and make sure you don't accidentally categorize real value under waste and improving the flow of value to the client as soon as possible. Um. So that's something I think right now our huddles, we're focusing on what is every individual person doing. Uh, I think in the next little bit here as part of changing the statuses, we'll focus more on what is that business process doing. Looking at the there's like four or five main types of work in an MSP. So there's proactive maintenance, there's responding to unplanned work such as, uh, an a notification from your RMM or your backup solution about some some issue. Then there's project work and like internal improvements. How do we visualize all of that, um, and be very discrete or very, um, very explicit on that flow of work. So I think we, what I was saying a year ago and telling everybody and preaching was you need to standardize your statuses across all your boards to make Kanban easier. I think I'm, we're going to have to do 180 on that thought and it's more about being very custom on each type of work. Um, it's not so much about the technology or the individual people, but looking at that type of work. Um, so an account management process, how it flows through the system is very different than a change request on in your help desk. Right. And one of the the parts that I saw that I appreciate in in this this system is that, uh, unlike a lot of other systems where it's maybe just pulling information, you have a bidirectional interface with, uh, Connectwise manage. So you can actually do status updates, if you're dragging things around on the board, it actually updates the statuses. And if you change, um, uh, you can add ticket info and I believe time to the tickets directly from the interface. Is that right? Yes, that's right. So, um, stepping back a little, we you set up your own boards, a Kanban board, which is basically call like a layer or a view on top of your Connectwise data. To define what your columns are, so you can have map one or more of your Connectwise statuses into that column. So if you had four waiting statuses in Connectwise, you might just show it as one column in Kanban, it's it's up to you. And then you set up optional swim lanes. So it could be swim lane by resource, Connectwise board, by team and so forth. And then so you save that, apply your filters, then when you look at the board, you can drag and drop between columns to update that status. That'll immediately update Connectwise. And then all your regular workflow and templates and all that will kick off from from Connectwise. Um. You can also now add or remove resources on cards, we just released that today actually. We're excited to see that, we've been working on that for a while. Um, that way our goal is that in the huddle, you can make the changes required to update your workflow. So that we're not, we don't want to rebuild Connectwise, but be able to do the light editing on tickets. So change the status, change the resources, add some notes, that kind of thing. Right. And not not be managing data in two places. I've literally I've gotten screenshots of people managing their whole dispatch process in Trello. It looks nice because it's visual, but they've got somebody working spending a lot of time every day keeping their tickets up to date in both directions. Yeah, multiple silos of information is absolutely not a way to to get efficiency in your business. I agree. So it it raises a good point. Um, how do you see the division of work then? So, uh, primarily, you know, you want people working out of Connectwise, uh, kind of address the fact that your solution integrates with that data, so it's not redundant and you're not managing statuses and data in two places. What do you see as sort of the the the how people would work in one system or the other? Can they completely remove themselves Connectwise for a large part and just work out of the Kanban board or if is there a particular portion of the work that's better suited for in the Kanban than out? Um, right now the split is sort of deciding what to do next and prioritization would be more in Kanban. But actually entering time, updating agreements, looking at all the tasks on a ticket, managing those nitty-gritty details is better done in Connectwise. So throughout the day, you're going to have both open, you need Connectwise open to manage your time sheet and your expenses and looking at all the CRM details, all of that. And you'll have Kanban in a tab somewhere on a browser to keep an eye on it. And then the other use case is having it running on, let's say, large LCD screens around your office, unique to each team. Uh, so like you might have Brightgauge running on screens, you might have a Kanban board next to it on another screen or maybe cycle through it, right? Okay. And then thirdly, in your huddles, have one that you can actually interact with, so we have one in our huddle area and we have like a Bluetooth keyboard and mouse. So we can go and make changes and scroll around and and pick different boards and and views and such. Right, so it's more of like a a strategy or a management layer that sits over top. You can interact with it for simplicity's sake, but it it's not it's not where you actually work and manage the tickets. It's more an overlayer. That's correct. Yeah. And that may evolve over time, like we're we've I've gotten requests from MSPs that like we don't want to be working in both. Uh, we'd like to be able to enter time and add notes and do more things. Um, again, that that's sort of the slippery slope of how far do you go with it. Yeah, definitely. And one area we haven't touched on, but uh, you you've received a lot of positive feedback on is is actually managing the sales and support funnel. Uh, and managing opportunities from the Kanban. Um, you want to touch on that as well? Yeah, this is a huge, huge area. Is the, um, Connectwise has a lot of functionality in the sales area. There's like, um, see your opportunities, your activities. There's the there's like funnels, there's dashboards, there's reports. But it's not clear as to know like what are my priorities for this week for opportunities? What quote do I have to get out, what meeting do I have to book? Um. So in the there's there is like a my opportunities screen, so you can see all your open opportunities, you can create some views. But it's not standardized across your team. So even whether you're by yourself or or with your with a team, it's hard to know what's going on. And it's a lot of companies struggle to get, uh, the right statuses set up. There's a lot of coaching and best practices, um, companies working with consultants like yourself to flesh that out in this service area. But I haven't seen much in like the university, just good leadership on how to manage your sales opportunities. And it's kind of inspired by some other products like Pipedrive and other CRMs that are a lot more visual. There's active campaign, they're very simple, drag and drop. There's a whole trend nowadays to like simple CRMs where you don't need days of training, you just start using it. Just people have gotten fed up with Salesforce and NetSuite and all the big guys. And they're going to very single like simple or single page CRMs and dashboards. Um. So I said the Kanban concept can be applied to any type of work, whether it's factory floor. It's education, it's it can be applied to sales management, any any sort of thing. Even like cleaning your garage, you could map that work out on a Kanban board. Your personal work. Uh, so we've created an integration to the Connectwise opportunities to visualize that. Um, so we've got to set up with, uh, a a swim lane by opportunity type. So like recurring revenue, non-recurring, new clients, and renewals as well we have. So we can map out that flow through all the stages of the cycle from like new, needs analysis. Quoting, presented, completed, or follow-up. Um, you can really see the the progress of them through the funnel as well as try to minimize that. Having to do 10 quotes this week for one person, that could be too much. But hey, what are the, what can we really do well this week and close this week? Um, so not have 100 in progress in play, but how do we, like what are the five top activities this week? And that's more of a discussion than having lots of filters and fields. So Connectwise has way too many fields on the opportunities. Uh. So there's you got the probability, you got the stage, there's the status, there's the type, there's the the rep, inside rep, there's the business unit. It's, it's too much. Yeah, and I agree, I think that's often the biggest resistance to that information being completed is that it is overwhelming and and people just kind of look at it like, okay, I've to update these 20 fields. Um, versus just a right click on a on a card, maybe make a quick, uh, update on some details and then drag it to the next, uh, location. Um, I I think in so many cases, you're better off to start with really the high value data points and understanding where those, uh, those, uh, opportunities sit, uh, in the funnel is far more important than a lot of the minutia and the details. And if you can get that information later, that's great, but at least having that that visualization of that board to understand. Okay, we've got four opportunities sitting in this state, we've got 12 sitting in this status and we've got two hot ones that we really need to manage this week. Uh, just to get the team to rally around that board and understand what needs to be actioned right away would be really powerful. I I often see in sales management meetings where they really struggle to navigate the Connectwise interface in some usable fashion to get everyone rallied around the data. I've done some work in Brightgauge to try again to try and visualize that in a different way, but I I think the the card view is really powerful just in its simplicity. Yeah. Yeah, that will help people keep people or teams working within Connectwise instead of going to Excel or Wiki or Notepad to manage opportunities and what's next. Um. So the Kanban boards actually represent what's going on. What I've seen with this is that having the discussion on how you want to show your Kanban board that's standardized across your team, that the team decides this is how we're going to represent what's going on. It forces actually companies to use Connectwise properly. Because you you garbage in, garbage out. You can't visualize data that's in the wrong status, in the wrong types and all of that. Yeah, so much of this, I agree, is is the the opportunity is in getting the team's input, uh, so that there's there's buy-in and there's a collective understanding about why we do things a certain way and everyone agrees to that. You'll you'll see a huge uptake in accountability towards a process if people have feel like they've had a hand in building it. And, you know, back to the to the the previous point that, uh, so much of improving process is just looking at it. If you've if you've visualize or try to change something, uh, then having this opportunity to review it forces you to sort of say, well, this doesn't make any sense. Everyone kind of agrees and they they decide to change it in some way. Uh, that that opportunity to review your process in an object an objective way is can be really, really powerful for teams. Yeah. Yeah. So, uh, right now you're you're really just focusing on on the Connectwise, uh, end of things. But, uh, I imagine you have some big hopes and dreams around, um, the the lean methodology. Do you have any any future vision either for this product set or additional product sets that you think might be more powerful ways to bring the lean methodology into the IT DevOps space or the manage space? Um. There's some thoughts like do we get into Autotask and other products down the line? Uh, right now, I feel like for the next year or two, there's so much we could do just in the Connectwise world to, um, go into that a lot deeper. Um, we're I mentioned the Phoenix Project book earlier, uh, I think in previous conversation. And that's a key part for us. I actually give a copy of that book to all of our clients and it's required reading for everybody in my team. So the Phoenix Project is a book, um, written, came out, I think about five years ago. It's a novel about IT and DevOps and Kanban. It's, uh, look it up on Amazon, the main author is Jean Kim and a couple others. Uh. I really inspired by the book. So I discovered it about last fall around this time, talking with a couple of other MSPs. I heard about like two weeks in a row. I'm like, okay, I got to buy this book. So I bought it and read it that weekend and also listened to an audio book. I think there's a lot more we can implement from that, visualizing the workflow and just fostering it's not so much about the tool. Like realistically, you can implement get a lot of these benefits without having the tool, just do it in Connectwise, um, but it's fostering those conversations within the team, sort of grassroots, ground up. Instead of us making assumptions as management, as leadership. So I think there's more we can do there aligning technology and business, helping our clients. There's a lot of coaching we could do, um, implementing the rest of those learnings from the Phoenix Project book. So that book was based on the goal, which is a book from a fellow called Elihu Goldratt. He wrote this book 30 years ago in the manufacturing world. That's a very popular common book in in that space, project management, manufacturing workflow. How do you optimize flow of work with machines on the shop floor, let's say in a car manufacturing or parts manufacturing. So that was an inspiration for this book. Um, so there's more we can do there and that's that was in the days of paper and typewriters. And they implemented these things. Uh, so I see there's opportunities where we can implement more of that and get more into helping our clients realize the benefits of lean. Uh. Really looking at what are your real bottlenecks, is it a tool, is it a client, is it a process, is it a person? And aligning that. Yeah, I think that's a really important point. Um, I I see this a lot in project management, uh, but it it applies to everywhere else. Especially in in technical fields where people get so hung up on the tool that they lose sight of what the tool is actually supposed to do, which is produce a process. The process is so much more important. I think that's that's why we hit on a few times that using a tool like this and having an objective view of your processes is is incredibly powerful. Just to to force you to flatten some things out, make them a little simpler or adapt them in a fashion that that it becomes more productive for everybody. So, uh, we kind of noted at the beginning that there's a a continued, uh, crossover between the DevOps world and the the traditional Sis admin world. And I don't see any sign of that slowing down. I think it'll the pace will increase over time. You said it at kind of an interesting cross section in that you're, uh, an IT managed service company as well as a DevOps shop. And so you're kind of at the at the the nexus of this. And but I think that your position will become a lot more common in the future where there is this bleed over between the two worlds. So the better, uh, adapted companies will be to what that future looks like, will set them up for better success. Yep. We definitely get into a lot of that again in the Linux DevOps side of what we do, working with our clients that are development teams. It's all about continuous deployment, continuous delivery of like just small updates every day. So, um, micro updates in your process, in your product. You're not delivering major functionality every six months, it's like every day. Um, so that's the same for our workflow and how we work, it's it's not a, okay, it's December, we got to plan out next year. But it's looking at what small improvement can we make today and tomorrow, it's like what small improvement can we make today. And just looking and listening, knowing that the the people at the bottom of your organization. I guess bottoms, I don't like that word. Because they're they're the front line of your organization talking to your clients. They see the real issues. So it's like listening to them and not not shutting that down, but keeping that door open and just listening and making sure they're, um, willing. And to bring up ideas and what are inconsistencies in your process. It's like on the shop floor, the guys that know how to that are actually swinging the hammer or using the drills, they know what to improve. Just listening and not, um, shutting that down. So that's been powerful for me, it's just more of a personal development. As they say something and it doesn't align with what I've read in the book. Which like, okay, they they know better. Even though I've read the book, they know better because they're actually doing the job. So it's sometimes it takes a while to think through that, how can we implement it and improve our process. But that's that's where the power is, it's just listening and working together. Yeah, 100%. 1% a day improvement becomes a powerful momentum after a long time, right? Yeah. Yeah. Excellent. Well, uh, appreciate your time today, Wim. Any, well, we'll link to, uh, some videos so people can visualize the the the Kanban process and, uh, get some some links for for the books you recommended as well. Uh, any other, um, uh, calls to action or or words of wisdom before we, uh, sign out? I think we've covered pretty much everything. I can definitely get you the links to the books over and the videos. I'm happy to do a demo and screen share or a trial for anyone who's interested and get your feedback. So, look forward to. And where should they link to you on, uh, on the website or in social? What's the best channel to to reach out to you? Uh, we just relaunched the website before IT Nation, so that's, uh, www.cwkanban.com. It's got a link to a lot of resources, the blog posts and videos there. And you can also find me on LinkedIn, of course. Um, we've got Twitter going now. Um, so those are the main spots. Excellent. Well, all the best, Wim, be, uh, interesting to see how, uh, lean continues to impact the Sis admin side of the world. And, uh, and change things for for the better. So, all the best to you. All right. Thank you, Todd.