Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Very Popular

    Jira harder to control - Jira projects slowly becoming less collaborative.

    Jimi Wikman

    In the last few years, Jira have moved more and more towards JIRA project isolation. This is causing problems for companies that are working collaborative across multiple JIRA projects, and it is becoming increasingly difficult to use because of that. In a short period of time boards have become almost unusable where cross-linking projects cause things like roadmaps and scrum boards to stop working. This is a mindset issue, as well as an architectural one.

    It is clear that Atlassian's tools are focusing on an Agile mindset, focusing on Scrum and Kanban. This has always been the case, but it has never really prevented anyone for using their tools in a more traditional way as well. In recent years however this has changed and with the introduction of team managed projects this has taking a turn for the worse.

    With the introduction of team managed products, we have seen product development becomes increasingly fragmented and teams within Atlassian seem more and more isolated. This is typical for organizations working with Agile teams, and we also see this in the new products that are more MVPs than full-fledged applications. This fragmented way of working seem to cause not just alignment issues between the different Atlassian products, but it also seems to affect the architecture as well.

     

    The architecture is all over the place...

    If we look at the very basic architecture, we have "projects", which is the highest level of grouping data. This is what we have configuration for, like what issue types, workflows and custom fields we have for that set of data. Projects are divided between Team Managed and Company Managed types, where team managed are unique and isolated projects where anything goes and company managed are controlled and globally defined projects.

    On top of this, we add a board, which is a visual representation of a filter in either a Kanban or Scrum view. This is not something that I would consider "optional" because a project without a board is pretty useless. The boards are divided into four areas:

    1. Roadmap - Featureless Gantt using Epics that only work with data from one project.
    2. Backlog - Basic list with priority and iterations/status for selecting items to work on. Scrum features stop working if you add generic fields to bring in with a specific project attached to it. There is a hard limit of 5000 issues that will actually shut the backlog down if you hit it.
    3. Active sprints - Basic column based structure that you map statuses in the workflow to. Hard limit of 500 subtasks that will shut down this feature if you hit it.
    4. Reports - Basic reports for different purposes.

    As boards are defined based on a filter and filters can include any data from any project and since it is placed on top of a project you would assume that the data would be presented within the configuration of the project. Strangely, it does not because boards actually override project configurations and allow for customizations, even on Company Managed projects.

    This makes little sense, since the purpose of having a company managed setup in the first place is to ensure that the setups are the same. If each project can define their own views and configuration of estimates, for example, then what exactly is company managed?

    Things like that data from multiple projects can cause problems, like the roadmap being able to change from multiple projects is easily managed by adding permissions for who can and can not change things. A simple check to determine origin project and then who have permissions to make different changes in that project already exist, but it is not used in the roadmap.

    Disabling whole boards because of generic queries like "Related System[Dropdown]" = Jira" for the simple reason that it is not specific in terms of what project the issue belong to is a decision I do not understand. Sure, it can add overhead to the query if there are a lot of issues and a ton of customization, but that is solved by having a cache for every board that you check delta for on load instead of dynamically load all items. You also only load data for the listing and then fetch additional data on request.

    The limit of 5000 issues in a backlog is not just stupid, it is borderline illegal as it is an unknown limitation that cause denial of service. What makes this worse is that this limit does not just count the issues, but subtasks as well. This makes no sense in a Scrum board where subtasks never show up, and for a Kanban you should be able to turn this off in the settings.

    The Atlassian Agile Attitude

    This attitude towards technical architecture is not really surprising considering Atlassian is very open about their culture and how they approach things. Atlassian is very dedicated to Agile and especially Scrum, and that bleeds into everything they do. When asked about these problems, the response has been that Agile teams don't need to collaborate as they are empowered and self-organizing. Having a 5000 issues cap is not a problem for Atlassian because an Agile team never have that many issues, so if you do then you are not Agile.

    Don't get me wrong, these are all valid responses, IF everyone that used Jira was doing Scrum the way Atlassian defines it. They are not. The vast majority of companies, especially the larger companies, are NOT doing scrum. Or any other Agile ritual for that matter. There are product discovery teams for sure, but in general companies do product delivery, not product discovery. Just check to see how many UX or CRO experiments are currently running in any given company, and you probably will find there are few, if any.

    This mentality is also what is consistently blocking requests that go outside the Scrum sphere, like having estimates on subtasks show up on the story in an aggregated form or any form of resource and finance management in any of their products.

    It will only get worse

    I hate to say this as I like the products, but I have a feeling that this is only going to get worse, at least for another 5 years or so when we will either see Atlassian change directions or another product has emerged that better fit the way companies work. Atlassian is doubling down on the Agile mindset and you can see it in the products where they regularly remove functions and new products seem to be half done with little to no connectivity to other products. This would be ok if the new products would see rapid development once released, but that is not the case.

    So I am afraid that if you are looking for a tool to manage projects and tasks where you can set a standard for your company to follow, then Jira may not be the tool you are looking for. Not because it is very bad today, but because it continues to degrade as a uniform tool.

    If you on the other hand are looking for a flexible tool that your teams can adjust as they see fit in a snow globe type of setup that is great for design and explorative situations, then you are probably better off with Trello or Asana to be honest.

    If you are in need of a predictive tool for financial planning, then none of the Atlassian tools are what you are looking for. Atlassian doesn't support traditional financial structures, as Agile is an exploratory ritual. This could change however as Atlassian is focusing a lot on SAFe it seems and as you probably figured out by now SAFe is a traditional steering renamed and repackaged. So we could see more support for predictive planning tools because of this.

    Is there no hope?

    Of course, there is hope. Atlassian just must start to focus more on what companies actually need and less what they think they need. To do that, they have to look at the bigger picture and they have to focus on what matters most to all companies: finance. While they have a tool that is supposedly targeting this area it is way too expensive and since you can not test it, it still remains a tool you have to buy on faith alone.

    The first thing should be to implement proper team's setup with resource management. Make teams assignable and take a look at BigPicture that have most of what you need: workload plans, holiday plans, absence management, skills, roles and of course time allocation. Connect other applications like Confluence to allow for team spaces only visible in the teams section as well as basic information like contact information, team lead and connected systems from Insight.

    The second thing is to stop the Premium nonsense and just have one product. Locking key products like Advanced Roadmaps and the old Insight asset management in a price tier is plain stupid. Not only will you prevent your own products adaptation, you also annoy the customers that are forced to pay for things they don't want. At twice the regular cost, no less.

    The third things that should happen is to add seamless integration of the products. If you have ever seen a user trying out OpsGenie from Jira Service Management, then you know what I mean. New products like Atlas should be clearly be marketed as separate products, just like Trello, if they do not connect to the basic Atlassian ecosystem.

    Make issue hierarchy open to everyone to define. Have predefined sets for Agile or SAFe setups, but make it open for everyone to define their setup instead of locking down every user in a structure Atlassian want. We are already getting new features for the Epic, which is a great addition, now take it to the next step.

    Finally, make boards useful again and remove the caps and the breaking of features if you cross Jira Project boundaries. Add the color background feature from Business projects and allow for any colors instead of a defined set.

    My Opinion

    In my opinion, Atlassian is moving in the wrong direction in some cases. In other cases, they are doing great things. If you are working in an organization with a project based financial structure that is based around a set of portfolios and budgets, then you are probably hurting right now using Atlassian products, with add-ons.

    I also feel that Cloud is way too much of a playground right now, with little to no way to mitigate negative changes when Atlassian destructively removes features from their products. If you are on DC and are considering a move to Cloud I would strongly suggest you reconsider that unless you really know what the result will be and how your workforce will be affected with the limitations and constant updates that you can not control.'

    If you are already on Cloud, then keep careful watch on what is going on as information on changes that destructively remove features is rarely very well announced and you have to follow the community forums like a hawk to spot them. Also make sure you frequently check the well hidden suggestion and bug section of Atlassian and submit requests and bugs when things dont work or when you have features removed from the systems.

    Working with Atlassian's systems is a bit bumpy at the moment, but it is never boring!

    • Jira Software Cloud

      Jira Software is part of a family of products designed to help teams of all types manage work. Originally, Jira was designed as a bug and issue tracker. But today, Jira has evolved into a powerful work management tool for all kinds of use cases, from requirements and test case management to agile software development. In this guide, you'll learn which features and functionalities of Jira can help your team with your unique needs. 
      • 0 comments
      • 476 views
    • Atlassian

      A brief history
      Armed with a credit card and a dream, two college friends, Mike Cannon-Brookes and Scott Farquhar set out to create Atlassian. In 2002, they didn't know what kind of company Atlassian was going to be, but they knew exactly what it shouldn't be—an environment where they had to conform rather than be who they authentically are.
      Now, over 15 years later, our team has grown to over 3,000 Atlassians worldwide with offices around the globe. But it didn't happen overnight.
      Values to live by
      Our unique values describe, at the most fundamental level, what we stand for. These five values shape our culture, influence who we are, what we do, and even who we hire. They're hard-wired into our DNA and will stay the same as we continue to grow.
      We ❤️ teams
      Over 150,000+ customers use Atlassian to empower their teams and drive their missions forward.
      We take 'Don't #@!% the Customer' seriously because our customers are the reason why we do what we do. It's even why we price our products, so every company can afford them. They inspire us, challenge us, and in turn, help us build better products.
      Working open
      We believe all teams have the potential to do amazing things when work is open.
      Much of the world works, often unwittingly, in a closed way. Information is hidden or lost, bonds between teams and teammates are weak, and perspectives are withheld. The result? People burn out. Knowledge is wasted. Potential is left on the table. Forward progress is halted. This is why Open matters. This is why we do what we do at Atlassian.
      Open work has always been central to our values. It's in the DNA of our products and we bring it to life through our practices. But it doesn't just happen. Our teams make an effort to work, communicate, and collaborate openly every day to lead by example.
      Open unlocks new opportunities. Open brings us together. Open unleashes potential.
      1.001-2.500
      employees
      • 0 comments
      • 324 views

    Discuss the Guide

    Recommended Comments

    There are no comments to display.



    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
     Share

    • Articles

      About the Author

      Jimi is an Atlassian Expert with many years of experience in configuring and designing ways of working in Jira, Confluence and Jira Service Desk. He has built setups based on multiple processes and methods, including SAFe and ITIL.

      He has good understanding of the technical setup of integrations, as well as insight into competing software such as ServiceNow. He understands the problems involved with introducing new ways of working and is well experienced in coaching and training small and large work forces.

×
×
  • Create New...