Somebody mentioned that my design team had created a Trello board for themselves. Something to help them manage their workflow. I killed it.
That is my answer to Bart’s question “what do I do do when the designers want to have a task management system separate from the scrum/kanban board?” Don’t let them.
It is interesting that Bart specifically asked about designers and it was also my designers that had gone all Trello on me. But this isn’t really about that role, it is about any part of the team that wants to go their own way in terms of tools and process. If it is going to be detrimental to the them, then I don’t let them. In this case my problem was visibility. Or lack of.
A principle of Kanban is to “Visualize (the work, workflow and business risks)”. Information radiators are the best way to visualise the work and I’m a big fan of physical boards. They are in your face. You walk into the work space and you can see what is going on.
On the other hand electronic boards, like Trello, are hidden away. You have to go looking for them. And they lack the tactile benefits of physical cards. So they are a poor substitute for a physical board. There are times when an electronic board is a helpful, like with distributed teams, but this wasn’t one of them.
So I killed the electronic board and got the UX team to use the UX board. Yes, it is true, there was already a “UX and Requirements board”, one that was just upstream of the development board. Tickets flowed from one to the other.
Two things were really going on in this situation:
- The UX team wanted to manage their work within their team, away from the scrutiny of the wider team
- They didn’t like the columns on the physical board
I don’t have much patience for the first reason. Visibility all the way. They were welcome to control their own work, and hence change the columns on the physical board, but I insisted they managed their work in public.
It is only with this complete visibility that I, and others, can assess progress and spot blockers when they happen.
This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.
Hi Steven,
I agree with you. Everyone on the team needs to be aware of their place and responsibilities in the value chain. using big visible boards as you have suggested is a well proven way of achieving that. There should be nowhere to hide.
But I would imagine that designers have a keener aesthetic sensibility than the average developer. Why not engage with the UX guys on this and ask them to help in the design of the kanban boards. A kanban board is a user interface after all and they may have something positive to contribute to the design. If nothing else, you may help them understand why it is the way it is. This is a great opportunity for cross functional communication and collaboration. Thoughts?
Norman
Hi Norman. Yes agreed. In fact I did work with the UX team to rework the Kanban board for the design team.
I disagree with you.
When you ‘kill’ something like that you stop potential. Our UX team uses a physical board to keep us on track of the larger holistic view of the project and we have several digital boards, trello being one of them, that houses all the nitty gritty from process to flows.
We couldn’t imagine a life without either.
Nik, horses or courses.
In my example the wider team lacked sufficient visibility on what the UX team were working on. The Trello board would have made this worse, not better, as it came with a disengagement from the whole team board. That was the problem I reacted to. The team needed for visibility on, more engagement with, the big board.
I don’t particularly care what tools people use to manage the detail as long as there is sufficient visibility for the whole team to ensure the right work is done at the right time.
Steven
Respond dont react my friend :).
Trust me I responded to your post my reaction was very different. 🙂
Good point and good reminder. 🙂
I understand your concerns here but would encourage you to refrain from murdering your ux teams ideas. Had I read this post I would have ask you for clarification on what you feel your roll is. As a project manager I work for the team not the other way around. This is a service / facilitation position. It is my job to help them complete their goals.
Saying. “I killed it” sounds punishing and authoritative. You dropped the ball, and it is your job to make them happy again. Fundementally your teams needs were not being met by the present methodology you had in place. So where can you improve in recognizing team needs.
I am glad you eventually helped the team get their needs met. In the future just apologize for the oversight and focus on new ways to facilitate better communication with your ux pros.
John, it seems we agree on the concern and outcomes. The concern was a local optimisation that would undermine the overall process. The outcome was integrating the small team more effectively into the larger team.
Hi – this was an interesting read. Initially I thought “he’s so wrong”, but in your case, I think the decision to disallow a trello board was reasonable. Seems as though the only reason the team wanted it was to hide out.
But in many other cases – kanban boards do work for UX design, my team’s work being one example (and this post mentions the reasons for it: http://kanbantool.com/blog/kanban-for-ux-design. Perhaps the point is to match the way the agile method is used to the way the same methods are used throughout the company? It would not make sense for one dept. to do a physical board while others use digital.
All in all, I think going out and suggesting that a visual board will not work for ux team in general is unjustified.
Janice, I absolutely agree that Kanban works for UX. And if this team was a separate department doing separate work then I wouldn’t have cared what they did. Kanban, lean, agile, waterfall, whatever.
The context was a team of 3 UX+D people working within a much bigger team development team that was working on a single product. In that context, and from my perspective, the needs of the bigger team outweighed the needs/desires of the sub-team. The bigger team needed more visibility of the UX+D activity, a lot more visibility, hence getting the UX+D guys to put their work on the team board like everybody else. Happens to have been a physical board, but again the physical/electronic thing was secondary to the main goal.