tag:blogger.com,1999:blog-9220389270062827818.post4057374193369785261..comments2024-03-24T13:07:36.760+00:00Comments on Design, Code, Release: Kanban for supportNathanhttp://www.blogger.com/profile/02284010981286464436noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-9220389270062827818.post-81119007819542553092015-10-12T20:12:09.515+01:002015-10-12T20:12:09.515+01:00Apologies for not responding before, I completely ...Apologies for not responding before, I completely lost track that you had replied.<br /><br />When I mentioned broadening the support process it was more around individuals skilling up on other products so that people on the team could swap between support items easily, giving you more resources to be able to work with. Doing this wouldn't require any change to the board as such more to the people handling the work to get their skills up on the products they don't work on.<br /><br />I would definitely suggest creating a virtual/online board for the data that is in Remedy and to try and make this as visible as possible. The difficulty with electronic tools is that they are often "out of sight, out of mind" and aren't used to full effect.<br /><br />I would only suggest having a physical board if you don't use the electronic system (which I would imagine would be very unlikely) even though a physical board is often better for visibility and people keeping it updated.Nathanhttps://www.blogger.com/profile/02284010981286464436noreply@blogger.comtag:blogger.com,1999:blog-9220389270062827818.post-47599348371172793232015-09-15T14:17:54.186+01:002015-09-15T14:17:54.186+01:00Hello Again,
Thank you very much for your prompt...Hello Again, <br /><br />Thank you very much for your prompt answer. It was very helpful. First, I will try to use horizontal "swim lanes" to divide the board on a per application basis. If it doesn't work, I will try to widen our support process (if you have any, can you please send some photos) <br /><br />Since I'm a beginner on this topic, everytime I try to shape the process, I figure out a new question :) I hope you can help again. <br /><br />We are using an incident management tool called "Remedy" and make our ticket assignments from there. In that respect, should we create a virtual/ online board so that maybe coordination with the incident management tool is easier (as you suggested on your article) or do you think that a physical board can be beneficial as well ?<br /><br />Best RegardsAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-9220389270062827818.post-70725799288754962942015-09-10T08:37:02.580+01:002015-09-10T08:37:02.580+01:00I'm going to answer your questions in reverse ...I'm going to answer your questions in reverse order, <br /><br />Assuming that you don't have hundreds of support tickets then yes you should add to the to-do list everytime that a new ticket is raised. If you have hundreds of tickets then I suspect you have a different problem to tackle.<br /><br />Ideally when these new tickets are added they should be prioritised by the business so that the team is always working on the most ticket with the most impact.<br /><br />With all the tickets prioritised by the business the support people can simply pick the highest priortity item to work on.<br /><br />Whilst having dedicated people to support specific apps I would humbly suggest that if you are able to allow anyone on the team to pick up any tickets you gain by the team as a whole being able to better handle peaks & troughs on any of the applications, with a bonus that your board stays the same.<br /><br />If you have to keep dedicated people per application then my best suggestion is to use horizontal "swim lanes" to divide the board on a per application basis so that all the items on the board for an app will live within that lane (to-do, WIP & done).<br /><br />Does that help?<br />Nathanhttps://www.blogger.com/profile/02284010981286464436noreply@blogger.comtag:blogger.com,1999:blog-9220389270062827818.post-45013445233375501272015-09-09T09:34:26.151+01:002015-09-09T09:34:26.151+01:00Hello,
We have a process where we are supporting...Hello, <br /><br />We have a process where we are supporting many applications and each application has a dedicated support person. For ex: When an issue arrives related to X application we assign it to X person, when an issue arrives reated to Y app, we assign it to Y person. So I could not figure out how I can shape the board in that process ? <br /><br />Also, wthin a day we have a continous flow of tickets coming. Should we add to the "to-do" list everytime new ticket arises ? <br /><br />Reading the explanations above were very clear but I had obstacles to fit it to the current processes. I would appreciate if you can give an advice. <br /><br />Thanks in advance. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9220389270062827818.post-57317921788752172152013-09-06T08:28:57.194+01:002013-09-06T08:28:57.194+01:00Hi Brett,
You won't be surprised that you are...Hi Brett,<br /><br />You won't be surprised that you aren't the first person to come across this situation and there are many different ways that this can be handled.<br /><br />First off you shouldn't use the critical lane, that lane should exist purely for things that are effectively stopping a live/prod system from working. If a card appears in this lane normally the whole team should swarm the problem to resolve it.<br /><br />Ideally the tester should come to the dev and they fix the issue together, this keeps the WIP limits satisfied and allows the work to be fixed.<br /><br />The board is supposed to show the flow of work though so if you are actually moving work say from a test team back to dev then as long as the team is happy to allow it there is no reason that shouldn't be reflected in the board.<br /><br />This is likely to break WIP so the team needs to agree what they are going to do, do you add a section at the bottom of dev specifically for these items? do you break the WIP and have the devs swarm to sort it out? its down to the team to agree how to handle it (perfect topic for a retrospective).<br /><br />For a bit more reading on this try:<br /> - <a href="http://nrg.im/17Uob9d" rel="nofollow">Should we move a failed story back</a><br /> - <a href="http://nrg.im/17Djizi" rel="nofollow">Never Move Items Back on a Kanban board</a><br /> - <a href="http://nrg.im/1dLFCuY" rel="nofollow">The Kanban Story: Moving Cards Back</a><br /><br />There are numerous approaches to this, ultimately its down to your team to decide how to handle it, just be aware that this happening should be a trigger to discover why it happened and how to avoid it in the future.<br /><br />Hope that helps <br />Nathanhttps://www.blogger.com/profile/02284010981286464436noreply@blogger.comtag:blogger.com,1999:blog-9220389270062827818.post-54682626136503150162013-08-29T04:19:54.479+01:002013-08-29T04:19:54.479+01:00How do you handle to flow of work which comes back...How do you handle to flow of work which comes back from test? How do you show it's flow back through the board/system? Do you use the critical lane? You can only have two pieces of work in progress so if a piece comes back, you now have three, what happens to the work you are in the middle of working on?<br /><br />Thank you,<br /><br />Brettbrettskihttps://www.blogger.com/profile/14771977258945734905noreply@blogger.comtag:blogger.com,1999:blog-9220389270062827818.post-15112977559289967752013-05-20T09:31:46.892+01:002013-05-20T09:31:46.892+01:00Using the Wayback machine I've corrected those...Using the Wayback machine I've corrected those links so you should be able to get at the articles nowNathanhttps://www.blogger.com/profile/02284010981286464436noreply@blogger.comtag:blogger.com,1999:blog-9220389270062827818.post-619552153877250122013-05-20T06:51:08.627+01:002013-05-20T06:51:08.627+01:00Thanks a lot for sharing. The links to "So wh...Thanks a lot for sharing. The links to "So who’s doing this?" was useful. Pls note that only link 2 and 4 launched for me.Anonymousnoreply@blogger.com