Managing the Kanban Board

What commitments is the team actually making here, and have they got the right policies to ensure that they meet them?

Emre - I invite you to review the Scrum Guide as well as the Kanban Guide for Scrum Teams. With that background I suggest you form a perspective on what's missing in how the team is working, and more importantly why that matters. 

Specifically - what's the impact of not creating these tasks? how is that affecting the team's ability to deliver value? to achieve their Sprint Goal? To be committed and focused as a team? (maybe it is having an impact, maybe it's not... tasks aren't required in Scrum... and detailing the entire Sprint Backlog during Sprint Planning isn't required either...) 

I find that one of the interesting things that start to happen when Scrum Teams and practitioners start to think about Flow/Kanban is it gets them to really think about WHY they're doing things and understand the deeper intent rather than follow the mechanics. And THAT brings them closer to Professional Scrum. 

Bottom line Scrum isn't about managing tasks or keeping kanban boards or backlog lists up 2 date. All these MIGHT be useful in helping the team deliver value in an environment of complexity/uncertainty. There might be other ways. Talk to the team about outcomes rather than mechanics. 

Maybe find a connection between what's going on and the value areas discussed in Evidence-based management as a way to have a conversation with the team about things that really matter to them. 

You wrote, that you joined the company as a "Kanban Master". Did i understand it correct, that you are not doing scrum? 

I am just asking, because this is mostly a scrum board, where people will answer you, how to do it in scrum ;) ?

What commitments is the team actually making here, and have they got the right policies to ensure that they meet them?

They are just not committing to any policies. Instead they say "yes, yes, I will do it" and just don't do it, because there are no consequences. 

You don't mention whether you are using any of the Scrum framework.  And as a "Kanban master" it doesn't seem like you would be.  So the answers you get here might be a bit skewed.  

But @Ian has the right idea in asking whether the team has the right policies in place to meet the commitments.  Kanban, like most other agile practices, is not as concerned with having all of your tasks on a board as they are on delivering the right value at the right time.  In my opinion, you shouldn't be so worried about getting the detailed tasks created because the time it takes them to do that takes away from the time that they have to do productive work.  

I suggest that you stop worrying so much about the little details and start focusing on the team's ability to deliver the value that is needed by your stakeholders at a time that value is needed. On a Kanban board the thing you track is the value not the individual tasks.  The columns of the board should reflect the actual workflow that the value delivery goes through. This goes back to the days of Toyota where Kanban was used as an inventory control mechanism.  The items that crossed the boards represented specific types of inventory.  They were progressed through the workflow to help visualize the state of inventory at all places it was needed.  In any place where I have used a true Kanban board, the workflow didn't apply to individual tasks.  So we often just had an item that described the valuable deliverable and progressed that across the board.  

To this day, I use the same practice when I'm using a visual board no matter the agile practices we use.  Value should be the focus, not the details of the work being done.  

What commitments is the team actually making here, and have they got the right policies to ensure that they meet them?

Dear Lan Mitchell, I must say that we receive commitment from the team for all the work to be done after each iteration planning.  Frankly, the problem here is that they don't have the right policy, as you said.The team here focuses on getting the task done instead of focusing on value and that's why i guess kanban board seems like drudgery to them.

 But @Ian has the right idea in asking whether the team has the right policies in place to meet the commitments.  Kanban, like most other agile practices, is not as concerned with having all of your tasks on a board as they are on delivering the right value at the right time.  In my opinion, you shouldn't be so worried about getting the detailed tasks created because the time it takes them to do that takes away from the time that they have to do productive work.  

Dear @Daniel thanks for your explanation and I give you eternal right on this matter. But my concern here is monthly individual and team performance reports are based on kanban board. In other words, the senior management questions the productivity of the teams through these reports at the monthly evaluation meeting. The team actually does its job and creates value, but there seems to be a problem because it doesn't reflect correctly on this board. If the team can do this job instantly, there will be no problem anyway. 

After each daily meeting, I go to all team members and I say keep these jobs updated one by one. I know I should never have done this but I couldn't get the team members to take the initiative

If the team is creating value, but their productivity is questioned by senior management based on some Kanban board I would suggest to take the conversation with senior management rather than with the teams.

You could lower the WIP limits.



When they agree who does what, they may be incentivised to make tasks.



Or they may still not be doing it. Is it part of the Definition of Workflow to crate tasks? Why have they agreed to put it in the DoW if they don't want to do it?

 In other words, the senior management questions the productivity of the teams through these reports at the monthly evaluation meeting.

Agreeing with the other @Daniel.  The problem seems to be with the way senior management evaluates individuals and not with the team getting the work done to provide value.  You should try and educate senior management on how agile processes work and how to focus on value instead of tasks.  

This newly discovered information makes me go back to what @Yuval said earlier. 

Maybe find a connection between what's going on and the value areas discussed in Evidence-based management as a way to have a conversation with the team about things that really matter to them. 

Evidence-based Management (EBM) would be a great way to do this.  Possibly suggest that all of them read the EBM Guide found at that url and facilitate discussions with them on the topic.