Best Practices for Kanboard Usage


#1

I wanted to see if others might be able to share some of their best practices for using Kanboard in a mixed organization with different departments (not just IT/software development) making use of the tool?

I’ve been running a long-term “test” you could say with Kanboard for almost 3 years now.

Originally, I started off with a single board for our IT department as a whole, and eventually created swimlanes for our subareas within IT: one for our Application Services, one for our Network/System Admin Services, one for our Computer Techs, and one for Online Services.

After a little while under this model (which I thought was kind of nice, since it had all of our IT work in a single location), I was asked to see if I could split those swimlanes off into individual Kanboard Projects (partially to aid in configurability since as swimlanes each area was stuck with the general settings/columns/etc. for the project and couldn’t tweak things much).

This initially lost some visibility about what was going on, but I ended up enabling notifications for myself in the other projects so that I could still have an idea of what else was going on.

For the most part though, I was pretty much the primary user of Kanboard within our department keeping track of Online Services related items. The other IT areas have used it somewhat, but overall it’s pretty minimal in comparison.

The drawback of separating things out into individual projects though does make it easier to provide an aggregate “What’s Going On?” sort of view for higher ups, and that’s an area where I feel Kanboard is pretty weak right now and is also part of the reason for: [feature-request] Can Projects Be Organized Into Categories? but even with such a feature additional views would need to be added that provide the aggregate views. Currently, achieving this would likely require an external report to be generated from the Kanboard database since if I remember a past experiment with the API, I don’t think I was able to pull in the needed info to create the report I was envisioning at the time (this was sometime last year).

My CTO was pretty excited about the Gantt chart capability, but the output hasn’t been super useful since we’re not making use of Start / End Dates on most tasks (plus he was more interested in being able to see Milestones and Subtasks too…but the Gantt view just shows the task names only).

After switching to the individual boards for each IT area, even though it wasn’t as centralized as the initial single board for all of IT, it seemed like it was a nice straightforward way to keep track of all of tasks over a long period of time (in other words, this would be a project without an end date since I wasn’t planning on creating additional projects in Kanboard for myself for each bigger “project” type task that came in…those would simply end up being normal tasks with additional subtasks created inside of them). To me, this felt more logical since I felt that creating a lot of extra projects would end up cluttering up things (or if I had multiple projects going on at once, that would mean switching between boards frequently, where I’d prefer being able to just use one board most of the time).

Even though that was my approach (sticking with one board for my work) my CTO was interested in the idea of creating multiple projects so the Network/System Admin folks did that for a bit, but it’s been a while since they’ve posted anything new.

At a higher organizational level, I’d love to introduce Kanban to the rest of our organization, since I have a feeling it can be useful in other areas, but at the moment it’s unclear to me which approach is going to be best to go with overall…although right now I’d lean towards keeping things to one project per department to simplify the overall management and currently I’d handle aggregating those departments up a level manually once I spend some time working on that piece.

The other part I struggle with is how difficult it’s been to just get my own fellow IT colleagues to get on board with using the tool since I don’t manage the other staff directly so at this point I feel like if we’re not truly using it successfully within IT as a whole…how can I promote it to other departments?

There might be some other open source Kanban tools out there, but Kanboard is still the only PHP-based one I think that’s pretty full featured (and up my alley to keep up to date and manage), but it would be nice to build up some best practices around using Kanboard specifically across an organization (even though Kanban is super flexible, it’d be nice to have concrete examples of how others have utilized the tool in different types of departments that could be used as sources of inspiration or best practices).


#2

Hi,
I am also in the process of rolling it out, also across departments, in and out of IT.
I started by delivering a workshop on Kanban principles, which made it very clear that it works for any kind of knowledge work.
So far, it seems to be helping.
About best practices in using Kanboard, still figuring it out myself.
One tip: We are using some consistent tags to identify the “Owner” of a task, so these people can search all tasks for which they are “Product Owner” across the whole Kanboard system. This also helps the people taking care of the task, so they know who to contact. This helps to replace the “Follow” function of Trello, which we miss.


#3

So I use JIRA at work, and Kanboard for all of my other projects and teams. I have some experience with collaboration and some with theoretical workflows. Your question seems to be more about processes than tooling, so I’ll give it a go.

Boards can be created using one of two overall philosophies:

  1. Per Team
  2. Per Project

Speaking specifically to Kanboard, per team makes most sense. This is as opposed to JIRA, where tasks are simply represented on a board, where a board is a view of the tasks. However, in Kanboard, tasks are unique to a single board.

This is important in the day-to-day usage of the boards by your team(s). Since people are lazy (you should most likely know this by now) it’s important that they have a simple “visual representation of work”. Having boards per-project both (somewhat) arbitrarily splits up work and splits up the locations where work is visually represented. As you noted above though, this increases the day-to-day visibility as other teams can see each other’s work. On the other extreme, one single giant board gets cluttered too easily and becomes a “we’re doing agile” checkbox for management, with none of the benefits. From personal experience, we had gigantic board with a daily standup that stagnated because all of the teams were too scared to actually make changes to “The Board”. It became holy.

The benefits of a per-team board not only gives the managers of the teams a good view, but also allows for functional swimlanes - my favorite being the IT Operations Master Board model on a per-team basis. It can also give a personal touch to the board, where people aren’t afraid to make mistakes (aka actually do things). Once your team has a stupidly-simple way of understanding a board (they are lazy, remember?) you have to refine the way in which they work with tasks. In this case they are the clients. And the clients are always right, no matter how wrong they are (within the boundaries set above). Of course, if you have a separate time reporting system, and separate ticketing system, etc., you run the risk of Kanboard succumbing to “just one more system” symptom. IT loves to have a “single pane of glass”, so if you can sell it like that, you might get their attention.

However, keep in mind that you’re not going to win everyone. At some point, you might need to mandate its usage for the basic things. This is the shitty part of implementing a system that is so obviously beneficial, since it may not be immediately obvious how it can fit into different peoples’ preferred workflows. There are always those whose brain “doesn’t work that way”. And it’s up to them to figure out that its in their best interest. All you can do is relentlessly lead them towards that realization.

Feel free to let me know if you want me to expand on any of these points, and good luck on your implementation!


#4

Thank you both @UrkoMPT and @smacz42 for replying to my post and sharing your thoughts (particularly @smacz42’s detailed reply which was exactly what I was hoping to receive when starting this thread).

That does kind of help me since it helps to reaffirm my more recent thoughts about having something that’s team based rather than per project, but as you mentioned the real hard part is all of the communication/convincing that may need to occur to get everyone on board and using such a system.

I started the first step in that direction though earlier this week by sharing some details related to Kanban with some other higher ups in the organization that may help to get some additional support outside of our own department so I’m hopeful I might start to get some traction in the near future.

I need to spend some time to setup some Team Projects for others on campus ahead of time I think next to help kickstart things (I was originally giving all of our staff the ability to create their own projects but took that away last week so as to avoid that issue of people creating too many projects and therefore keep them to their own Team Projects instead moving forward).


#5

Some other notes…on our end we do have a help desk powered by Web Help Desk used by our Technicians and some of our System Analysts to receive requests submitted by our users. One thing that has been challenging has been trying to think of a potential way to link up the ticketing system with Kanboard so that the techs could look at their tickets in Kanboard as a starting step but I haven’t spent a lot of time trying to come up with a solution for that.

However, lots of our staff areas currently do not have any sort of ticketing system (since not everyone is in there to receive tickets) so I feel like having Kanboard available would help them to keep things on track / organized / etc.