Main

How to Supercharge your Agile Board (aka Kanban Board aka Scrum Board)

I'm sharing EVERYTHING I know about Agile Boards... in the hope that YOU will share with me. I look forward to talking to you in the comments. πŸ‘ = = = = = = = = = = = = New for 2024: my best-ever training: "How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout" β†’ https://www.developmentthatpays.com/webinars/p-and-p?ref=yt = = = = = = = = = = = = Notes: - There's a mistake at 14:24 - the title should say "Driving a Wedge?" - Please don't leave without leaving a comment - I want your tips and tricks! 00:00 Intro 01:12 To Do, Doing, Done 2:50 Triggering 4:49 Release me 6:50 Ageism 7:36 WIP Limits 9:43 More columns 14:27 Driving a wedge? 19:53 Blocked items 22:30 Swim Lanes 24:10 Not fair! ------------------- 160. How to Supercharge your Agile Board (aka Kanban Board aka Scrum Board) #agile #scrum #kanban #DevelopmentThatPays Kanban boards, Agile boards Scrum boards - whatever you call them we're going deep on them I'm talking column naming process columns buffer colums Swim Lanes blocked items WIP limits card aging everything from the basics to some rather nifty tips and tricks Welcome back to the shed at the bottom of the garden where we are for the very first time attempting a fancy 2 camera setup. And no: what's coming is not a rant about physical boards versus Agile boards. Most of what I'm going to be talking about today can be done on both but I will be highlighting things that can only be done on a physical board and one or two things that can only be done on an electronic board That said what are we looking at here well we're looking at a Kanban board that's probably the most correct word for it name for it Agile board I think is probably become quite common Scrum board as as well often used by Scrum teams surprising that whatever you call it I would recommend it for any Agile team regardless of framework or methodology. Three columns - not three Swim Lanes by the way: I'll say more about Swim Lanes later. Three columns To Do Doing and Done. This is the only column where work gets done - you could call that an active column I call it a process column. I'm not even sure that's the right term if you know of if you know of the correct or better term please let me know in the comments The board of course is for tracking work the very first board I had any dealings with was was one very much like this it was using a whiteboard with drawn on columns and index cards to track individual backlog items across the board aided and a beted of course by a Blog of BluTak other brands available the second board I had dealings with was printed on a big sheet of paper with columns just wide enough for a single PostIt and this is how the board might look for a Scrum team if this was right at the beginning of the Sprint the items here are essentially the Sprint Backlog That's of course not the case for Kanban more on that in a moment when an item is picked up it's moved into this column to indicate that it's now being actively worked on and it's at that point and know earlier that this item should be assigned to a person as time goes on items get pulled in from to-do and eventually items may get all the way across to the done column and by the time if this is again if this is still the Scrum team by the time we get into the middle of the Sprint that the board looks pretty much as it would for a Kanban team Going back to the to-do column as I said Scrum teams have a Sprint they have Sprint planning they have a way of generating work for this column. In Kanban things are a little different in Kanban the the work pretty much drives everything and we can enable that with another line on this [Music] board this in Kanban is called called a trigger point. It's very much like a reorder point that supermarkets and such like will use to let them know that they're running short on a particular item and that they should go on and order more stock and that's exactly how it works on the board in this position there were three items still left in to do well nothing to do at the moment but when this item gets picked up and now these two items move move up above this trigger point that's the time to call a meeting and and typically it takes a while to get the meeting together to run the meeting to the result of which will be more items for the to-do column and the idea being is that if this is the state when the meeting is called there's enough work to carry on with if it takes say a day or perhaps ABS two days to get that meeting organized so maybe this one gets picked up in the meantime this one gets Al also gets picked up and then finally the result of that pl https://www.youtube.com/watch?v=O0BnP45op0E&list=PLngnoZX8cAn9ybPBWdlydv7AaqdifaE27

Development That Pays

2 weeks ago

