Where to fit research/exploration work items into Kanban Board?

Question

I'd like to move toward Kanban-style project management, but I'm finding it especially hard for a project where some of the technology is new and the developers have to spend time researching modules developed by other people to see whether they'll work.

They often don't know how long the research will take, and sometimes it doesn't lead anywhere. The task may be as vague as "figure out how to get solr to index the content of Excel files like this", where this is a particular requirement, or "see whether there's a Drupal module that will help us do X." These work items don't seem to fit very well into the minimal-feature-type structure of Kanban.

So, where to fit the research or exploration related work items into our Kanban Board?

Answer 1

This is a good question... Not sure I have a good answer, but here ya go...

Can you adopt the concept of a timebox and goal/question to answer to help the research tasks complete and move the project forward?

You will never get the "best" answer" but spending a fixed amount of time for something like "see if there is existing code that will..." can help move it forward. Phrase it as "Decide to build from scratch or include a 3rd party library into the product to solve X, Y and Z" and give the activity 4 hours to make the call. Someone can grab the card, do the 4 hours of research and then make the decision. Once made, the next task should be to size the result of the decision (maybe that is included on the card? I've seen it both ways...)

Continuing the example... If you decide to build from scratch but don't know how to implements it, then similarly create a first task that is "create design sketch, 2 hours" Keep the timebox small and focus on moving to building something as soon as possible. If your team really doesn't know how to approach something, nothing teaches like experience.

Once you are progressing toward building and someone realizes "hey, I just read on Bob Loblow's Blog that there is already a solution to this..." then you can evaluate with the new information if it is cheaper/easier to switch or continue building from scratch.

So...

• There is never such a thing as the perfect answer
• Build something ASAP
• Change direction when you have new information that compels you to

But I'm interested to hear more thoughts!

Answer 2

A few of ideas which you may find useful:

• Don’t treat marketability of a feature as totally crucial thing. We sometimes add a feature which we know won’t be marketable but we still see some value in building it. In you case just pull your research tasks as any other tasks through the board. In other words treat research as a feature on its own.

• You may want to add a specific stage to show that specific feature/task is researched and not yet built. We actually did that with our board adding design stage — you can see more in one of my posts on Kanban board.

• If you decide after research that you don’t want to build the actual feature just call it completed and move into done column. You may want to mark it in a specific way so you know it hasn’t been built so you can filter it out when you analyze your cycle time/lead time or you verify what’s really been built.

And one final advice: don’t treat process described on Kanban board as a sacred cow. It should reflect how you work and not the other way round: the way you work should be a result of what you’ve scribbled on the board. If something doesn’t really suit the board decide whether it is just the example, and then treat it like one, or it might be a common situation so you might need to change your board.