When is using a Kanban(-like) board with paper tickets okay?

Question

At some point our project manager (PM) switched to a Kanban-like board (we have "Open", "In progress", "Verification", "Feedback", "Analysis" and "Test" fields on the board; our project follows (I think) the V-model that is we do a lot of testing along with the implementation of features and bug fixing). Since I joined the team after this was introduced it's all I know from this project.

As time went by I found it more and more problematic to work with the way things are because:

• the client has their own ticket repository (Polarion from Siemens; no matter how many "awesome" features it offers it is, in my opinion, an incredibly broken/incomplete pile of junk)
• we have our own Redmine (digital tickets :)) and
• board with tickets on paper

The way things currently work are:

1. Client finds an issue and creates a ticket in Polarion
2. Our PM (or someone from the dev team) looks through the opened tickets

3. If a ticket suitable for us is found (that is, its category is Software), the following needs to be done:

   1. Create Redmine ticket
   2. Create paper ticket and hang it up on the board in "Open"

In addition we have two members of our team who work remotely which means that they have to "bother" someone to create the paper version of the ticket and manage it on the board in their stead. Our PM tries to do it but it's not working so well to be honest.

To add more to this we also have internal tickets that represent problems that our client hasn't found yet (might never do) that we keep away from Polarion since the client has no access to our Redmine. Posting a ticket number to a ticket that is not visible for the other party doesn't make much sense.

All this was bothering me at the very beginning (I like taking notes on paper but not managing that paper) but it became worse when we had a couple of big waves of tickets shipped from Polarion most of which weren't reproducible (hence had to be hung up in the "Feedback" category on the board and in Redmine). The more tickets we had on the board the more difficult it became to find anything. Me and my colleagues sometimes spend several minutes to find the given ticket (my personal record is approx. 10 minutes), which is not only a waste of time but as you probably imagine incredibly frustrating. If you are unlucky enough the ticket might not actually be present on paper because someone forgot to do it/was not able to (like the two colleagues who work remotely).

This stacking up of tickets with status "Feedback" led to the creation of a new process - we now have a separate from the board pile of tickets on paper that are not reproducible and require a different type of feedback (the normal "Feedback" in our project is when we require more information on the specification) - Dear client, please don't post a screenshot and say it doesn't work as expected while at the same time the screenshot is not even of our own software but of a third party tool that you use for the simulation of the system (and we don't have) or "Dear client, please read your own specification..." etc.

And of course we always have to work with the paper tickets too. I always create Redmine tickets when I find a bug, document everything and basically take care of the digital side of the ticket system. However sometimes I forget to create a paper version (it's not just me, happens to many others too) which annoys the hell out of the PM.

I'm interested in the general practice out there (I don't have much experience to be honest) when it comes to ticket management on paper. Is it suitable for big projects at all (we are 11 people and work for more than 2 years on this project; tickets on papers is something we have for a couple of months now)? When is it time to say enough with the paper and move to digital-only medium?

Answer 1

With (almost) any development practice whatsoever, whether or not the practice is acceptable depends on whether or not the Team finds said practice to be useful.

Consider gathering the Team together (on Skype if necessary for the remote workers) for a meeting, where you ask the following questions:

1. What are the intended benefits of using the board?
2. Is the board achieving its purpose?
3. If not, what can we do to change that? (Note: "It's impossible" is not a valid answer to this - There must be some way to achieve just about any purpose, outlandish and expensive though it may be)
4. Is it worth implementing those changes, or would it be more cost-effective to remove the board entirely?

If the answer to #4 is 'remove the board entirely', then your next step is to convince whoever has the power to make that decision - which, if it is your development team itself, means you're done.

Answer 2

Yes it looks like you are talking about a Kanban process rather than a "Scrum Like" one. But That's OK. Consider reading up on Kanban, I'd suggest "Kanban: Successful Evolutionary Change for Your Technology Business by David J. Anderson" as its very good.

I have used Paper cards for a large project, so I feel your pain. Yes syncing the digital world and the physical world is a time consuming and often futile task, especially when there are lots and lots of cards in flow. So consider WIP limits, it can reduce the number of cards in flight at any given time, and thus reduce the complexity of what your team is trying to do.

But at the end of the day ... living in a digital world (especially one where there are 2 versions) and a physical one is very difficult. If there is no visualization element to your existing tools then perhaps the compromise is to move to a tool that visualizes the board for you. (PM's PO's & the like Love to see the boards as it gives them great insights into how the team is getting along). Suggestions MS VSTS, JIRA or Leankit, I've used them all.

Failing that perhaps you can document as a team how much waste the current setup is causing in the hope that it might encourage the PM to rethink how they want to organize the team's workload.

I hope this helps Regards