0

Background

My team is an outgrowth of the "low code, no code" movement, originally utilizing visualization tools and lightweight ETL tools for data analytics; we're progressed to some more advanced toolsets. We organize ourselves in terms of "products", which are aligned to different stakeholder groups. Most team members own multiple products.

Each team member takes on three roles:

  • Product Owner - Feature Prioritization, Stakeholder Management
  • Business Analyst - Translating Features into Requirements
  • Developer - Executing changes themselves

This is a double edge sword. Team members are able to listen and respond to business needs in rapid manner (no hand offs). However, as a people leader, resource constraints, burnout, and bus factor are real concerns.

Problem

Today, we operate in a proto-Kanban environment. Features and User Stories are placed on a board but to varying degrees of specificity and granularity. We're trying to adopt Kanban best practices (e.g. explicit definitions of done, visualizing emergent processes). However, one best practice (and frankly, what got me hooked on Kanban) I'm struggling with is WIP limits.

If team members were specialized for particular process steps, I see the utility of WIP limits. However, team members own the end to end product development process from scoping, execution, verification, and deployment. My real concern is the balance between different products for a given team member. Based upon my research, "per person" WIP limits are a sign of low Kanban maturity.

Question:

How would you recommend I amend my approach given the situation?

Options I've Considered

  1. To encourage T-Shapeness and reduce bus factor, have team members work on features regardless of the "traditional" product they support. Drawback to this approach is there's a significant learning curve to begin supporting a given product and I want to minimize context switching beyond what's already happening today.
  2. Assign WIP Limits Per Product.

Thank you for your expertise in advance.

2 Answers 2

0

To encourage T-Shapeness and reduce bus factor, have team members work on features regardless of the "traditional" product they support. Drawback to this approach is there's a significant learning curve to begin supporting a given product and I want to minimize context switching beyond what's already happening today

You make valid points here. However, don't overlook the main advantage of t-shapendess, which is flexibility. If you have individuals dedicated to products then the work the team takes in for a given product must match the capacity of the assigned individual.

With a t-shaped team you have more flexibility to prioritise work and the ability to 'swarm' on products that need urgent attention.

Assign WIP Limits Per Product

Usually the best advice with WIP limits is to experiment. Try an approach and measure the cycle time to see what the impact is. Adapt until you feel you have a WIP limit that is effective.

0

WIP limit on "doing" part is still equal for everyone - one task at a time. Having a unified process among everyone is one option.

Having a specific process covering all skillsets - again fine, if you set WIP limit of 1 per person specific Kanban column.

Lastly, since you have business analyst, maybe your process is a two piece puzzle? Pre-work and actual work. I have written a full post about working with timelines in kanban and organized the process to help that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.