Five things I realised when I made the leap from JIRA to a whiteboard
I started at my current workplace just a few months ago, and of all the things I’ve spoken about, it’s my views on JIRA and whiteboards that have probably raised most eyebrows. Don’t get me wrong, I think that JIRA is a fantastic tool and my career so far wouldn’t have gone as smoothly had it not been for it (and other similar tools). But that’s all JIRA is — a tool. It shouldn’t dictate how you work but rather aid you in how you want to work. I am a huge advocate of JIRA being used as an information store for your requirements and holding a backlog of tickets. But for managing flow of work from the business to your developers and out to live? Give me a whiteboard, everyday.
Why? Well, to stop this post from being too long, here’s 5 reasons.
tl;dr — the use of a whiteboard makes it easier to adapt your board so it serves the whole team, not just Product and Project Managers. In return, you are rewarded with more visibility, easier management of flow of work and a team where conversations are valued and preferred over big JIRA tickets.
1. Adding tickets to a white board is easier than adding to a JIRA board
As I started using a whiteboard, the first thing which struck me was that there was next to zero ceremony when add tickets to the board. At standup, or at any point in the day if needed, anyone on the team would pick up a post-it note or index card, scribble the a few words to describe the issue/task and stick it on the appropriate column on the board. Voila — ticket created and work instantly made visible. Often, the few words on the card was enough to understand the ticket — e.g. “Sign in and Register buttons misaligned on iPhone 5”. But the short descriptions would encourage the various roles in the team — test, engineering and Product — to actually talk to each other and figure out the work. Where there was more detail required (such as ‘Given-When-Then’ scenarios, test instructions, UI designs etc.) a JIRA ticket would be created on the back of it, but the overarching rule was to make the work visible in order to promote a conversation at some point in the future. And if after the conversation the team decided the ticket wasn’t valuable enough to do, then the post-it note was simply thrown away. It was normal to see different handwriting on most tickets, showing that everyone felt comfortable with this process.
In comparison, writing information in JIRA from the outset was more daunting. Words typed here were treated as gospel, meaning creating a ticket quickly wasn’t possible — as the ‘Reporter’ you had to make sure you had the detail down properly, the edge cases covered, applied the correct components and labels. Sure we had some templates, but this was yet another step (read: blocker) to recording a particular bug/task. Given the amount of effort, it’s easier to just not bother creating a ticket for your wonderful idea and just carry on with your current task — this situation is surely to the detriment of the team overall.
This isn’t to say that JIRA tickets are not useful. Once the paper ticket was discussed, if there was agreement that the ticket was worth doing, then we would create a ‘proper’ JIRA ticket and add the detail which has been discussed. Not only did this cut a lost of waste (only work agreed upon would get a JIRA ticket), there was an instant shared understanding and so when the ticket was picked up, it was available to be started on immediately, with little additional detail needed. But despite the JIRA ticket being created, it was still the paper ticket which was used on the board, and taken from ‘Next’ through to ‘Done’.
2. It’s not just tickets which get added to the board
Whereas a JIRA board is often owned by a Delivery/Product type, a whiteboard can really, truly, feel like it’s owned by the team. Developers walk up to it, pick up new tickets when they’re done with theirs, and will happily scribble annotations directly on the board. Some will be attention grabbing (“BLOCKED DUE TO JENKINS”), others will be more subtle (“Check approach with tech architect before starting this”) and others will be funny (a scribble over a ticket so it reads “Add to Fart” instead of add to “Cart”). All these are real examples I’ve seen and for me prove one thing — the team interacts and owns the whiteboard in a way they never would with a JIRA board. That tangible feeling of the index card, scribbling down a bug or issue which truly matters to you, and seeing this move across the board is a charm which is hard to resist. And if you need further convincing, try to remember the last time anyone actually enjoyed using one of your JIRA boards.
3. Management of sub-tasks
Given then that sub-tasks are written by the engineering team for the engineering team, one would ask — why bother creating JIRA sub-tasks at all? It’s inconvenient for the developers to do this, even worse if a Product Owner does it (it’s not a Product ticket and the PO will need handholding by the developer for this ticket anyway) and all these sub-tasks would just clutter your view of the stories which need to be done.
So that leaves other options. How about leaving the developers alone to discuss it over Slack? Or if you’re the sole developer tackling the story, have a list of to-do’s on a notepad next to you? Or even more efficiently, just hold all the sub-tasks in your head — after all, no one else needs to know, right?
Unfortunately, nearly all of these options are quite terrible as it means the actual work isn’t visible. You would end up with one story ticket stuck in your board for ages, with no idea why it isn’t progressing. A board which developers are comfortable to add items to, which can have notes and annotations added to it with zero repercussions and can be changed in a matter of minutes, ends up being perfect for visualising work which would normally be hidden. This is good news as you and the team are aware of exactly what is needed before that story is ‘Done’, but without needing JIRA. For stakeholder management, this is perfect as it allows you to focus on the user value you want to deliver.
4. Control WIP per person and per column
The most eye opening feature of a board for me was possibly the simplest one to execute. By giving every member of the team a physical avatar such as a magnet, you can easily see when someone is working on more than one ticket. No one can work on more than one ticket effectively, so using the board can help easily identify and tackle this. This kind of behaviour is particularly prevalent in teams where the senior members of the staff are asked to do more of the heavy lifting, which in reality just means they get more tickets at any one time.
It can also help identify when a column is swelling with too many tickets — this mostly might happen in the ‘In QA’ column, but can easily affect other columns too. There could be a bunch of tickets in ‘Backlog’ or ‘Next’ showing you the queues which are forming, or even in ‘Ready for Deployment’, making it clear that your next deployment is likely to be a risky one.
As this is so visible to everyone, you can discuss ways to alleviate the problems here. You might decide to run experiments around more frequent deployments, or even enact policies which lighten the load on the QA function in your team — for example, you might allow non-testers to QA the simpler tickets such as less severe bugs. The point here is that by making all this visible, you are opening the opportunity to discuss how you can improve your process and make life a little better for everyone.
5. Promotes collaboration
The board is a natural place around which to run your stand-ups, but over time I found that it becomes synonymous with nearly any team discussion. Whenever an issue needs some face-to-face discussion, going to the board is seen as a better alternative than just door-stepping someone at their desk or hitting them with a stream of Slack messages.
Nearly anything a team may need to discuss, from clearing up ambiguous requirements on a ticket to making more dramatic decisions like go/no-go calls end up happening around the board. And the fact that these discussions happen in view of the team rather than behind closed doors, leads to an openness in the team which JIRA just can’t provide.
But following on from my first point, it’s not only developers and QA who can easily create tickets. Product Owners too can add tickets easily to the board, safe in the knowledge that everyone on the team knows that a ticket is only a placeholder for a conversation which needs to be had. In a JIRA-led team however, the tendency is for Product Owners to make perfect JIRA Story tickets, to cover every edge case and every requirement themselves, in such a way that a developer would be able to pick it up and complete it without further conversation. And if this is what the team values, then it’s no better from the upfront specification and analysis phases espoused by Waterfall.
The saying goes: “guns don’t kill people, people do”. Whilst this is true, it’s also undoubtedly true that guns make killing a lot easier. I believe something similar can be said for JIRA. “JIRA doesn’t cause bad practices, bad culture does”… but without proper care, JIRA can help enable and promote these bad practices very easily.
With this in mind, it’s disheartening to see just how pervasive JIRA has become with the idea of “doing Agile”, to the point that many simply teams cannot foresee adopting Agile methodologies without having a JIRA board.
When you consider that one of the Agile principles is “Individuals and interactions over processes and tools”, JIRA manages to fool people into thinking they no longer need conversations — “What do you mean you can’t just do it? But I wrote the ticket with the user story and acceptance criteria, and even attached the UX.”
And countless times I’ve seen Product Owners using bizarre JIRA red-tape to avoid having tickets added to their backlog — “Go to our Confluence space, there’s a link there for the JIRA template you need, fill that out fully, exactly what you want, full business value, steps for how you see it working with UI already considered and pre-approved sign off from Marketing. And then we’ll review it and see when we can do it.” This kind of approach perhaps says more about weak product ownership than it does about JIRA, but JIRA can certainly help promote such ways of working.
At it’s worst, JIRA turns perfectly competent Product Owners into Frankenstein-esque ticket creation machines, managing the monsters their projects have become as more and more bugs and tech tasks reveal themselves throughout development. And the worst thing is? Some Product Owners seem to like this. It gives the illusion of control — “if I can create tickets at the pace the team is discovering the issues and technical tasks, then I’m in control, right?” Unfortunately not. At this point, you’re not managing a product or any real development, you’re managing JIRA, a world in which Labels, Components and Fix Versions rule the roost.
A whiteboard isn’t perfect (of course it isn’t) but it helps avoid some of the anti-Agile behaviours so common in teams because it makes us to speak to each other, and forces to make our work visible. So how best to make the jump to using a whiteboard? Well this warrants another post to do it proper justice — I’ve not even discussed how you would manage work through to ‘Done’ or collect team metrics — but if I had to give any advice it would be to JFDI.