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?

  • The edit helps(although the title still needs an edit). The resulting question is too broad and doesn't identify a practical project management problem. The core seems to be, "We want to communicate with one another". I'd have to ask what is stopping you? How will you know when you are successfully communicating with one another?
    – MCW
    Commented Aug 22, 2014 at 11:26
  • @MarkC.Wallace, I edited the title to match the body. Good idea!
    – jmort253
    Commented Aug 23, 2014 at 2:33
  • Hi kostas, if you can edit your post to address Mark's clarifying questions, this will bump your post into a reopen review queue where users with 500+ reputation can vote to reopen. Hope this helps!
    – jmort253
    Commented Aug 23, 2014 at 2:34
  • 1
    Hey guys, can you please review my question?
    – kbariotis
    Commented Aug 28, 2014 at 10:22
  • 2
    @kostaskostarelo In its original form, this wasn't a good fit for our site, but your edits and the helpful edits of our community members fixed the problems. Thank you for making this a good, on-topic question for our site. I'll reopen for more answers.
    – jmort253
    Commented Aug 29, 2014 at 5:20

3 Answers 3


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.

enter image description here

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.

enter image description here

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!)

enter image description here

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!

  • 1
    You rock @maheshsingh. You deserve the answer. :) What about the different departments of ours. They don't have the same workflows. Can they exists on the same board?
    – kbariotis
    Commented Sep 12, 2014 at 16:13
  • 3
    Thanks @kostas - glad it is useful. Yes, different departments could have their own swim-lanes, with different workflows easily, as long as the overall board does not become too large/ difficult to manage. Also, it depends on whether you use a physical or an electronic board :-) The physical board will require some coordination for different departments to hold daily standup meetings at different time slots so each is able to do it effectively! Apologies for the delayed response - my notifications on this don't seem to work too well :( All the best! Commented Sep 16, 2014 at 1:46
  • @fnt - thanks for pointing it out - I have fixed it. Commented Mar 25, 2017 at 11:21

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.


  • I assumed his point was to map the current workflow state as accurately as possible rather than to start with a more idealized flow (most kanban proponents seem to prefer the former). It would make spotting immediate problems easier; in this case, I am guessing it would be the delays and info loss/alignment problems around the hand-offs. :) Commented Dec 10, 2015 at 16:14
  • Please be careful not to create a discussion in answers. SE should not be a discussion site - each answer should stand independent, address the question and only the question. Obviously we bend the rules slightly here and there, but we should avoid things that take us too far from this goal.
    – MCW
    Commented Dec 10, 2015 at 19:04

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.

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.