TL; DR: Jira Anti-Patterns
If you ask people to come up with popular attributes for “Agile” or “agility,” Scrum and Jira will likely be among the top ten featured. Moreover, in any discussion about the topic, someone will mention that using Scrum running on top of Jira does not make an organization agile. However, more importantly, this notion is often only a tiny step from identifying Jira as a potential impediment to outright vilifying it. So in March 2023, I embarked on a non-representative research exercise to learn how organizations misuse Jira from a team perspective as I wanted to understand Jira anti-patterns.
Read on and learn more about how a project management tool that is reasonably usable when you use it out of the box without any modifications turns into a bureaucratic nightmare, what the reasons for this might be, and what we can do about it.
🇩🇪 Zur deutschsprachigen Version des Artikels:Jira Anti-Patterns und wie man sie überwindet.
🗞Shall I notify you about articles like this one? Awesome! You cansign up here for the ‘Food for Agile Thought’ newsletter and join 46,000-plus subscribers.
🎓 🖥 💯 🇬🇧Guaranteed on May 16:Professional Scrum Facilitation Skills Class — May 16, 2023.
📖 Get notified when theScrum Anti-Patterns Guide book is available!
Join your peers on May 4, 2023:HoA EXTRA: How Elon Musk Would Run YOUR Business with Joe Justice.
The Organizational Rationale behind Regulating Jira
Organizations might use Jira in restrictive ways for various reasons, although these reasons rarely align with the agile mindset. Some reasons include the following:
- Control and oversight: Management might want to maintain control and supervision over a Scrum team’s work, ensuring that the team follows established processes and guidelines. A desire for predictability and standardization across the organization can drive this.
- Risk aversion: Organizations may be risk-averse and believe tighter controls will help minimize risks and prevent project failures. This approach might stem from previous negative experiences or a need to understand agile principles better.
- Compliance and governance: In some industries, organizations must adhere to strict regulatory and governance requirements. This requirement can lead to a more controlled environment, with less flexibility to adopt agile practices fully.
- Hierarchical culture: Organizations with a traditional, hierarchical structure may have a top-down approach to decision-making. This culture can make it challenging to embrace agile principles, which emphasize team autonomy and self-organization.
- Inadequate understanding of agile principles such as Scrum: Some organizations may not fully understand them or misconstrue them as lacking discipline or structure. This misunderstanding can result in excessive control to compensate for the perceived lack of process.
- Metrics-driven management: Management might focus on measurable outputs, such as story points or velocity, to assess a Scrum team’s performance. This emphasis on metrics can lead to prioritizing numbers over the actual value delivered to customers.
- Resistance to change: Organizations that have successfully used traditional project management methods may resist adopting agile practices. This resistance can manifest as imposing strict controls to maintain the status quo. After all, one purpose of any organization is to exercise resilience in the face of change.
While these reasons might explain why organizations use Jira in restrictive ways, curtailing the agile mindset and a Scrum team’s autonomy or self-management will have negative consequences. For example, restrictive practices can:
- Reduce a team’s ability to adapt to change,
- Hinder collaboration,
- Decrease morale, and
- Diminish customer value created.
Contrary to this, agile practices promote flexibility, autonomy, and continuous improvement, which organizations will undermine when imposing excessive control, for example, by mandating the use of Jira in a particular way.
Gathering Qualitative Data on Jira Anti-Patterns
I did not run a representative survey to gather qualitative data for this article. Instead, I addressed the issue in aLinkedIn post on March 16, 2023, that received almost 100 comments.
Also, I ran a short, non-representative survey on Google Forms for about two weeks, which resulted in 21 contributions, using the following prompt:
“Jira has always been a divisive issue, particularly if you have to use Jira due to company policy. In my experience, Jira out-of-the-box without any modification or customization is a proper tool. If everyone can do anything, Jira is okay despite its origin as a ticket accounting app. The problems appear once you start submitting Jira to customization. When roles are assigned and become subject to permissions. Then, everything starts going south. I want to aggregate these Jira anti-patterns and make them available to provide teams with a data-backed starting point for a fruitful discussion. Then, they could improve their use of the ticketing tool. Or abandon it for a better choice?”
Finally, I aggregated the answers to identify the most prevailing Jira anti-patterns among those who participated in the LinkedIn thread or the survey.
Categories of Jira Anti-Patterns
When I aggregated the effects of a mandated rigid Jira regime, they fall into four main categories:
- Loss of autonomy: Imposing strict controls on the Jira process can reduce a team’s autonomy and hinder their ability to self-manage, a fundamental principle of agile development.
- Reduced adaptability: Strict controls may prevent the team from adapting their processes based on feedback or changing requirements, resulting in diminished value creation.
- Bureaucracy: Increased oversight and control can introduce unnecessary bureaucracy, slowing the team’s work by creating unnecessary work or queues.
- Misalignment with agile principles: Imposing external controls can create misalignment between the organization’s goals and agile principles, potentially hindering the teams from reaching their true potential and undermining the return on investment of an agile transformation.
Jira Anti-Patterns in Practice
The most critical Jira anti-patterns mentioned by the participants are as follows:
- Overemphasis on hierarchy: Using Jira to enforce a hierarchical structure, thus stifling collaboration, self-management, and innovation. For example, roles and permissions prevent some team members from moving tickets. Consequently, teams start serving the tool; the tool no longer supports the teams.
- Rigid workflows: Creating inflexible and over-complicated workflows that limit a Scrum team’s ability to inspect and adapt. For example, every team has to adhere to the same global standard workflow, whether it fits or not.
- Administration permissions: Stripping teams of admin rights and outsourcing all Jira configuration changes to a nearshore contractor.
- Micromanagement: Excessive oversight that prevents team members from self-managing. For example, by adding dates and time stamps to everything for reporting purposes.
- Over-customization: Customizing Jira to the point where it becomes confusing and difficult to use; for example, using unclear issue types or useless dashboards.
- Over-reliance on tools: Relying on Jira to manage all aspects of the project and enforcing communication through Jira, thus neglecting the importance of face-to-face communication.
- Siloed teams: Using Jira to create barriers between teams, hindering collaboration and communication.
- Turning teams into groups of individuals: Dividing Product Backlog items into individual tasks and sub-tasks defies the idea of teamwork, mainly because multiple team members cannot own tasks collectively.
- Lack of visibility I: Hiding project information or limiting access to essential details, reducing transparency.
- Lack of visibility II: Fostering intransparent communication, resulting from a need to bypass Jira to work effectively.
- Fostering Scope creep: Allowing the project scope to grow unchecked as Jira is excellent at administering tasks of all kinds.
- Prioritizing velocity over quality: Emphasizing speed of delivery over the quality of the work produced. For example, there is no elegant way to integrate a team’s Definition of Done.
- Focus on metrics over value: Emphasizing progress tracking and reporting instead of delivering customer value. For example: Using prefabricated Jira reports instead of identifying the usable metrics at the team level.
- Inflexible estimation: Forcing team members to provide overly precise task time estimates while lacking capabilities for probabilistic forecasting.
Some Memorable Quotes from Participants
There were some memorable quotes from the participants of the survey; all participants agree to a publication:
- Jira is a great mirror of the whole organization itself. It is a great tool (like many others) when given to teams, and it is a nightmare full of obstacles if given to old-fashioned management as an additional means of controlling and putting pressure on the team.
- The biggest but most generalized one is the attempt to standardize Jira across an org and force teams to adhere to processes that make management’s life easier (but the teams’ life more difficult). It usually results in the team serving Jira rather than Jira serving the team and prevents the team from finding a way of working or using the tool to serve their individual needs. This manifests in several ways: forcing teams to use Company Managed Projects (over team Managed ones), mandating specific transitions or workflows, requiring fields across the org, etc.
- Stripping project admins of rights, forcing every change to a field to be done by someone at a different timezone.
- The biggest anti-patterns I have seen in Jira involve over-complicating things for the sake of having workflows currently match how organizations currently (dys)function vs. organizations challenging themselves to simplify their processes.
- The other biggest anti-pattern is using Jira as a “communication” device. People add notes, tag each other, etc., instead of having actual conversations with one another. Entering notes on a ticket to create a log of what work was completed, decisions made, etc., is incredibly appropriate but the documentation of these items should be used to memorialize information from conversations. I can trace so many problems back to people saying things like, “Everyone should know what to do; I put a note on the Jira ticket.”
- Breaking stories up into individual tasks and sub-tasks destroys the idea of the team moving the ball down the court to the basket together.
- Developer: “Hey, I’ve wanted to ask you some questions about the PBI I’m working on.”Stakeholder: “I’ve already written everything in the task in Jira.”
- Another anti-pattern is people avoiding Jira and coming directly to the team with requests, which makes the request “covert” or “Black Ops” work. Jira is seen as “overhead” or “paperwork.” If you think “paperwork” is a waste of time, just skip the “paperwork” the next time you go to the bathroom! 😬 🤢
- Implementing the tool without any Data Management policies in place, turning into hundreds of fields of all types (drop-down, free text, etc.). As an example, there are 40 different priority options alone. Make sure to have a Business Analyst create some data policies BEFORE implementing Jira.
- “A million fields”: having hundreds of custom fields in tickets, sometimes with similar names, some with required values. I have seen tickets of type “Task” with more than 300 custom fields.
- “Complex board filters with business rules”: backlog items are removed from boards based on weird logic, for example a checkbox “selected for refinement.”
How to Overcome Jira Anti-Patterns
When looking at the long list of Jira anti-patterns, the first thought that comes to mind is: What can we do to counter these Jira anti-patterns?
Principally, there are two categories of measures:
- Measures at the organizational level that require the Scrum teams to join a common cause and work with middle managers and the leadership level.
- Measures at the Scrum team level that the team members can take autonomously without asking for permission or a budget.
Here are some suggestion on what to do about Jira anti-pattern in your organization:
Countermeasures at the Organizational Level
The following Jira anti-patterns counter measures at the organizational level require Scrum teams to join a common cause and work with middle managers and the leadership level:
- Establish a community of practice and promote cross-team collaboration: Create a cross-functional community of practice (CoP) to share knowledge, experiences, and best practices related to Jira and agile practices.
- Revisit governance policies: Work with management to review and adapt governance policies to support agile practices such as Scrum better and reduce unnecessary bureaucracy.
- Train and educate: Support the middle managers and other stakeholders by providing training and educational resources to increase their understanding and adoption of agile principles.
- Encourage management buy-in: Advocate for the benefits of “Agile” and demonstrate its value to secure management buy-in and reduce resistance to change.
- Share success stories: Promote successes and improvements from agile practices and how Jira helped achieve them to inspire and motivate other teams and departments.
- Foster a culture of trust: Work with leadership to promote a culture of trust, empowering Scrum teams to make decisions and self-manage.
- Review metrics and KPIs: Collaborate with management to review and adjust the metrics and KPIs used to evaluate team performance, prioritizing outcome-oriented customer value over output-based measures.
- Customize Jira thoughtfully: Engage with management and other Scrum teams to develop a shared understanding of how to customize Jira to support agile practices without causing confusion or adding complexity while delivering value to customers and contributing to the organization’s sustainability.
- Address risk aversion: Work with leadership to develop a more balanced approach to risk management, embracing the agile mindset of learning and adapting through experimentation.
Countermeasures at the Organizational Level
Even if a Scrum team cannot customize Jira independently due to an organizational policy, there are some measures the team can embrace to minimize the impact of this impediment:
- Improve communication: Encourage open communication within the team and use face-to-face or video calls when possible to discuss work, reducing the reliance on Jira for all communications.
- Adapt to constraints: Find creative ways to work within the limitations of the Jira setup, such as using labels or comments to convey additional information or priorities, and share these techniques within the team.
- Limit work-in-progress: Encourage team members to work on a limited number of tasks to balance workload and avoid task hoarding, even if the team cannot enforce WIP limits within Jira.
- Emphasize collaboration: Encourage a collaborative mindset within the team, promoting shared ownership of tasks and issues, although Jira does not technically support co-ownership.
- Adopt a team agreement: Develop an agreement for using Jira effectively and consistently within the team. This Jira working agreement can help establish a shared understanding of best practices and expectations.
To use a metaphor, Jira reminds me of concrete: it depends on what you make out of it. Jira is reasonably usable when you use it out of the box without any modifications: no processes are customized, no rights and roles are established, and everyone can apply changes.
On the other hand, there might be good reasons for streamlining the application of Jira throughout an organization. However, I wonder if mandating a strict regime is the best option to accomplish this. Very often, this approach leads to the Jira anti-patterns mentioned above.
So, when discussing how to use Jira organization-wide, why not consider an approach similar to the Definition of Done? Define the minimum of standard Jira practices, get buy-in from the agile community to help promote this smallest common denominator, and leave the rest to the teams.
How are you using Jira in your organization? Please share your experience with us in the comments.
📖 Jira Anti-Patterns — Related Posts
✋ Do Not Miss Out and Learn more about Jira Anti-Patterns —Join the 12,000-plus Strong ‘Hands-on Agile’ Slack Community
I invite you to join the“Hands-on Agile” Slack Communityand enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join all you have to do now isprovide your credentials via this Google form, and I will sign you up. By the way,it’s free.
The articleJira Anti-Patterns was first published on Age-of-Product.com.
Anti-patterns are related to issues like lack of clarity around roles and responsibilities, lack of communication between team members, and poor facilitation of the Daily Scrum, among others. To avoid these problems, it's vital to ensure that everyone is clear about their duties within the team.What are the anti-patterns of Scrum Master? ›
- Excessive Tailoring. ...
- Complacent with Status Quo. ...
- Solves Problems for Others. ...
- Competes Against Other Teams. ...
- Avoids Conflict. ...
- Follows the Same Retrospective Format Every Sprint. ...
- Does Not Like to be Challenged/Questioned. ...
- Assign Tasks to Team Members.
Overly Focused on Yesterday
Oftentimes, standup participants spend too much time sharing the details of what they did yesterday (to impress managers). For example, someone may go into too much detail on the story of how they solved a bug, even though that doesn't impact what needs to be done today.
- Miscommunication. ...
- Unclear Requirements and Scope Creep. ...
- Scope Stretching. ...
- Scrum Master Acts as Team Lead. ...
- Scrum Master Avoids Conflict and Doesn't Like to be Challenged. ...
- Sprint Backlog Being Regularly Changed Mid-Sprint.
- Unreadable code.
- Cut-and-paste development.
Anti-patterns are considered bad software design, and are usually ineffective or obscure fixes. They generally also add "technical debt" - which is code you have to come back and fix properly later.What are two anti-patterns? ›
In software engineering, anti-patterns include the big ball of mud (lack of) design; the God Class (where a single class handles all control in a program rather than control being distributed across multiple classes); and Poltergeists (ephemeral controller classes that only exist to invoke other methods on classes).What are the three C's in Scrum Master? ›
These 3 C's are Cards, Conversation, and Confirmation. These are essential components for writing a good User Story. The Card, Conversation, and Confirmation model was introduced by Ron Jefferies in 2001 for Extreme Programming (XP) and is suitable even today.Can daily scrum exceed 15 minutes? ›
- The daily scrum, or standup, is the heart of sprint execution. Time boxed to 15 minutes, it should be short and direct. Keeping this event healthy will keep your sprint delivery healthy, too. A common failure in this event is when your scrum lasts longer than 15 minutes.What is a common anti-pattern? ›
Analysis paralysis is considered a classic management anti-pattern.
If team is mature enough and self organized , managed to achieve sprint Goal, team can decide to skip the daily scrum once a week with all team members consent and will. If some team level impediment occur then team may gather to resolve that as and when required.What are two typical anti-patterns with product owner? ›
- Busy or Missing Product Owner. ...
- Calling the Sprint Review a Sprint Demo. ...
- Expressing the backlog in Technical user stories instead of focusing on business-related user stories. ...
- Writing detailed user stories. ...
- Questioning the estimates given by the Dev Team.
Many organizations start their DevOps journey by adding a new DevOps silo that becomes the middleman between dev and ops. This becomes an anti-pattern when an organization stops moving dev and ops closer together into one team and just keeps the DevOps silo.What is the negative impact of the anti-pattern? ›
It is essential to recognize and avoid anti-patterns because they can lead to several negative consequences: Inefficient or ineffective solutions to problems. Increased complexity and maintenance costs. Decreased code readability and understandability.What can you say about antipatterns of DevOps? ›
That said, DevOps antipatterns can best be defined as ideas that are counterproductive to the DevOps culture. They include: Blame culture: In this kind of culture, blaming and punishing people is the norm when mistakes are done. It can happen at an individual or organizational level.Why singleton pattern is considered an anti-pattern? ›
If singleton were used here, it would break that behavior. This inflexibility is one of the biggest reasons why singleton is an antipattern. Engineers often use singletons to provide a global access point. They are often used in place of a global variable that has a single instance.What are the famous antipatterns? ›
Some examples of famous antipatterns are bleeding edge (organizational antipattern), gold plating (software design antipattern), and magic numbers (programming antipattern).What is an example of a project management anti-pattern? ›
Anti-pattern #2 – Death march
A management team that denies the obvious failure of a doomed project, but still requires developers to work until it's completed, is leading their team on a death march. Some projects will fail.
Anti-Pattern is a counter word used to describe Patterns. In this, pattern that is frequently used but is ineffective to a problem and has gone wrong is called anti-pattern. Anti-Pattern is used mostly as viable solution to a problem but due to some reasons in gets wrong.What are three team retrospective anti-patterns? ›
From my perspective, the top three Sprint Retrospective anti-patterns are: not making the Retrospective a safe place, forcing team members to participate in an exercise they consider a waste of their time, and not taking the Retrospective seriously in the first place.
The daily scrum is not to be considered micromanagement because it does not target any individual.How do I get rid of no impediments issue in daily Scrum? ›
- Don't wait until the Daily Scrum to raise an impediment! ...
- Use a Sprint Goal. ...
- Understand the difference between 'blocks' and 'impediments'. ...
- Improve transparency by using an 'Impediment Board'. ...
- Keep track of fixed impediments. ...
- Understand the organization.
On the other hand, static state, or static methods with associated static state, are utterly evil. That is an anti-pattern. It frequently helps to define a method as being non-stateful (and therefore a legitimate static method) if, and only if, it always returns equivalent output on equivalent inputs.Is OOP an anti-pattern? ›
The object-oriented-programming antipattern is the excessive / unnecessary use of object-oriented-programming (OOP) and OOP techniques when simple procedural functions would have sufficed, with less overhead, fewer files to navigate around, fewer indirections to follow while debugging, etc.Is cross functional team a Scrum anti-pattern? ›
For a Scrum team to operate successfully, the entire team—including product owner, cross-functional development team, and ScrumMaster—must honor the Scrum values of commitment, courage, focus, openness, and respect.What are 3 strengths of a Scrum Master? ›
To sum up, Scrum Masters share at least 6 traits: They are responsible, humble, collaborative, committed, influential, knowledgeable. And the best Scrum Masters also know when to abide by the rules and when to break the rules.What are the 5 C in Scrum? ›
What are the five Scrum values? The five Scrum values are commitment, focus, openness, respect, and courage.What is 3 5 3 model of Scrum? ›
In other words, Scrum works best when implemented in its entirety. That means employing the only formula you will need in Scrum (3+5+3) i.e. 3 roles, 5 events, and 3 artifacts. But what about product backlog refinement? The process of product backlog refinement is considered an ongoing activity in Scrum, not an event.What is 15 10 5 rule in scrum? ›
We also have a good practice which the teams can follow, 15-10-5 allocation of the scrum team's capacity, which means, 15% of a team's capacity to technical debt, 10% of a team's capacity to defects, and 5% of a team's capacity to exploratory work.How many sprints can you have in scrum? ›
Depending on the scale of your project and what you determine as a team during goal setting — including sprint planning— you may have as few as two to three, or as many as 10–20 Scrum sprints.
“The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.” So " Yes, it is mandatory that they <PO-s> do not participate in Daily Scrums. " , thankfully, is outdated in realization that banning good resources is not optimal.What is the N 1 anti-pattern? ›
The N+1 query antipattern happens when a query is executed for every result of a previous query. The query count is N + 1, with N being the number of queries for every result of the initial query. If that initial query has one result, N+1 = 2. If it has 1000 results, N+1 = 1001 queries.What are the code anti-patterns list? ›
- Spaghetti code. If somebody tells you that you write good spaghetti code, it's not a compliment. ...
- Golden hammer. ...
- Boat anchor. ...
- Dead code. ...
- God object. ...
- Copy and paste programming.
The Scrum Master should not take sides
The facilitator role of the Scrum Master means that in a situation of conflict, he should not take sides or have any predilection for someone's opinion. Instead, he should serve as a mediator in helping the parts reach a solution.
Not only can the Product Owner abnormally terminate a Sprint at any time, but the ScrumMaster can cancel the Sprint at any time on his or her accord or on behalf of either the Team or the Product Owner. The Abnormal Termination has been a part of Scrum from the very beginning.Is IT allowed to skip the Daily Scrum if there is nothing to talk about? ›
You should not reschedule or skip daily scrums no matter how busy your schedule is. Skipping these meetings could derail project delivery as well as quality. You shouldn't be missing these meetings, and you shouldn't be allowing any of your team members to miss the daily scrum either.What is Scrum anti-patterns? ›
Scrum Anti Patterns are behaviors that the team members exhibit that would drain the resources from the Scrum Team in the long run. Keeping an eye out for such behaviors in the Scrum Team would enhance the productivity and performance of Developers.What are anti-patterns Scrum values? ›
- Unrefined Product Backlog. Product Owners practice the mentioned pattern. ...
- Missing Key Stakeholders. Planning and assigning tasks is possible after discussion with stakeholders. ...
- Weak Definition of Done And/or Ready.
Question: why are big stories considered anti-pattern they make it difficult to apply iterative development they do not support pair work they make it difficult to estimate compliance efforts they make it difficult to estimate testing efforts.What is an anti-pattern how anti-patterns are helpful in arriving at a good design solution to a problem? ›
Anti-patterns are certain patterns in software development that are considered bad programming practices. As opposed to design patterns which are common approaches to common problems which have been formalized and are generally considered a good development practice, anti-patterns are the opposite and are undesirable.