that's not exclusive to your software. Any Kanban board can indicate problems with items when they're blocking allotted in progress issues or have been worked on over the average issue estimated effort.
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.
Is exclusive if you want to be able to skip the meetings. A Kanban board can be tricked out to display anything but not to get questions answered, pause stories or take up new ones while getting approval online.
On top of which you need a notifications system that does much better than a Kanban + Slack combo.
The original purpose of Kanban is to get insights into the manufacturing process and that especially includes blockers to progress. So yes, I agree if you do not follow this process and setup your board properly to the process, this will be less effective.
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.
It doesn't matter how you setup your board. A Kanban board is a display only tool - you can't effectively have communication inside of it or get approvals for new stories or reviews of existing work.
It shouldn't surprise you very much that 1950's factory sticky notes don't cover all aspects of modern software development.
This is really making a mockery of Kanban for software development, that's not at all how it's done. I suggest you review this excellent talk from a Microsoft employee on how they've effectively used the Kanban method to tackle issues that we've just discussed. youtube.com/watch?v=CD0y-aU1sXo
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.
Frontend developer by day, iOS developer by night. Currently working on learning iOS development and my own blog, Mike Decodes, where I'm decoding the tech industry. Come hang out with me on Twitter!
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.
The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.
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. this is not a software/tool issue, rather a communication/soft skills one.
Since we do remoting (started in March 2021 due to Covid and we will probably go on like that even after) we are doing Slack status updates when everyone signs-off at the end of the day.
They perfectly answer the first question of a Standup ( What did you do yesterday - in this case, today) and I find those updates very informative and very useful. But the main point of the standup is raising the awareness of potential blockers and share information that cannot emerge by moving cards around.
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.
A meeting is a tool. There are limits to what can be accomplished with synchronous meetings as there are limits to any tool. No matter how well you run the standup or do soft skills communication the meeting happens point in 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
everything is a tool. language is a tool. outcome varies depending how you use the tool.
in my post I am addressing a specific problem related to communication and softskills in the people attending standups, which I noticed in 10 years of Daily Scrums, in different teams and projects.
I am absolutely fine with Daily Scrum and Kanban, how they are meant, and I am fine with Jira and Trello ( never used other tools so far, so I can;t say) , just wanted to stress how too often we overlook the main point of it, forgetting the blockers and limiting it to a round-up of how was your day yesterday..
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
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.
The concept that we somehow forget to mention our blockers in daily standup meetings?
So you are basically saying that in 10 years of Daily Scrums, in different teams and projects, the only thing you learned is that software developers are deeply incompetent.
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
ah ah! you can say so :wink. or you can say that developers have really to invest more energy in soft skills and communication.
Personally, I like to talk and discuss a lot about coding and tasks, and normally the awareness of blockers emerge while chatting, via a quiet request of help on slack or by physically seeing that a dev is struggling with an issue or having lots of discussions with other members. I understand that PjM and other stakeholder might need different tools, like daily standups, which unfortunately are not often optimal. not because people are stupid, incompetent, or malicious, rather because of lack of communication skills, experience, confidence.
have a nice day
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.
Yes let's imagine for a second that people are not ridiculous enough to attend a meeting whose only purpose is to mention blockers and then forget to mention blockers.
Alternatively let's hypothesize that it's the meetings fault...
Suppose for instance that to a developer a point in time meeting doesn't really serve much purpose. He after all has to continue coding throughout the day. He's going to face blockers the entire day also.
So to a developer whether or not he mentions the blockers at one particular time of day is not very relevant. The meeting makes no sense and so he doesn't take it as seriously as you.
Can it, really? I always struggled with setting up a kanban board in JIRA which would display blockers properly (full disclosure: I'm by no means a JIRA expert, I don't event have admin rights to it usually, so maybe I miss something). The only way it could be done was by setting up a column called "blocked", but it violates the rule that the tasks should only move forward. Other ways, such as a flag, were not visible enough, when looking at the board.
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.
@katafrakt
you didn't miss anything. Since other PM tools don't have a notification system that enforces action you are left choosing between flags and columns.
One flag or column for truly blocked and another for stories with outstanding questions or suggestions. (Or you can collapse those two types to one but that again muddles things.)
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.
that's not exclusive to your software. Any Kanban board can indicate problems with items when they're blocking allotted in progress issues or have been worked on over the average issue estimated effort.
Is exclusive if you want to be able to skip the meetings. A Kanban board can be tricked out to display anything but not to get questions answered, pause stories or take up new ones while getting approval online.
On top of which you need a notifications system that does much better than a Kanban + Slack combo.
The original purpose of Kanban is to get insights into the manufacturing process and that especially includes blockers to progress. So yes, I agree if you do not follow this process and setup your board properly to the process, this will be less effective.
It doesn't matter how you setup your board. A Kanban board is a display only tool - you can't effectively have communication inside of it or get approvals for new stories or reviews of existing work.
It shouldn't surprise you very much that 1950's factory sticky notes don't cover all aspects of modern software development.
This is really making a mockery of Kanban for software development, that's not at all how it's done. I suggest you review this excellent talk from a Microsoft employee on how they've effectively used the Kanban method to tackle issues that we've just discussed.
youtube.com/watch?v=CD0y-aU1sXo
Wow the part on estimation in that video is cringey. And naturally it doesn't cover any of the issues we are discussing around the standup like
Work, hopefully 😂
Not according to the Scrum guide:
exactly. this is not a software/tool issue, rather a communication/soft skills one.
Since we do remoting (started in March 2021 due to Covid and we will probably go on like that even after) we are doing Slack status updates when everyone signs-off at the end of the day.
They perfectly answer the first question of a Standup ( What did you do yesterday - in this case, today) and I find those updates very informative and very useful. But the main point of the standup is raising the awareness of potential blockers and share information that cannot emerge by moving cards around.
A meeting is a tool. There are limits to what can be accomplished with synchronous meetings as there are limits to any tool. No matter how well you run the standup or do soft skills communication the meeting happens point in time.
everything is a tool. language is a tool. outcome varies depending how you use the tool.
in my post I am addressing a specific problem related to communication and softskills in the people attending standups, which I noticed in 10 years of Daily Scrums, in different teams and projects.
I am absolutely fine with Daily Scrum and Kanban, how they are meant, and I am fine with Jira and Trello ( never used other tools so far, so I can;t say) , just wanted to stress how too often we overlook the main point of it, forgetting the blockers and limiting it to a round-up of how was your day yesterday..
having said all that. I'd suggest to continue the conversation about the concept and not about your specific tool @uclusion thanks
The concept that we somehow forget to mention our blockers in daily standup meetings?
So you are basically saying that in 10 years of Daily Scrums, in different teams and projects, the only thing you learned is that software developers are deeply incompetent.
ah ah! you can say so :wink. or you can say that developers have really to invest more energy in soft skills and communication.
Personally, I like to talk and discuss a lot about coding and tasks, and normally the awareness of blockers emerge while chatting, via a quiet request of help on slack or by physically seeing that a dev is struggling with an issue or having lots of discussions with other members. I understand that PjM and other stakeholder might need different tools, like daily standups, which unfortunately are not often optimal. not because people are stupid, incompetent, or malicious, rather because of lack of communication skills, experience, confidence.
have a nice day
Yes let's imagine for a second that people are not ridiculous enough to attend a meeting whose only purpose is to mention blockers and then forget to mention blockers.
Alternatively let's hypothesize that it's the meetings fault...
Suppose for instance that to a developer a point in time meeting doesn't really serve much purpose. He after all has to continue coding throughout the day. He's going to face blockers the entire day also.
So to a developer whether or not he mentions the blockers at one particular time of day is not very relevant. The meeting makes no sense and so he doesn't take it as seriously as you.
Can it, really? I always struggled with setting up a kanban board in JIRA which would display blockers properly (full disclosure: I'm by no means a JIRA expert, I don't event have admin rights to it usually, so maybe I miss something). The only way it could be done was by setting up a column called "blocked", but it violates the rule that the tasks should only move forward. Other ways, such as a flag, were not visible enough, when looking at the board.
@katafrakt you didn't miss anything. Since other PM tools don't have a notification system that enforces action you are left choosing between flags and columns.
One flag or column for truly blocked and another for stories with outstanding questions or suggestions. (Or you can collapse those two types to one but that again muddles things.)
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).