A couple of weeks back, I met with a friend who works as project manager at an indie game studio. He told me how he is establishing scrum (which seems to be a hard-sell for clients, who want contractual, detailed outcome guarantees), and, how now all the companies value creation processes are modelled in Jira.
After a two minute exchange of opposing views on Jira – me: “Jira sucks”; him: “I love Jira” – my friend complained a bit about how team members f***ed up the Jira board with regularity.
He told me:
We need 50 Jira status. I told the team 20 times that they shouldn’t touch status. Good that Jira let’s me lock down access rights.
Whoa! What!? That is insane!
I went back and forth with him for a couple of minutes, trying to open him up for the perspective that this sounds like a horrible way to manage a team’s projects, to no avail. My friend knows the company, processes and projects intimately, and I don’t. He rightfully told me that I don’t know what I’m talking about.
Hypothesis on misusing Jira
My hypothesis were independent of his specific case, and I’m confident that they apply universally:
- If you have 50 status on one board, you are modelling your processes incorrectly.
- If you need to lock down the board to protect it from the very people who work on the project, you are failing the team.
The 50 status problem
- With 50 status there’s no way you can structure the board to be visually clear. Thereby you will be missing out on one of the top benefits of a tool like Jira.
- With 50 status there’s no way you ever will be able to teach everyone in the team to change them the same, consistent way in all cases. Heck, I doubt the project manager will be able to do that consistently “right”.
The trust problem
- What message is the team getting from a “you’re not allowed, no, actually you can’t change status of your own tasks”?
- If there’s just one person allowed to change things, you are introducing unnecessary bottlenecks. Just a longer lunch break of the project manager will introduce unnecessary waiting times of 30min per task. What’s going to happen if the project manager is sick or on vacation? No one will know or be able to do changes to the board, the project will either grant to a halt, or disconnect from the project management tool!
A sane proposal
So if 50 status can’t ever practically work for a big team, but you need all of them, what do you do?
Easy: you split up the complexity into manageable chunks.
It’s likely that you already have sub-teams who each work on a sub-set of the project. Create a separate board for every sub-team. You’ll find that every sub-team will likely not be involved in more than 10 status – a small enough sub-set that proper board usage can be taught to everyone. The project manager can have a “master” board with everything on it.
- Team members can update the status the very moment they made progress on a task. Incorrect status transitions can still be prevented with status rules but are, in my experience, not required.
- Team members are not overwhelmed with seeing all of the project. Most times they only need to see their piece of the pie.
- There’s no dependency on the 1 project management master. The team is a little bit more empowered.
I do not believe that there’s any project or use-case, where it can’t be avoided to run into the two mentioned mis-uses of Jira. I’m interested in being proven wrong though.