11–20 of 78 posts
That may be part of your problem right there. I'm sure your team is very good, but do you really think you are 10X better? It seems unlikely.
That being said, I think you’d be facing an impossible fight.
No developer loves these tools, and as a manager you hear complaints about almost everything imaginable, and if you have jira, and you think it’s working for you, then it’ll be hard to change your mind.
Leading upwards is really challenging, because you’ll need to show the financial cost of using jira and present an alternative as well as a plan and a budget for how to get there if you want to convince your manager, and you’re probably not paid to do that.
This is how introducing Jira goes in a typical enterprise:
There's process, lots of it. There's training, scrum masters and Agile trainers flood the office floors. You can't move a task from in progress to done, because you didn't push the ticket through QA, QA Accepted, In Review, UAT and Waiting to be Deployed phases.
6 months later the Agile trainers are gone and sanity prevails and all the processes that don't make sense are quietly rolled back.
Thankfully you can configure Jira to do pretty much whatever you want, even the absolute minimum required to keep the dashboards management sees pretty.
> We've demonstrated times and times again that our development processes and our talent was order of magnitude superior to their existing dev teams. That may be part of your problem right there. I'm sure your team is very good, but do you really think you are 10X better? It seems unlikely.
"Their motivation is to be able to track what the dev team is doing and keep a log of the activities, with the end goal being to be able to qualify this work as Capex."
So if you really don't want JIRA then offer an alternative that will meet those requirements.
Management may still say "just use JIRA". Before pushing back on this have a think about the cost/benefit ratio and whether this is really a battle worth fighting. You may lose credit with management, and more importantly, life is short. Arguing over issue systems is a stupid thing to spend your life on unless it's really going to save you a lot of time/frustration down the line. All in all, I would say it's unlikely that it's worth it.
I and most of us at Atlassian believe that epowering developers with more autonomy will drive better outcomes, better products, and better teams.
To help resolve these conflict, aspects of Jira needed to change and team culture needs to change.
To fix this we've been investing to democratize Jira's permissions model. We have been focusing on autonomy and flexibility to let any team design the way they want to work while giving administrators the power they need.
The SW biz is a very fast-growing space. When you combine massive growth, speed, and impact it is easy to lose control.
Feeling like you need tighter control means people often try to grip tighter. Sometimes that shows up in insanely complex and structured Jira instances. Sometimes Agile has become more important than agility. Sometimes using Jira has become more important to leaders than the outcomes the actual customer wants. This shouldn't be the case.
It can become easy to over-index on process and control at the expense of agility and software team autonomy. Don't do it!
This results in some over-designed Jira boards and workflows.
Leaders and managers in business and software development need to balance the desire for control with the need for S/W team autonomy. This endless dance between autonomy and control always shows up in every HN thread with detractors saying Jira sucks and fans saying Jira is great but the people setting it up must suck.
There is responsibility all around. Jira, for example, needed to improve the permission model to better empower teams with project level controls. We've needed to simplify the setup and clean up the issue views. These changes in Jira Cloud help admins feel more comfortable delegating more control to teams to design their own way of working.
We can't police how people use Jira in the wild but we can share our POV, our playbooks and we can make changes to the product to make it less likely that managers treat dev teams like factory labor focused on process and efficiency above all else.
A well-running team in a well designed Jira instance should work more like a lab than a factory.
Triads or squads should be able to chase a hypothesis, they should be better able to adapt to new information and respond to change than a factory assembly line. Leaders should be looking for more than process and efficiency out of the team and out of Jira.
How should you handle this?
Make Jira work for you.
Play a role in designing the way you want your team to work. Take the lead in changing the board design or the workflows when your work requires it.
The teams that make adapting to change their competitive advantage make the biggest impact on their company, their customers and the world. But, it takes trust and courage for leaders to create the conditions necessary for this. It means giving software teams a degree of autonomy and flexibility. Mastering this is the core competitive advantage for innovative companies today. These companies retain great talent, they hire great talent, they get great results.
Over the years we've heard the wishlist from Jira users and administrators in large companies and startups.
Make it easier to use and get started!
Give me flexibility and control when I need it!
Let my team design their own way of working!
To bring a new level of simplicity and power to Jira we needed to re-think the basics of the product. We also decided to open up and share our practices to go along with our tools (Team Playbooks https://www.atlassian.com/team-playbook). We needed to learn a few things from the Trello team. We needed to think deeper than new features. The good news is that we've been doing that in a big way and you should be seeing that in the Jira Cloud product you can try today.
A couple examples
Project Level Permissions- Have you ever felt like the Jira you are using was designed for some other team or project? Alert! It might have been. Jira SW Cloud now makes it easy for next-gen project owners and team leads to design their own Jira projects, boards, and custom issue types without creating concerns that it will impact other projects.
Agile features can be turned on and off with the click of a button, so your team can customize to best suit its own unique workflow depending on its maturity level and the project at hand. For example, you can now flip between scrum and kanban methodologies in seconds
You can create issues and columns in-line, without ever leaving the board
Out-of-the-box team filters on every board, such as epic, issue owner, or labels make it easy for anyone to sort and filter in a click, no JQL needed.
You can define a rule to automatically update an issue's field or assignee based on the column it is moved into
You can display issue attachments as card cover images on the board
You can create, edit and delete issue types in independent projects
You can create issue types and customize the fields to suit your team's needs
We've got a lot more coming. The good news is that you can customize, modify, adapt and design Jira Cloud to do pretty much anything you want. The bad news is that means someone who doesn't know what you mean might do it for you if you don't participate.
Building software is complicated work. Jira's secret sauce is the way it simplifies the complexities of software development into manageable units of work that can be predictably shared and worked on by many different teams at the same time. Well designed Jira boards and Jira issues enable collaboration across increasingly diverse software teams that include design, marketing, analytics etc.(via integrations to the Jira issue)
That's a lot of text for a really small text box in HN. I'm trying to stay awake long enough to see the end of the Red Sox game. It's longer than that the typical bit of snark about Jira sucking or your admin sucking or doing work at work....sucking.
My advice:
You can have admin or project admin permissions, you can design the way your teams wants to work, you can integrate the tools like GH, BB, INvision, New Relic, Launch Darkly, etc that your team uses already. You can give the managers the vis they want and need and you can do it without sacrificing the sanity of your team day to day. And, you can use Jira to show whoever needs to know what you've been doing and how it impacts the business.
Jira should feel like the center of gravity that helps all the work your teams are doing hang together across different teams and tools.
> We've demonstrated times and times again that our development processes and our talent was order of magnitude superior to their existing dev teams. That may be part of your problem right there. I'm sure your team is very good, but do you really think you are 10X better? It seems unlikely.
Order of magnitude (base 2)?
But seriously, even when I've only thought I was twice as good as someone else (and I'm afraid I have thought that too many times), it usually hasn't ended well.
Truth is you might be so good because you’re not at scale, they may be looking to scale you up which is great... you just have to get them the numbers.
Jira as a tool sucks dicks for pennies (trust me i’ve seen it)
Jira is however customisable as fuck, so if you’re being forced into it then get admin! Stick to a simple workflow, basic practices. Jira falls short with the amount of munging people do to it, at the minute my team has a 9 column board with 5+ projects on it... that’s not how it’s meant to be done and it drags time out of my day.
So by all means if you’re tracking already, demonstrate that (as long as it’s not a damn spreadsheet). If you can’t get them what they need then question why Jira. If you have to use it then get admin and make the tool work for your current process.