How can we adopt Kanban to our workflow?

Question

I'm working in a creative agency, with 8 people sharing the same physical space. Some of us travel often, and we are loosely organized in the following departments:

• RnD,
• Design,
• Social, and
• Management.

We mostly work on client projects, with the departments usually working in parallel. Our current workflow is - roughly - the following:

• Requirements: Management talks to clients and gathers requirements
• Design: Our designers propose and finalize the UI
• Build
• Test
• Go Live and Social

Also, we switch between projects very often.

We are looking for a better way to collaborate (individually and between departments), fix our workflow and store information (issues, tasks, ideas, etc) and are currently investigating Kanban, mostly because of its ability to adapt to current workflows.

How can we adapt Kanban to our workflow? Should we organize this workflow into columns or have it like labels on it's task? Social tasks and development tasks have a lot of differences. Should we put all of them in the same backlog? In what abstraction level?

Is there a more optimal solution for our workflow?

Answer 1

I just came across your question - I am not sure if you are still looking for an answer, but nevertheless, here goes. (Just as a background, I am the product owner in a Kanban product company - and have experience with product development within our organization using Kanban; as also talking to many application/ product dev teams, so my response comes from the lessons from all of that experience).

Firstly, it would be interesting to know some additional information -

1. How many projects do you typically have active at any point of time? How long do customer projects run, on average? Do people work on multiple projects at a time (I believe the answer to this last question is yes.)
2. Would you let your customers see the Kanban boards, if you were to set up Kanban boards?

But, in any case, based on what you have said, let me respond. Two main things you have said you are trying to solve make Kanban a really good choice -

1. To collaborate better, and
2. To fix your workflows

In our experience, the visibility and the 'cross-tribe' view that Kanban provides, where you are able to easily see what various people in each function (tribe) is busy with, where they might be stuck and need help, etc. makes it an awesome team for people across functions to communicate better, collaborate better, help resolve issues and make task assignment (self-assignment with Pull) and resource balancing (thru WIP limits and the ability to see visually who is loaded how much) decisions more effectively.

Kanban's very nature - at least Kanban Method, as defined by David Anderson - is to help you start with your current workflow - and then go from there to improving it gradually as you identify the problem areas - bottlenecks, WIP limit violations, resource overloading, etc. - and fixing them one by one. (In fact I recently blogged about this here in case you are interested - http://bit.ly/2n4frr8)

So, my opinion (altho I may be considered biased!) is that Kanban should be a great solution for you.

As to how you might draw up your initial Kanban board, answers to my questions above would help - but you could easily start with either a simple Kanban board with a single swim lane for the entire company, with columns for each workflow step, between a common Backlog and Ready at the beginning (left of the board) and a Done/ Deployed/ Archive columns at the end on the right. You might use color coding of cards/ stickies to show work for different projects/ customers - and other stickers to be used on each card to show who is working on it, what type of work is it (user story or defect or change request or just a simple task) and other things such as a blocked status or other attributes of the card.

A different alternative would be to define multiple swim lanes - one for each Client or each project. (The project disadvantage may be that depending on the number of projects you do at a time, you might end up with a huge board - AND - at the end of each project, you will have to re-label the board with another project's name. Since you might be doing repeat work for each client, it may be better to have client-specific swim-lanes.

A third alternative, which most medium/ large organizations use is to have a complete board for each project. The board remains active as long as the project is active and simply closed when the project is done. This is better suited if you use an electronic Kanban board OR if you have a few long running projects. Otherwise, if you use physical boards, you will end up in a situation where all your team members will be forced to make updates on multiple boards in multiple locations, which would be a real challenge! Even in an electronic Kanban situation, this may not be advisable if most of your people work on more than 2 projects at a time. (Ignore the actual labels in the picture below!)

Of course, there are many options possible, including having some sort of a board hierarchy, where you might have a organization --> client --> project hierarchy of boards - some of which may be more easily doable with an electronic Kanban product if and when you are ready for it. (Electronic products will also provide you some cool things such as defining a standard set of tasks on a card for each workflow column - so that on a single card, you can define tasks and map them to social vs. development stages - and track them as the card moves from the left to the right side of the board.)

But, start with simple and then go on to more sophisticated as you adopt Kanban more effectively.

To your question about defining workflow stages as columns on the Kanban board or as labels on each work item, having the Kanban board allows you to visualize your workflow like no other tool. It then provides you a powerful information radiator of where (what stage of the development cycle) your overall body of work is, where there may be overloading, etc. So, if you use Kanban, the columns as workflow stages is the best option.

Hope this helps! If you have any questions/ clarifications, I'd be happy to answer here or you can also reach me at [email protected]. Cheers!

Answer 2

While this is a very complete answer from Mahesh, it looks to me as if the approaches are really a re-work of waterfall.

In Kanban, we should reduce WIP (work in progress) as much as possible. In the diagrams proposed, there is a huge amount of WIP - and this indicates one of two things:

1. The resources available are SUBSTANTIAL - and it is possible to work on all those items simultaneously, or
2. There is far too much WIP, and the process, therefore, isn't Kanban. (In Kanban, we only "pull" work that we have capacity to work on, and work on that exclusively until it is complete).

I would be very interested in Mahesh's views on this.

C.

Answer 3

Kanban is a great tool for making your workflow explicit. This will help you expose bottlenecks, eliminate waste and eventually change/optimize your workflow.

Usually organizations implement Kanban when 1 or more of the following are true or suspected of being a problem:

• There are too many pieces of work happening in parallel
• The org needs to take several specialists and get them to own a work product or process as a team, not as a bunch of individuals
• There are many competing work products
• Priorities frequently change

When you create your Kanban board the goal is to have the board reflect as closely as possible what your group does. Its beneficial to actually have the group of people that will use the Kanban board build it. This can help them take ownership as well as understand their processes. They should also agree on, set, and understand how WIP limits work and the basics of a pull system.