Kanbanish visualization and workflow management for multi-project, multi-team department

Question

I'm trying to think of a simple (and agile in nature) way to visualize a large department's work and bottlenecks, with the idea of gradually improving the process once we have the necessary data.

The problem is that we have multiple groups of developers working on multiple projects. Some developers are cross-project and some projects are cross-team. Developers are very set in their ways (we don't want to force C# or Java developers to learn Delphi 6 during pair programming).

Another issue is that a very small QA team is shared between all developers/projects.

I need ideas for how to organize a Kanban (or similar) taskboard so that stories are categorized by project (or team?) but that the WIP limits are still applied across the board.

Also, how would the standup meetings go? Including everyone in a single meeting would take up too much time and result in information overload, but splitting the meeting makes us lose out on a lot of the transparency that agile enforces.

So, any ideas related to taskboards and standup meetings are welcome. Also, alternatives to Kanban with the same level of prescription as Kanban (in other words not much) are very welcome.

Answer 1

I'm trying to think of a simple (and agile in nature) way to visualize a large department's work and bottlenecks, with the idea of gradually improving the process once we have the necessary data.

Maybe not the expected answer but this is exactly what value stream mapping is for:

And this is where you should start.

Have a look at Mary Poppendieck material on this subject (e.g. this presentation, this one, or her books).

Answer 2

Corey Ladas over at Lean Software Engineering has a few articles on how to design a Kanban board for various workflows. I also highly recommend the kanbandev mailing list - the community is pretty mature, but searching through the archives should prove useful.

For standup meetings, keep in mind that Kanban does not prescribe the standard Scrum-style standup (What did you do yesterday, what did you do today, any blockages?). These can still be useful to do with smaller groups, but with a larger team (you never mention how large - 20? 200?) you can just focus on the blockages. What people are currently working on is visible for all on the board, and the next priority (i.e. What will I do next?) should be in some sort of "Ready" queue, which is pulled from according to your different classes of service.

Answer 3

In Agile projects, it's a common practice to visualize and share project status using charts or diagrams on boards. While no single document delivers all of the ammunition agile teams need to get the rhythm, this set of visual materials offers an easy framework to help guide software development teams through the various agile cycles.

A variation of the Kanban, an easy way to represent these cards, with some enhancements to this representation and a synchronized use of the concept, ArabiaGIS introduced the Sync Kanban concept.

The Sync Kanban is composed of a board for each project where the team leader or the responsible developer will try to represent the project status and the features progress with pies.

for complete description: http://www.jaftalks.com/Home/Show/Sync-Kanban-Agile-Project-Management

Regrads, Hasan Jaffal