Maybe another video, what is missing for me is the rule to cross a column in Kanban. And I would have mentioned the DoD in scrum and the extension of it in Kanban to each Done sub-column that makes the pull system working.
@@bgn9000fr - Hi Philippe - I almost missed your comment. You're right: DoD! Or - in the case of kanban - multiple DoD's. (And yes, I'm planning a follow-up video and the DoD's will be featured.)
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.
Come to think of it, that's exactly what happened: the blocked items tended to be ignored. Good idea to move it (the looks-like-a-swimlane-but-isn't-one) to the top. 👍
Spot on Paul! 👌 Swimlanes (as @gary rightfully said) are risky, if not an impediment to the flow of the entire system. Putting them ON TOP of the respective column will "force" the team to talk about it during their walk on the board. Suggested question for the facilitator ".. and what's the plan to unlock them? What/who is needed?" 😉
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.
@@Developmentthatpays Which part? If before the buffer the team agrees the WIP limits are 2+4+2 then adding columns (without adding more people, i.e. capacity) shouldn't change your total WIP limit, should it?
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.
Excellent distinction --> "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" Love Eric Brechner. Might need to get that book!
I think the aim of kanban is managing the flow through a strategy. A blocked issue is something the team needs to work on and establish rules to avoid such issue to come back later. Then for me any blocked issue has to stay until it is not solved or remediate.
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.
You've brought us to the subject of "person-centric" vs. "work-centric". I see a lot of the former in Scrum teams, perhaps explained by the prevalence of "Yesterday, Today, Blockers". And I've seen a few teams that filter the board to display just the cards belonging to the person that's talking. That's HUGE missed opportunity, IMHO. I want _the team_ to be focusing on "our work", rather than _team members_ focusing on "my work". (Genuine) question on subtasks: do you track them across the board (do they appear as cards?) - or are they part of a Story card?
I was doing exactly the same thing with a small yellow sticker with a number on it,... "back in the old days" of physical boards and co-located teams #nostalgic😢
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
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!
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.
Agree with you 100% on blocked items. There's a related item that I'd love your option on: there are some comments along the lines of "blocked, pending action from a third party". If the block really is "outside of the team's control", perhaps there's an argument for moving the blocked card "outside of the WIP limit". What do you reckon? (I'm aware that creating two kinds of "blocked" will end up with liberties being taken!) One more thought on this: if "blocked-by-third" party is something that happens regularly ( _is part of the workflow_ ) then what's actually required is a new column (or column pair). Put another way, the item isn't blocked, it's just moved to a new process.
On the one-and-only "Done": a couple of people commented that I neglected to mention Definitions of Done (DoD) - note the plural. Think it's the kanban way to have a DoD for each process column. So "Design is complete when the DoD for Design has been satistfied", So "Dev is complete when the DoD for Dev has been satistfied", etc. How do you feel about multiple DoD's?
@@Developmentthatpays If the block really is "outside of the team's control" should it stay in the sprint? The problem with putting it in the Blocked column is that you do not go back to it because you are getting on with other things. Keeping it in place on the board means there is a regular, in your face reminder of a problem/Block that you need to get rid of either by fixing it or removing it from the sprint and dealing with it more appropriately. If Blocked by third party is part of the workflow, officially or unofficially, it is not blocked. That is like saying these items are blocked by the release team because they have to wait to the next quarterly release to go live. Something that is blocked should be able to be fixed or there is a much bigger problem that the development team has identified but should not get bogged down with. Blocking an item on the board is to highlight it to the team in case it may impact others, but also to highlight that help is needed to fix it. if it is going to take a while to fix think about removing it and getting on with things the team can do.
@@Developmentthatpays I have worked with teams where design was imbedded and Done meant released into production so there was only one DoD, but this is the ideal and most organisations do not have this capability. This is where different DoD can be useful. The problem I have with multiple DoD's is when they are within the development cycle. I only see impediment if there is a Dev DoD and a Test DoD etc. They are just additional hand offs, stage gates that impede progress, add bureaucracy and ultimately waste everyone's time.
@@malcolmlisle543 - [Re. blocked items] Sooooo much good stuff here - especially the bit that hadn't occurred to me: throwing the blocked item out of the Sprint.
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
Thanks, Michael - Great stuff as always! - On point 1: I'd never though about it that way before: that the (single) column *_is_* the "in progress"! - On point 2: What a difference a word can make! As you say, there's a WORLD of difference between "Test" and "Review" (or "Validate"). Huge! - On Expedite: Excellent points one and all! (I may have to do a video on that!)
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.
Can't believe you used the "W" word !!! My mental model here is not "Dev --> Test" (which has... _challenges_ ) but "Design --> Dev". It comes from this video vimeo.com/88885445#t=28m18s featuring Corey Ladas. It starts at 28:18; at 30:15 he asks "Why would we make the split?"; a bit later he talks about why we might UNDO the split. --- You're completely right about testers helping developers if needed. (Annoyed with myself for not mentioning that in the video.)
@@Developmentthatpays OK. I see Cory’s idea there. I think in my experience, the work he puts in “Specify” has already been done in refinement and planning before it even gets to the To Do column of a sprint board. Now I’m thinking about it in a Scrumban context (I was inspired by your Scrumban videos to introduce it to my teams with great success, and used them to sell the idea to the team, so thank you!). I like to propose to the team that (digital) boards use the user story/PBI/thing-of-value as swim lanes. Sub-tasks under those stories are the cards that flow from left to right. In this scenario, ‘specify’ might be a time boxed subtask to come up an approach that populates more subtasks for the user story to get to done. And of course at any time more subtasks can be added or removed as more is understood. The Test column is removed and testing work becomes subtasks that flow through the same three columns as ‘specify’ and ‘code’. And the team always pulls, never binds early and respects the WIP limits.
Excellent --> "And the team always pulls, never binds early and respects the WIP limits." Re: "Story/PBI/thing-of-value as swim lanes". This is an area I've been giving a lot of thought to recently (around what actually gets tracked across the board). Might make a good subject for another video.
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!
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.
You've reminded me of something we had on the first board I ever saw: I big laminated "STOP" sign. When we had an outage, the sign was stuck right in the middle of the board - to indicate that "we've got an emergency and we'll get back to the Agile stuff when it's resolved". (Better, I think, than an expedite column that "invites" emergencies.)
Like in ANY Hospital, the Triage helps in "maximising the flow" of patients based on severity, urgency and time of arrival. But when a huge car crash happens and some life-endangered people arrive, there is no "Expedite swimlane", but something more like Gary's STOP signal on anything in ToDo (100% will wsit), on most of stuff In Progress with lower priority (75%?) but NEVER on something that's Urgent, Emergent and almost Done, and that can be finished to make space to the new Top Emergency. You don't kill a patient to save another one (unless it's WAR). The only risk is that the "exception" once per month becomes the "norm" every week, because someone is screaming loud! 😮
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.
I got this a bit wrong in the video. I _added_ the WIP for the "Done"... and I should have _taken it back_ when I introduced shared WIP. (See comments from @paulhenman above.)
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!_*
Maybe another video, what is missing for me is the rule to cross a column in Kanban. And I would have mentioned the DoD in scrum and the extension of it in Kanban to each Done sub-column that makes the pull system working.
@@bgn9000fr - Hi Philippe - I almost missed your comment. You're right: DoD! Or - in the case of kanban - multiple DoD's.
(And yes, I'm planning a follow-up video and the DoD's will be featured.)
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.
Come to think of it, that's exactly what happened: the blocked items tended to be ignored. Good idea to move it (the looks-like-a-swimlane-but-isn't-one) to the top. 👍
Spot on Paul! 👌
Swimlanes (as @gary rightfully said) are risky, if not an impediment to the flow of the entire system.
Putting them ON TOP of the respective column will "force" the team to talk about it during their walk on the board.
Suggested question for the facilitator ".. and what's the plan to unlock them? What/who is needed?" 😉
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.
Wow... that's a strict standard!
@@Developmentthatpays Which part? If before the buffer the team agrees the WIP limits are 2+4+2 then adding columns (without adding more people, i.e. capacity) shouldn't change your total WIP limit, should it?
@@PaulHenman - I confess that I'm looking for a flaw in the logic... without success!
@@Developmentthatpays 😂
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.
Excellent distinction --> "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"
Love Eric Brechner. Might need to get that book!
It is an excellent book, only thing put out by Microsoft that I can say that I don't regret purchasing 😜@@Developmentthatpays
What is the difference between the 🅿 column and a blocked column ?
I think the aim of kanban is managing the flow through a strategy. A blocked issue is something the team needs to work on and establish rules to avoid such issue to come back later. Then for me any blocked issue has to stay until it is not solved or remediate.
Thanks for sharing such very powerful yet simple and visual content! I love watching and also learning from you.
Thank you for your kind words. Much appreciated.
Same same 🤗
This video is sooo practical! I can apply the knowledge learned immediately in my project. Thank you :)
Thank you for making my day!
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.
You've brought us to the subject of "person-centric" vs. "work-centric". I see a lot of the former in Scrum teams, perhaps explained by the prevalence of "Yesterday, Today, Blockers". And I've seen a few teams that filter the board to display just the cards belonging to the person that's talking. That's HUGE missed opportunity, IMHO. I want _the team_ to be focusing on "our work", rather than _team members_ focusing on "my work".
(Genuine) question on subtasks: do you track them across the board (do they appear as cards?) - or are they part of a Story card?
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
Simple... but brilliant!
I was doing exactly the same thing with a small yellow sticker with a number on it,... "back in the old days" of physical boards and co-located teams
#nostalgic😢
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
Yes, DoD would be an excellent addition. (Annoyed I didn't think of it!)
Adding this to my short list of required watching for any project manager or scrum owner.
Really? Fantastic!
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!
Thank you! This was a bit of an experiment (with the overhead camera) and I'm glad you liked it!
@@Developmentthatpays paid off. Physical props can be as impactful (sometimes more) than fancy graphics.
You're right!
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.
Agree with you 100% on blocked items. There's a related item that I'd love your option on: there are some comments along the lines of "blocked, pending action from a third party". If the block really is "outside of the team's control", perhaps there's an argument for moving the blocked card "outside of the WIP limit". What do you reckon? (I'm aware that creating two kinds of "blocked" will end up with liberties being taken!)
One more thought on this: if "blocked-by-third" party is something that happens regularly ( _is part of the workflow_ ) then what's actually required is a new column (or column pair). Put another way, the item isn't blocked, it's just moved to a new process.
On the one-and-only "Done": a couple of people commented that I neglected to mention Definitions of Done (DoD) - note the plural. Think it's the kanban way to have a DoD for each process column. So "Design is complete when the DoD for Design has been satistfied", So "Dev is complete when the DoD for Dev has been satistfied", etc. How do you feel about multiple DoD's?
@@Developmentthatpays If the block really is "outside of the team's control" should it stay in the sprint? The problem with putting it in the Blocked column is that you do not go back to it because you are getting on with other things. Keeping it in place on the board means there is a regular, in your face reminder of a problem/Block that you need to get rid of either by fixing it or removing it from the sprint and dealing with it more appropriately.
If Blocked by third party is part of the workflow, officially or unofficially, it is not blocked. That is like saying these items are blocked by the release team because they have to wait to the next quarterly release to go live. Something that is blocked should be able to be fixed or there is a much bigger problem that the development team has identified but should not get bogged down with.
Blocking an item on the board is to highlight it to the team in case it may impact others, but also to highlight that help is needed to fix it. if it is going to take a while to fix think about removing it and getting on with things the team can do.
@@Developmentthatpays I have worked with teams where design was imbedded and Done meant released into production so there was only one DoD, but this is the ideal and most organisations do not have this capability. This is where different DoD can be useful.
The problem I have with multiple DoD's is when they are within the development cycle. I only see impediment if there is a Dev DoD and a Test DoD etc. They are just additional hand offs, stage gates that impede progress, add bureaucracy and ultimately waste everyone's time.
@@malcolmlisle543 - [Re. blocked items] Sooooo much good stuff here - especially the bit that hadn't occurred to me: throwing the blocked item out of the Sprint.
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
Thanks, Michael - Great stuff as always!
- On point 1: I'd never though about it that way before: that the (single) column *_is_* the "in progress"!
- On point 2: What a difference a word can make! As you say, there's a WORLD of difference between "Test" and "Review" (or "Validate"). Huge!
- On Expedite: Excellent points one and all! (I may have to do a video on that!)
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.
Can't believe you used the "W" word !!! My mental model here is not "Dev --> Test" (which has... _challenges_ ) but "Design --> Dev". It comes from this video vimeo.com/88885445#t=28m18s featuring Corey Ladas. It starts at 28:18; at 30:15 he asks "Why would we make the split?"; a bit later he talks about why we might UNDO the split.
---
You're completely right about testers helping developers if needed. (Annoyed with myself for not mentioning that in the video.)
@@Developmentthatpays OK. I see Cory’s idea there. I think in my experience, the work he puts in “Specify” has already been done in refinement and planning before it even gets to the To Do column of a sprint board.
Now I’m thinking about it in a Scrumban context (I was inspired by your Scrumban videos to introduce it to my teams with great success, and used them to sell the idea to the team, so thank you!). I like to propose to the team that (digital) boards use the user story/PBI/thing-of-value as swim lanes. Sub-tasks under those stories are the cards that flow from left to right. In this scenario, ‘specify’ might be a time boxed subtask to come up an approach that populates more subtasks for the user story to get to done. And of course at any time more subtasks can be added or removed as more is understood. The Test column is removed and testing work becomes subtasks that flow through the same three columns as ‘specify’ and ‘code’.
And the team always pulls, never binds early and respects the WIP limits.
Excellent --> "And the team always pulls, never binds early and respects the WIP limits."
Re: "Story/PBI/thing-of-value as swim lanes". This is an area I've been giving a lot of thought to recently (around what actually gets tracked across the board). Might make a good subject for another video.
Thanks for sharing such knowledge session 🎉
Doing column I can say it as cycle column alternatively ❤
Interesting. Can you say more about "cycle" as a column name?
Thanks for this
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!
Ah, this is an excellent point (that I completely failed to address!)
I wonder how others handle *failed work items* . _Please chime in below._ 👇🏻
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.
You've reminded me of something we had on the first board I ever saw: I big laminated "STOP" sign. When we had an outage, the sign was stuck right in the middle of the board - to indicate that "we've got an emergency and we'll get back to the Agile stuff when it's resolved". (Better, I think, than an expedite column that "invites" emergencies.)
Like in ANY Hospital, the Triage helps in "maximising the flow" of patients based on severity, urgency and time of arrival.
But when a huge car crash happens and some life-endangered people arrive, there is no "Expedite swimlane", but something more like Gary's STOP signal on anything in ToDo (100% will wsit), on most of stuff In Progress with lower priority (75%?) but NEVER on something that's Urgent, Emergent and almost Done, and that can be finished to make space to the new Top Emergency.
You don't kill a patient to save another one (unless it's WAR).
The only risk is that the "exception" once per month becomes the "norm" every week, because someone is screaming loud! 😮
@@michaelforni This is exactly what I was thinking. Isn't thaw the "exception", that might happen frequently, mitigated by the triage process?
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.
I got this a bit wrong in the video. I _added_ the WIP for the "Done"... and I should have _taken it back_ when I introduced shared WIP. (See comments from @paulhenman above.)