canb band boards agile boards scrum boards whatever you call them we're going deep on them I'm talking column naming process columns buffer colums swim lanes blocked items whip limits card aging everything from the basics to some rather Nifty tips and tricks welcome back to the shed at the bottom of the garden where we are for the very first time attempting a fancy 2 camera setup I know what's coming is not a rant about physical boards versus agile boards most of what I'm going to be talking abo
ut today can be done on both but I will be highlighting things that can only be done on a physical board and one or two things that can only be done on an elect on an electronic board with that said what are we looking at here well we're looking at a can ban board that's probably the most correct um word for it name for it agile board I think is probably become quite common scrum board as as well often used by scrum teams surprising that whatever you call it I would recommend it for any agile te
am regardless of framework or methodology three columns not three swim Lanes by the way I'll say more about SW swim Lanes later three columns to do doing and done this is the only column where work gets done uh you could call that an active column I call it a process column I'm not even sure that's the right term if you know of if you know of the correct or better term please let me know in the comments the board of course is for tracking work the very first board I had any dealings with uh was
was one very much like this it was using a whiteboard with drawn on columns and uh index cards to track individual backlog items across the board aided and a beted of course by a Blog of Blac other brands available the second board I had dealings with was printed on a big sheet of paper with columns just wide enough for a single posted and this is how the board might look for a scrum team if this was right at the beginning of the Sprint the items here into do are essentially the Sprint backlog t
hat's of course not the case for Canan more on that in a moment when an item is picked up it's moved into this column to indicate that it's now being actively worked on and it's at that point and know earlier that this item should be assigned to a person as time goes on items get pulled in from to-do and eventually items may get all the way across to the done column and by the time if this is again if this is still the scrum team by the time we get into the middle of the Sprint that the board lo
oks pretty much as it would for a can ban team going back to the to-do column as I said scrum teams have a Sprint they have Sprint planning they have a way of generating work for this column in Canan things are a little different in Canan the the work pretty much drives everything and we can enable that with another line on this [Music] board this in Canan is called called a trigger point it's very much like a reorder point that supermarkets and such like will use to let them know that they're r
unning short on a particular item and that they should go on and order more stock and that's exactly how it works on the board in this position there were three items still left in to do well nothing to do at the moment but when this item gets picked up and now these two items move move up above this trigger point that's the time to call a meeting and and typically it takes a while to get the meeting together to run the meeting um to the result of which will be more items for the to-do column an
d the idea being is that if this is the state when the meeting is called there's enough work to carry on with if it takes say a day or perhaps ABS two days to get that meeting organized so maybe this one gets picked up in the meantime this one gets Al also gets picked up and then finally the result of that planning meeting uh would be some extra work that would hopefully fill up this column again trigger point in these days of continuous integration has been a long time since I packaged multiple
items into a release but back in the old days when when I used a board like this this was a nice little trick to create a like to use an index card to represent a release and to use it to gather together items that would be part of that release um making it easy for the person whose job it was to to handle the release to pick up this index card check that everything was okay with all of the items that were part of that release and package it up and send it on its way we've got our board and we'
re able to track work across it but the board can do a lot more for us than that and I've cleaned most of the work off the board just to make the point that if we can take items from to-do get them into doing and get them over to done if we can do that in the shortest possible time well you can't really get any better than this that's what in Canan is called single piece flow and it's kind of what we're always trying to get to in the real world though we often end up in a situation that's very d
ifferent than that with a doing column that just gets longer and oops and longer and longer and it's easy to see how this can happen we are after all doing agile we're solving difficult problems chances are from time to time we're going to get stucked out items are going to get blocked and what we what we tend to do is reach for another card that's why the doing column left unchecked can continue to grow and grow and that's a problem because we end up with a situation where things hang around a
long time in the doing column the very opposite of the single piece flow that I described before and here's one thing that I can't easily represent on this physical board but some electronic boards can do do and that is to indicate the age of cards it was actually the reason I upgraded to a paid Trello subscription was to have this kind of visual uh aging where the cards kind of Fade Away over time and card age is actually a pretty powerful parameter we're going to get into work in progress limi
t in a second but you're going to essentially extrapolate all of Canan from this idea of minimizing in the age of all of the work items powerful powerful stuff let's move on red pen at the ready let's go ahead and impose a whip limit and because I've got a physical board and my column is just one Post-it wide I can do this rather night Nifty trick putting a horizontal line to indicate that work in progress limit whip limit for short four cards being the maximum that is allowed for another electr
onic board it's more typical that the number is written at the top of the column somewhere and a breach of that whd limit reach of that whip limit it's quite hard to say is typically indicated by turning the entire column red now if you're using an electronic board but it doesn't support work in progress limits I have a little bit of a hack for you let's say uh just to fit on my board that this is the work in progress limit just three items a of indicating that work in progress limit and remembe
r I did say this was kind of hacky is to create a dummy card ideally change its color and it gets positioned at the bottom of the the list here the idea being that if another card is picked up it ends up here and it's visually obvious that the whip limit has been breached now the problem of course is when this card is mov moved then these all Ripple up and it's a manual operation then to reposition this one in the fourth position in this column as for coming up with a number for that work in pro
gress limit my rule of thumb is to take the number of people doing the doing and multiply it by somewhere between one and a half and two maybe start at twice the number of people and over time attempt to reduce that number down remember the board I mentioned earlier the one printed on a big sheet of paper well the first thing I noticed about it was that it was made of paper the second thing I noticed about it is that it had many many columns many more than the three columns you see here before y
ou so yeah let's talk about adding more columns into the mix so I've redrawn the board it's starts with Todo ends with done but in place of doing I now have three active three process columns we'll talk about what they are in just a moment but the big question is do we need extra columns and how do we know if we need one two or three and the way to determine that is to figure out if and how often work changes hands so if work goes from too and is picked up by this guy and this guy takes it all t
he way to done then one column is enough if and if that's how all of the team operate everyone picks up their own ticket and sticks with it all the way to the end one column is enough the the board that we were just looking at before the doing column in the middle perfect however oops that person shouldn't have been I early assigned someone there shouldn't shouldn't be assigned at this point if however this person picks up the ticket assigns himself or herself to it and then passes on to someone
else then it looks like we need two columns and I I'm sure you can see where this is going if this person then passes on to another person Bend three columns is the right number so let's fill in a possible set of three processes for this particular team I hope I'm not going to upset anyone by having test as a as a separate process I know there's a little bit of a problem with with that in agile I'm using it as an example possibly because it's actually quite common to find teams with a with a te
st function um if you have concerns about that I hope I will lay some of them in a second going to say that this process is Dev and the first one is design three processes three columns going to move this one back here and put these guys at the top of their um processors actually let's let's give Dev a helping hand three quick points before we move on first of all what I've drawn here as a little bit unfair we'll be fixing the fairness factor in just a moment secondly I hope you got the message
when I talked about um handing work passing work it's almost like passing the bat on from one person to another across the board that I hope you can see is is very team specific in a company with multiple teams it's unlikely they're going to be having the same structure of work um or workflow across all of their teams and yet what I see too often is companies that have standardized their agile boards again probably using jir or similar giving everyone the same structure even though it probably d
oesn't match the team so keep a team my advice here would be to keep a team specific two team sitting right beside one another one might have three columns here one might be happy with just a single column should be team specific final thing to say and then we'll move on when naming these columns I've tried all kinds of um naming strategies the one that works the best is to use the imperative voice the imperative because I do sound like something of a of a grammar ner here and I kind of am the i
mperative is the is the thing that you use when you're giving instructions like jump Run Stop go that kind of word so design it's like a command develop it's like a command test like a command works works well in pretty much every situation I've come across and tends to be shorter tser easier to write on a board like this than options such as designing developing testing or even something like in progress design Dev test keep it imperative we have a board now that accurately reflects the way thi
s team works it reflects its workflow design into Dev into test now concern you may be having and it's certainly one that a colleague of mine had back in the day the first time we went for a multicolumn board like this and his concern was doesn't this drive a wedge between the individual functions between Dev and test between design and Dev and uh yeah I mean that kind of makes sense what I hope I'm going to show you that actually the opposite may be true that it might help the various parts of
the team to work more closely together we'll get to that in a moment what is a valid concern is to do with working progress I hope you can see that even if we restricted every column to just one item they'd still be three times as work three times as much work potentially in progress than we had in our single column setup so yes we have paid a price in terms of work in progress when moving from a single process column to three process columns and we do it willingly because of some of the benefit
s that are crew as I hope again you will soon see and the first of those benefits come when we add back those work in progress limits going to go for here here here and here reflect them at the top for the electronic version let's go for two here four here and two here now an experiened team might be able to operate here with a minimum of work in progress but any real world team that I've ever dealt with certainly that have been a part of will sooner or later get to a point where where everythin
g is at its work in progress limits question for you looking at this board and the work in progress limits which of these cards can move well it's only these two here Dev is stuck it can neither move items into test nor pick up new work from design similarly design can't move into Dev nor can it pick up more work from to do so what's a poor developer to do well one thing they could do is nothing that's certainly better than magically introducing more work in progress into the system but what the
y really should do is walk over to test and ask if they can help out that's the positive thing to do and that's the response to aren't we driving a wedge no we're not those work in progress limits have actually led to Dev moving across to ask test if they can help out if anything this board and those work in progress limits have drawn different members of the team together powerful powerful stuff and uh just to see that things really do unblock once an item moves here then this one can move all
of these move up we can pull in another item here if we're ready and design also unblocked we can pull things in a quick word about card value in terms of value delivered to the customer none of these cards have delivered any none of them will until they make it to the done column and they get released that's when value is delivered having said that I think it's true to say that this card all other things being equal is potentially more important than all of the other cards here only because it'
s likely to be the first that gets entered on and then gets to deliver its value so as things go across the board it could be argued that things get more valuable and that's one reason that in Daily standup provided we're using the walk the wall process otherwise known as walk the board that's the reason why we start at the top it's one of the reasons why we start at the top right of the board in order to make sure that we talk about the most important items first so we started here move down th
is column over to Dev go all the way down this column into design if we run out of time if we exceed that time box 15 minutes and we don't get to these tickets it's not the end of the world we covered the most important ones there's also a really practical reason that we start at the top right if I again load this board up put everything at its work in progress limit as we saw before these are the only cards that can move if we start at the top during our daily standup we find this one can move
well we've opened things up if I started to move cards starting here things would have got messy very very quickly did I mention blocked items let's talk about them now several ways that we can indicate blocked items on a board the first way that I see a lot um which doesn't make me happy I don't think it's a very good method um but I can see why it's simple and it kind of works and that is to create a dedicated column for blocked items either just before done or just after to do yeah it kind of
works but there are better ways on a physical board and I wish I'd known this back in the day when I used a physical boards this is something that someone told me about much more recently is that if this card gets blocked pick it up put it down like that we now have a strong indication that this card is different so that's another way of doing it the electronic version of doing that is to tag the card in some way and I guess um ideally oops reaching for another postage this is the this is the b
locked item you get gets tagged ideally you change this color and again visual indication on the electronic board that this one is blocked um one other way of doing this which is the first way that I used um I don't like it as much as this I'll say that straight away have a row that was specifically for blocked items if this was the item that was blocked got moved into this row to indicate that it's blocked now there's a subtle but important difference between this approach moving it down here v
ersus turning on it on its Edge or tagging it with a yeah with a tag and that is what it strongly applies about work in progress if I leave it here if I move it on a diagonal or tag it it's still taking up work in progress It's still not possible for Dev to pull in some new work it's part of that oh I think we we said it was four but yeah it looks smaller than that just at the moment so I don't have a big enough Bo I'm really sorry about that however if we move it into this dedicated Row for blo
cked it looks well it's more than strongly suggested doesn't it the dev now just has two items in progress we've not only moved it into this role but we've removed it from the work in progress for that process column and my question to you is which is correct or at least which is more correct let me know in those comments right back at the beginning which is quite a long time ago now I mentioned swim Lanes I would argue that there are no swim Lanes here in the same way I think as in a swimming p
ool which I think is where the term comes from and before they put any ropes in I don't think we talk about there being just one swim Lane it's like they put the rope in and now there's one or two swim Lanes depending on how you look at it anyway let's add a swim Lane to this board I'm going to start by squishing everything up and kind of creating some space for it so here is our swim Lane probably doesn't need to run across done what that gives us is effectively another route across the board f
rom to do into time through to Dev test and done and there is a number of reasons that you might want to do this and several reasons why you wouldn't I've used it in the past when the team was trying to add more unit tests to the code base and we decided to track that separately from other work on the board the most common use for this is as a kind of an express route across the board for super urgent items I think this is sometimes called a silver bullet um swim Lane is that good for items in t
he silver ballet swim Lane yes it is is it good for the work on this board as a whole no it isn't this could take us into a discussion about curing Theory and I don't really know enough about that but yeah the message here is use them sparingly if at all when I added the extra columns I said there's a little bit of unfairness hiding here indeed there is and it's time for me to address it if I look at design design can pull items in from to do that is good but what about when design finishes work
what does it do with it well the only move available to it is for it to push push its work into Dev now if you know anything about Canan you know it's all about the pull and not the push this is really I've always thought this was really unfair that all of a sudden Deb's got another item another another item this contrib buting to its work in progress that it never asked for that's the unfairness we need to set things up that so the dev has the same rights and privileges as design design is abl
e to pull Dev should also be able to pull I guess a hack on a physical board like this would be maybe to put the card halfway across the two columns of course for an electronic board that's not going to work so let's do this properly we're going to have to add in a few more columns I've got a board to clean so I've introduced two new columns which I hope are going to sort out the fairness issue both of the columns I added are buffer columns let's just indicate that with a b um buffer column is a
column where no work gets done this is where work sits waiting to be picked up by the next stage so let's see if we really have solved the fairness problem so item into Todo design can pull from from that column that's fine that was always fine when design is finished it can move it into this buffer column that's a change of state that's not a push Dev now has has been given the right the privilege the privilege the design always has to pull work in when Dev is ready for it so that's a pull it
happens when Dev wants it and not a moment before and again Dev when this item is complete it moves it into this um buffer column where it waits until test is ready to pull it in in its turn and again test now has the same privileges as design and now Dev to be able to pull when it is ready the being as this sticker says we want to be pulling no pushing final step um test doesn't need its own buffer column because the done column that we've had right from the beginning serves the same purpose wh
en it comes to whip limits I guess I can add back the whip limits that we had before if I can remember them I think we had two there four there and two here and I guess we could do the same for these new buffer columns I might add um a one here and maybe two here but we can do better than that by using something called shared whip shared work in progress but to do that we need to figure out who owns these new columns who owns these buffer columns so is this column owned by Design or is it owned
by Dev and the answer of that kind of comes down to well it's a question of control when design has p p in as we said and that's fair and proper and when design is finished it needs a place to put it and it moves it over here all of that all of those actions were in Design's control everything that we did here pulling it in moving across to buffer is in designs control and it owns therefore owns both of those columns if Dev owned this column well design would have been messing with it and that's
not what we want that wouldn't have be fair so the way the column split up by the way you always end up with an odd number when you set up a thing like this is that there's a to-do column and then it goes pair pair develop owns this buffer column and test and I guess in a way done as a buffer column and it is owned by test now establish a work in progress limit that is shared across these two I believe it was two before when we only had design so let's make it three and here's where that flexib
ility comes in we could have three items here or two and one one and two or all three in that buffer column let's do a similar thing over here Dev was four before so maybe five or even six would work there and for the sake of completeness six items here 5 and one 4 and two three and three two and four one and five or all six in that buffer column test we haven't really changed so we just leave that unaltered establishing the ownership also helps us name these columns the long hand would be desig
n and design done Dev and Dev done one final wrinkle this kind of a conventional way of laying this out which removes repetition adds Clarity and emphasizes the pairing of columns and that's it everything I know and probably a few things I shouldn't about aile boards did I miss anything out did I get anything wrong do you have any top tips share them please do you know where them their comments below

