Jira is a wonderful tool, and one of its greatest strengths is that it is so easy to configure anyway you want it. Jira's biggest weakness is however also that it is so easy to configure. If you go to the companies where people really dislike working in Jira, you will often find that they share several common mistakes made when designing Jira at scale: Fragmentation of setup No governance strategy Massive amounts of configurations Top-down design led by management These things lead to painful setups of long and usually illogical workflows, isolation of Jira projects making collaboration impossible and ultimately a system that border on collapse. These are the setups that make people dislike working in Jira, and I fully understand them. Chaos is not something you want to have in your system or your way of working. I have seen some alternatives to this, and they are usually closed and controlled to the point of claustrophobia instead. This makes working in the system painful, as it feels like forcing square pegs into round holes, or worse. These setups are usually hard defined around one methodology, like SAFe, Waterfall or Scrum, making working in any other way almost impossible. The Flexible Atlassian Setup This is why The Flexible setup is designed to mitigate both these scenarios. It is designed to provide a structure based on processes that we always do, regardless of methodology, while at the same time allow for flexibility to use any methodology within that structure. In short, we cut away the BS and focus on what we actually do, and we do that bottom up instead of top down. We clearly define the separation of business processes and delivery processes, and we place Confluence in between as the tool for documentation. We clearly define the difference between need/idea and requirement, and we ensure that we support both business processes and delivery processes in the least intrusive way for all users. We do this by defining work in Jira as work orders and features. We define the work orders using different issue types based on the work that is being done, instead of having generic artifacts that can be abused and distorted. All work orders are color coded to ensure everyone understands what process it belongs to. Workflows are short and focus on the processes and the shift of responsibility rather than state diagrams of every possible state of a work order. We align statuses, so all types of work can exist in the column based structures of the boards, and we use the fetch and release principle to simplify work and visibility. We simplify and unify information based on the process involved. This ensures that we avoid bloating by adding information that is not relevant to the work order. This also ensures that cross Jira project collaboration where teams can work with Jira issues from any Jira project seamlessly, which is especially important for integration work. We create basic roles and place the power of who can see what in the hands of the Jira Project Administrators, and we reduce the noise by setting up notifications to a bare minimum. This is the Flexible Atlassian Setup, and I hope you will find it useful.
