Dev team's role in configuring Jira

Question

Let me start by explaining the big, unfixable problem here:

A new Technology Director has been brought in above my team, and he insists on deciding how Jira is configured, affecting people who don't report to him. Despite his insistence to the contrary, he doesn't seem to have the slightest idea how agile or Scrum works, but the rest of the team is very comfortable with these things. He doesn't understand what goes into a standup, and when we forced a retrospective recently, he stared at his laptop the 90 percent of time. This (and his apparent confusing of waterfall and agile) is causing very real problems.

He's a talented programmer, but also kind of a jerk and an inscrutable communicator. He leads by fiat, not by example. It's so bad that I've already decided that I'm leaving (I'm expecting an offer in the next two days), and our senior front-end developer quit right after we hired a very junior front-ender who really needed his mentoring.

Now, to my more narrowly-scoped question

Should someone in this role have a major say in this sort of thing? The way he wants to configure Jira makes no sense to anybody else. How can I push back and advocate for agile and Scrum?

I'm trying to fix as much of this as possible before I leave because I do like the company and I really care about the team and I want to see them succeed.

Any advice on how to help me help my team before I leave would be appreciated.

Answer 1

Target the goal(s), not the path.

Jira is a tool like any other. Way too often I see people concerned about keeping Jira organized, forgetting that, as any other tool, Jira should be a mean to a proper goal or result.

Take a step back: think why are you guy using Jira at all? List the top 3 reasons. As him (or even better, everyone using Jira if you want to have a more consistent view). Are the answers the same? Are the goals of Jira usage the same? Maybe your manager is asking for a specific usage because he envisage some specific reports that cannot be obtained using Jira as-is. Maybe he has a waterfall-oriented view and is expecting to have Due Dates from Jira. The bottomline here is that, if there's a conflict on Jira usage, is because people have different expectations on Jira. When discussing about it, try to avoid naming Jira at all.

Examples:

• as a developer, I need to know what are the top priority work we have
• as a developer, I need to know how many activities I have depending on me
• as a manager, I need to know how much work accumulated (yeah, I avoided using the word 'backlog' on purpose) my team has
• as a manager, I need to know where most of the team's effort is going
• as a manager, I need to know how much work we'll be delivering next year (spoiler alert: unless your company is very mature, Jira won't answer that!)
• as a user, I need to know when my request is going to be completed
• as a tester, I need to know the developers I have to talk to when questions arise

Now, setup the plan to reach the goals: So long everyone is on the same page on what Jira can (and most importantly, can not!), propose some plans on how to reach the objectives. If there are clashes on objectives, then priorities need to be set (and alternatives discussed). Let's say, if the manager needs to know the 1y delivery plan, saying "Jira won't have it, suck it up" won't help. Alternatives should be discussed. Likewise, if the agreed approach doesn't help the team, the team needs to agree how to address the goals (up to have 'layers' of Jira usage, for instance... for Example managers using Epics as they want and the team using Task / Stories).

Answer 2

For your first question: JIRA is a stand-in for the taskboard, which is a tool for the team to visualize and organize their work and for stakeholders to quickly see how things are progressing. For the most part, that means it is for the team to decide how it is used. The big exception I'd see to this would be that it is not unreasonable for a stakeholder to make a request about the configuration for them to get better visibility into the status of the sprint and the work if it doesn't impact the team too much.

For your second question, that's a tough one. It really comes down to why they are doing it. For many people, the intent is good - they think they're helping. Maybe what they are doing worked somewhere else and they assume it'll work there. Or, maybe he actually does have a better way of doing things, but since he's just forcing it, you get all of the disruption of the change, but can't see any benefit. For these people you can usually show them the impact they're having and ask them to slow down and go through some experimental changes with the team, asking them to offer suggestions to problems the team is struggling with and you can try those suggestions before making them permanent. The changes that actually are better will make sense and the changes that don't fit will fall by the wayside.

On rare occasions, I run into people that do this without good intentions. They've somehow learned along their career that they should control other people's actions and that's how they know they're an important leader. These people can change, but it's a long road. Usually, it's easier just to get out of their damage area.

Answer 3

The simple point to take away is that if you are leaving then the best thing you can do for your team is almost certainly nothing. By trying to 'fix' stuff all you can achieve is upsetting your colleagues who don't like the implicit conflict that will arise.

I'm trying to fix as much of this as possible before I leave because I do like the company and I really care about the team and I want to see them succeed.

New people rarely do things out of some kind of Hollywood-villain enjoyment of evil. Perhaps the new tech director has been promoted out of his comfort zone, maybe he has shock exaggerated his experience. It doesn't matter, you are moving on.

Focus on making sure that your tasks are complete & that your projects are running smoothly when you come to leave. That's how you can best serve your team.