Comments

@Developmentthatpays

Over to you: what did I get right? What did I get wrong? What could be better? What are your top tips and tricks? Let me know!

@PaulHenman

If you're going to have a swim lane for blocked items, then I'd recommend putting it at the top of each column because resolving the impediment is important; putting it at the bottom of the column can lead to the impediment being ignored.

@malcolmlisle543

A brilliant job as usual Gary. You covered all of the salient points. My favourite blocking method is to change the colour of the card but leave it where it is. This works really well with WIP limits because it still counts as WIP even when it is blocked so does not get forgotten about and can be focused on to get the block removed. One amendment I would suggest is don't use "Design Done" or "Development Done" there is only one Done. Use Design Complete and Development Complete that way you don't get the conversation around is it Done? Done Done? or Done Done Done? Reserve Done for it is Done as far as the Team is concerned and either in production or waiting to be released.

@scoogsy

Great video. As always, production is fantastic. So easy to follow. Lovely use of a physical board. Hard to change minds and implement, but clearly useful!

@YisraelDovL

Re: Blocked tasks. I think it is best to leave them in place so that they take up WIP limit unless we see that it will be blocked for a while for an external factor. What I like to do then, is to use a πŸ…Ώ column, from the great Kanban Project Managment Book from Eric B.

@leandrosebastian3203

