Should we assign work to individual team members in Kanban?

Question

From my understanding, in non-agile settings, the project manager is responsible for assigning work to individual team members, but in a (self-organized) Kanban team, team members do this when they have slack, in accordance with the team's capacity (WIP limit).

Context

Our product/tech team doesn't have much experience in an agile environment, it is cross-functional, and we have a variety of projects, which may require input from the specialists (UI/UX designer, front-end developer, GIS specialist) that are on the team. Sometimes, entire projects can only be worked on by specific team members.

Hence the following questions (really 2 ways of looking at the same issue, IMHO):

1) As a PO, while planning the work, should I take into consideration who can work on the product backlog items (thereby "pre-assigning" work), or should I just sort them by priority (business value and other factors)?

2) As a team member, what should I do if I don't have the technical expertise to pull what's at the top of the "Ready to work" column into build if...

a) ... we haven't reached our WIP limit yet

b) ... we have reached our WIP limit

Answer 1

As @Daniel has already said, Kanban is not prescriptive - it asks you to start with what you today - and make incremental changes to your process to improve flow.

On a slightly different note, Agile teams with not too much experience initially have this issue of team members not being able to pull - or self-assign - work, because they are too used to being told what to do. Even in longer running Kanban teams, young/ new team members not used to Kanban have the same problem. In most cases, at least for some initial period of time, the team - the PO, the Scrum Master or the Engineering Manager - and the team member themselves will jointly decide in a standup meeting what work can be taken up by that team member. This can continue until such team members feel confident enough or empowered enough to pull work whenever they are ready to start on the next one.

Finally, it is the reality for many small and medium teams that specific people become experts in specific modules of a software they have built and maintain - or have specific technology skills such as front-end, backend database or some such skills. The PO and the team have no alternative but to wait for the right set of people to be available to work on tasks that need those skills.

As a Kanban-based dev shop, we do what you have outlined. We populate the Ready column with the next set of the highest priority/ business value items - and whenever the team members who are to (and can) work on those items become available, they will pull those items.

As for the team members who don't have skills to do the next set of items sitting in the Ready queue, whether your WIP Limit has been reached or not is a moot point. They just can't work on those tasks because they don't have the skills. They can either work on some intangible (class of service) work - such as some refactoring of code, perhaps documentation, or some such work - or ask the PO to identify something new they CAN do, since sitting idle is usually not an option. Here's a board design by class-of-service that you might consider -

In the meantime, as a team, as @Daniel suggested, you have to work on cross-training of team members so you reduce your people-dependency to some extent, and enable more people to take on more kinds of work that they would typically not consider to be "their work".

Answer 2

Kanban should be a pull system, so you should not assign work. However, one of the core principles of Kanban is to start with what you do today and make small incremental improvements. If today people pull the work they can do, then ok, start with that. However, another thing Kanban requires is that we manage and measure flow. This is what I commonly see teams discover almost immediately:

When you pull work based on what you can do rather than what needs to be done, you increase the lead time for valuable work you can't start on. Many teams also immediately discover that there is a pile of important work waiting on one or two people who know how to do it. If you see this and do not acknowledge it and make small moves to improve this area, then you aren't practicing Kanban. A lot of teams will skip this step and just start sorting the backlog by priority. In fact, almost all teams I've coached at least tried to do this. It is bending the rules a bit, but the benefit usually outweighs the damage and I've never once known of a team who got more benefit out of keeping their silos where there was more valuable work to do.