you need to set column limits and change your workflow on the kanban board to a pull instead of a push. that means means you'll have two columns per step in your development process. Then you can set alerts if certain items remain for too long or there are too many items in a column.
That way you can spot issues in your development pipeline immediately as they happen
Project management without meetings.
Meeting driven process is a roadblock to delivering better software.
Uclusion is a new way to communicate and track stories at the same time.
As Pawel noted there are any number of Kanban blogs explaining that is an anti-pattern. I'm just picking one at random linkedin.com/pulse/blocked-bad-bre...
you don't understand at all what I just said, there is no blocked column at all. Again, review the video I've put down below. It works and the microsoft OS is build using this agile kanban style of working.
Project management without meetings.
Meeting driven process is a roadblock to delivering better software.
Uclusion is a new way to communicate and track stories at the same time.
Trouble maker and Problem solver ⚙️🔧
Loves simplicity, hates bullshit 💩.
Productivity obsessed, avid learner 🖥🚀
Sport and outdoor freak 🧗⛰
Metalhead 🎸🤘 Father of 2 👨👩👦👦
Opinions are my own
honestly.. i often dont care much if i am sticking to the orthodoxy of a method.
I adapt it to my team, my project, my workflow.
we indeed have the column BLOCKED. and i think it is very usefull because, it clearly shows that a developer CAN NOT work on something - and probably explains why they have more than one ticket IN PROGRESS at once.
but the order for us is:
TO DO - IN PROGRESS - BLOCKED - IN REVIEW - DONE
and there is hardly any going back because blocked is when the work is impossible due to forces external to the team ( further implementation is impossible without other tickets being completed, often from other departments, requirements have to be rediscussed by stakeholders etc). not because dev is sick, or cant solve a bug.
We're going in circles and it seems clear to me you have an agenda here rather than just looking at the facts and information that has already been presented.
Agile was never about being rigid in the process, that's the whole point of Agile to take things that work and make them fit within the context you operate.
All this talk about "this is agile", "this is not agile" seems to indicate dogmatic approaches that are actually an anti-pattern.
Trouble maker and Problem solver ⚙️🔧
Loves simplicity, hates bullshit 💩.
Productivity obsessed, avid learner 🖥🚀
Sport and outdoor freak 🧗⛰
Metalhead 🎸🤘 Father of 2 👨👩👦👦
Opinions are my own
exactly :-) it is called Agile in the end right?
and i'd like to mention 2 of the points listed here
Individuals and interactions over processes and tools
Responding to change over following a plan
that;s why imho being dogmatic is as @rolfstreefkerk
explained an antipattern.
let's do whatever fosters good communication and helps us moving forward and faster.
let's do whatever fosters good communication and helps us moving forward and faster
Or... How about use a software that let's us use whatever we want, not stick to shitty JIRA that forces use to change the process, because it's so limited? I mean, having the tickets marked as clearly blocked doesn't seem like rigid and dogmatic approach. Saying that you don't need it because JIRA does not support it - does (where using JIRA is a dogma).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
you need to set column limits and change your workflow on the kanban board to a pull instead of a push. that means means you'll have two columns per step in your development process. Then you can set alerts if certain items remain for too long or there are too many items in a column.
That way you can spot issues in your development pipeline immediately as they happen
As Pawel noted there are any number of Kanban blogs explaining that is an anti-pattern. I'm just picking one at random linkedin.com/pulse/blocked-bad-bre...
you don't understand at all what I just said, there is no blocked column at all. Again, review the video I've put down below. It works and the microsoft OS is build using this agile kanban style of working.
If there is no blocked column then you are using a flag and that didn't work for Pawel either.
honestly.. i often dont care much if i am sticking to the orthodoxy of a method.
I adapt it to my team, my project, my workflow.
we indeed have the column BLOCKED. and i think it is very usefull because, it clearly shows that a developer CAN NOT work on something - and probably explains why they have more than one ticket IN PROGRESS at once.
but the order for us is:
TO DO - IN PROGRESS - BLOCKED - IN REVIEW - DONE
and there is hardly any going back because blocked is when the work is impossible due to forces external to the team ( further implementation is impossible without other tickets being completed, often from other departments, requirements have to be rediscussed by stakeholders etc). not because dev is sick, or cant solve a bug.
We're going in circles and it seems clear to me you have an agenda here rather than just looking at the facts and information that has already been presented.
Agile was never about being rigid in the process, that's the whole point of Agile to take things that work and make them fit within the context you operate.
All this talk about "this is agile", "this is not agile" seems to indicate dogmatic approaches that are actually an anti-pattern.
exactly :-) it is called Agile in the end right?
and i'd like to mention 2 of the points listed here
Or... How about use a software that let's us use whatever we want, not stick to shitty JIRA that forces use to change the process, because it's so limited? I mean, having the tickets marked as clearly blocked doesn't seem like rigid and dogmatic approach. Saying that you don't need it because JIRA does not support it - does (where using JIRA is a dogma).