Thanks for sharing such very powerful yet simple and visual content! I love watching and also learning from you.

@gobindachandrajena8009

Thanks for sharing such knowledge session πŸŽ‰ Doing column I can say it as cycle column alternatively ❀

@jacobtolman726

Adding this to my short list of required watching for any project manager or scrum owner.

@pawepokrywka7602

This video is sooo practical! I can apply the knowledge learned immediately in my project. Thank you :)

@mikependergrast9252

Used different views of the board which includes a swim lane for a sub-team or person. Gives the advantage of being able to see the work and in case of Scurm, allows the daily standup to focus on individuals work progress. Also fan of subtasks that allow work to parsed based on dev, des, test, etc.

@PaulHenman

The biggest benefit of a "buffer" column (e.g. "Ready to test") is that it can highlight delays (queues) but the WIP limit across Dev & Ready to Test should be the same as it was for Dev - adding a "buffer" column doesn't mean you can have more work on the board.

@rwj_dk

I would add Definition of Done (DoD) to the process. On physical board that is a post-it above column stating thing that need to be done before something can move to done.... On electronic boards these are sub-tasks/checklists on each card. To make it really work use the boards automations/API to automate the pro ess of applying DoD when stuff goes in progress

@PaulHenman

Card aging on a physical board can be done by simply adding a tally count on each card; I tend to increment the count just before the daily scrum

