Optimizing kanban workflow due to lagging dependency

Question

The following describes a situation where I am no longer part of. I recently had a shower thought about the past situation and wanted to see how the situation could've been improved. This is my first question on PM so I hope this fits so I can learn something.

We had a small team consisting of developers, a product owner, a tester, and an external freelance designer.

The workflow at the beginning
Frankly, there was no real workflow. Storys and tasks got discussed, developers started to work on it. The designers did what they could do, and everything came together eventually.

The dependency story
Due to the nature of the designer being a freelancer, we can't really influence when and how the person is working on the task. We worked with designer A, then switched to designer B because B wanted to do even more than just design in the project and had enough time to spare. Shortly after starting, midst in changing a lot of the design, personal reasons led B to leave the project. We had good experiences with designer A (except for the lack of time), A knew the project as well and also brings a lot of own ideas into it. Thus, we switched back to A.

Switching designers always resulted in a lot of overhead work because of conceptional changes, design styles, etc, and brought a lot of unrest into the project. We were happy with having A back to not have too much of an overhead.

The bottleneck
Due to the designer not having enough time, the team started to work on a lot of stories in parallel. The more stories got finished, the more work was there for the designer. This was a bad process with a lot of waste, as the situations repeated itself; The designer was always lagging, developers were always ahead.

The restart
the project completely re-started because of COVID and a re-orientation of the concept to adapt to the uncertain times. The team agreed on doing Kanban in order to have a proper visualized workflow, and with the WIP limits, the aim was to completely finish one thing after another to prevent having the same chaos we had before.

The Kanban workflow looked like this:

• Ready for design
• In design
• Ready for development
• In development
• Ready for review
• In review

There is a WIP limit of 6 on all those "in progress" columns, except for the design ones; There we have a WIP limit of 2.

The bottleneck workaround
We still have the designer bottleneck. However, there was an idea of improving the workflow by "wrapping" the design columns in development columns. The suggested workflow would look like this:

• Ready for prototype
• In prototyping
• Ready for design
• In design
• Ready for development
• In development
• Ready for review
• In review

The idea is that, during the "prototype" part, a story is being implemented with what is already available design-wise in the component styleguide. During the prototype, the story is being challenged to see if it would work and to gather knowledge. Only then, a task will be ready for design – if anything would be needed from the design at all. The development phase would then just be about implementing the design, adapt the code when necessary, and add automated tests.

The question
Would the new workflow make any sense at all, or would it just cover the symptoms? What would you suggest for improving?

Answer 1

The new workflow would work if it reduces the load on the designer.

I'm not sure I understand the full picture, but you say:

Due to the designer not having enough time, the team started to work on a lot of stories in parallel. The more stories got finished, the more work was there for the designer. [...] The designer was always lagging, developers were always ahead.

And then you propose a new workflow where:

[...] during the "prototype" part, a story is being implemented with what is already available design-wise in the component styleguide. During the prototype, the story is being challenged to see if it would work and to gather knowledge. Only then, a task will be ready for design – if anything would be needed from the design at all. The development phase would then just be about implementing the design, adapt the code when necessary, and add automated tests.

Isn't this the same thing? You still have your developers ahead, and your designer lagging.

If my understanding is correct, this new arrangement will "reduce friction" between the designer and the work already done, by having the designer only design something that was already "validated to work". If there is back and forth between the team and the designer on some work, it makes sense to reduce this back and forth with a phase of "prototyping", as you call it. It's basically making sure the work for the designer reaches the designer in a format that will be most efficient for them to work on it.

When you have a bottleneck like you are describing, you have the options of:

• having the team swarm on the bottleneck, basically others in the team stop what they are doing and go help the designer (might not be possible because of the specialized skill);
• make sure the work that reaches the bottleneck is in its most efficient format, so that it enters and leaves the bottleneck as fast as possible (this is my understanding of what you describe trying to do with your new workflow);
• add more designers (or at least someone who can work full time) to reduce the bottleneck, and thus be able to use a WIP limit of 6 on the design work also.
• better/more forward planning can also be a solution, by knowing when the designer will be available and sending them work in advance, so that they do it and you have it available later on when you need it.

In all honesty, external or not, if a human/material resource isn't available when you need them/it to be, then you are accepting to live with a risk to the project. You are trying to work around the bottleneck, but you still have the bottleneck limiting the flow of work. Ideally, you need to remove the bottleneck, which in this case probably means hiring more designers or someone who is available full time.

Answer 2

You're acting as if your bottleneck is something bad and you should rid of it. This may be true, but I'd like to list other options. There are 3 approaches to dealing with constraints:

1. Improve their performance (Bogdan got it covered in his answer) (book)
2. Use them to dictate the performance of the system (same book)
3. Use them to pivot your business (another book)

I'd like to emphasize the importance of #2. You always have a constraint. Approach #1 doesn't fix constraints - it shifts them to other parts of the process. Once you improve performance of the designers - some other part of the team will become a constraint. You want to balance it all out so that every part of the team works with the same speed? This is impossible in principle: you may only balance out the "average" performance of your team members. But in reality their performance changes from day to day - and that's the performance that's important and will keep you awake at night.

Sometimes you just need to breathe in, breathe out and.. embrace that that's the performance of your team. Theory of Constraints says that only the bottleneck has to work 100%, other parts of the process must slack from time to time. If you start balancing it out - you often will get even worse performance. The hubbub around you will make you think that you became faster, but in reality you'll be going back-and-forth a lot (physics analogy: your speed will be high, but your velocity will be low).

The fact that your bottleneck is at the beginning of the process is great. That's how everyone should do Just-in-time in software. So maaaybe instead of fixing it - you just tell everyone to calm down. If bored developers can always research the domain better, automate tests, refactor, optimize the product, optimize the process (deployment pipelines), read about good code, security, etc, etc. It's something that we usually don't have time to do.

PS: this all is also the reason why you need WIP limits in Just-in-time - one step of the process works faster than the other and you don't want tasks to accumulate. In perfect world you wouldn't need them, but that's not the world we live in :) BTW, you should set limits on buffer columns (Ready for XXX) too.

PPS: designers have a lot of work (compared to developers) only at early stages of the project. Your problem may resolve itself with time.

Answer 3

I think there is at least one issue - cards are put on Kanban board which are not ready/have dependencies. You can solve it of course, by simply using additional columns, but I bet you will end up with more of those "dependency" states.

Personally, I would suggest breaking down your process into two separate Kanban Boards. One for planning and refinement (including design). Other for development only. This way you will have a more transparent throughput/cycle time, as well as cleaner focuses for specific specialists on your team.

If that sounds like an overhead and you are doing it on physical Kanban board, maybe you can use electronic versions which support cross-board workflows: https://teamhood.com/kanban/physical-to-digital-kanban-board-in-2020/