@gthomasindependent

Once again Gary, excellent presentation on board management! We actually do have a separate Test "column". With that, there should be more of a dotted line between dev and test as failed items often need additional dev work. With that said and to answer you question on blocked items, I prefer to move the blocked items down, below the WIP count, as a way to address failed tested work items - especially when the failed work item is the cause for blocking another item. I guess this is where the test as a column controversy starts. Where does a failed work item requiring dev belong? In the Test column where Dev resources have to move into that column (leaving dev without that resource) or back into the Dev column where the failed item has to be "pushed" backward. Or have I missed the idea completely? Thanks and Thanks for yet another great vid!

@michaelforni

Awesome job Gary in simplifying one of (possibly) most controversial topic across Kanban an Scrum! πŸ‘ I'd say that everything is spot on, from my view, with just 1 suggestion and 1 improvement tip for the audience. 1. In a simple 3 columns board, the "In Progress" middle column to me is not really a "process" column, but more a WIP column. This is the only column hosting Work that IS In Progress (hence "WIP limit" and not "Process limit" πŸ˜‰) 2. When a multi-column board is adopted, naming the penultimate column "Test" limits somehow its content, scope and who is "allowed" to work on those items. (yeah, it's mostly a psychological alibi 😜). Possible tweak By naming it "Review" or "Validate", it expands the possible content (it will include "Test" for sure, but not limited to). It could host actions like - "Documentation sign-off" (maybe with a clear external dependency on an Approver), - "UAT validation" (Product Owners or Business Analyst or even Scrum Masters can do it) - etc.. In short, using "Review" to name that final column before "Done", helps in breaking the silo ("it's not my role!") and improves cross-collaboration. Lastly, an observation to back you valid suggestion to be mindful, cautious with "Expedite lanes": besides the impact on the system as per Queuing Theory and such, it sets a very dangerous place where people from outside the team can force work in (PUSH!) creating an harmful "sub-optimization" on "very important tasks". Counterintuitively, this will impact the WHOLE SYSTEM, slowing down EVERY other single ticket (reducing Throughput and increasing Ticket Age and Cycle Time) which goes in the exact opposite direction of "Optimise of the Flow", that's the mantra of Kanban (with capital K πŸ˜‰) Once more Gary, I'm truly grateful πŸ™ for the effort you put in crafting these small masterpieces of pure gold knowledge, that no AI in the world, would ever be able to come up with! #IstayWithHumans #PullNotPush #OptimizeTheFlow #StopStartingStartFinishing #WeArePeopleNotResources

@pzeeman73

That mini-waterfall you introduced at 9:54 really hurt. And it influenced much of the rest of the video. It might be OK for a transitional step for a team trying to get more agile, but in a cross-functional team (even one that is cross-functional in spirit) it shouldn’t be necessary. I liked at 17:07 where the developers go help out the testers. I think this can apply from right to left as well, with tester helping developers if needed. A cross-functional team is a thing of beauty.

@trebusch

Re: "Silver bullet" or "Expedite" swimlane I would avoid such a swimlane (for all the arguments in the video plus the ones in the comments) except for just one situation: If there are work items that have to be completed quicker than the current cycle time of the team (e. g. an incident, an emergency change, ...). Then it is really wanted to give priority to the item in this swimlane over all the other items on the board (and even go beyond a WIP limit) and the swimlane is a proper visualisation of this.

@chrisjolly4085

Why adding a "design done" and "dev done" column and increase WIP? Only for the pull purpose? When there is no room Γ³r capacity to move or pick an item from design to dev, shouldn't the designers ask if the developers need help as stated earlier in the video? By implementing a "Done" column and increase the WIP, you only shift the problem a bit.