Be Careful! Jira Might Restrict You From Being Agile!
When Jira defines how you work, you miss the mark.
When Jira defines how you work, you miss the mark.
Jira is one of the most common tools among Scrum Teams. Yet, using Jira doesn’t mean you are doing Scrum. Over the last years, I got annoyed by how easily teams fall into pitfalls with Jira. For example, some teams put a lot of effort into processes by setting complex workflows; meanwhile, they reduce collaboration because the workflow defines how they work.
Should the dog wag the tail, or should the tail wag the dog?
In my opinion, a tool should empower the team instead of modifying them. When the energy goes to the tool, teams miss the mark. Tools should not distract teams from focusing on delivering value. Teams should not forget the Agile Manifesto: Individuals and interactions over processes and tools.
Let me share with you why I believe teams misuse Jira and ultimately miss the chance of being Agile. Yet, this post is not about criticizing Jira but sharing my experience of what helped me progress and what held me back from it. I hope it helps you in your scenario.
Workflows Are Dangerous
Jira is pretty flexible with workflows; you can do whatever you want. That’s why it’s dangerous. People want to feel safe, and nothing better than having a solid workflow to define how they work.
Before I share my experiences with workflows in Jira, please look at the following image, and answer this question How Agile can this team be within this workflow?
I believe teams working with such workflow have little chance of being Agile. Unfortunately, I’ve already used similar workflows. Generally, the workflow started simple, but we added something to avoid a similar situation whenever we faced a problem. For example, we couldn’t progress during the refinement because something was missing, then we created a stage called “Dev Ready,” and we introduced the Definitions of Ready. Instead of identifying the root cause, we often focused on short-term measures.
With this example, it appears the team battled complexity by complicating workflows instead of opting for reduction and simplicity.
At some point in time, our team had a complex way of working. Our conversations focused on tools and processes, and that deviated our attention from what matters most: delivering value sooner. Spontaneity became unwelcomed; a Product Backlog Item could never make it to a refinement session without filling a set of criteria. We became a slow and complex team and ended up missing the mark. We were anything but Agile.
It was easy to fix our problems by changing our workflow. But doing what is easy doesn’t mean doing what is right. Imagine you have water leakage in your shower. Do you try to cover the leakage with something and forget about it, or do you call a plumber to evaluate the root cause and do what is right?
To be Agile, we have to do what is right instead of what is easy.
Extensive Comments on Tickets Slow Teams Down
When writing becomes the communication standard, misunderstandings are inevitable. Verbal communication represents no more than 40% of our whole communication. Yet, many people overuse this type of communication and hope for clear understanding.
I’ve stumbled upon many situations that the comment feature on Jira reduced the teams’ collaboration and created distance among them. Let me share a couple of examples with you.
Bugs: during the Sprint, a developer finished implementing a User Story, and another developer reviewed it. During the review, the developer identified a couple of bugs and commented on the ticket. The one who implemented didn’t understand and commented back. After two days, this item had seventeen comments, and no progress was made.
Integration between front-end and back-end: a front-end developer needed a change on the API to match the acceptance criteria. She commented on the ticket and tagged the back-end developer who implemented the API. A discussion started on the ticket; after fifteen comments and three days passed, they could agree on what to do.
In both examples, the team members could have solved the understanding problem in a fifteen-minute call. Yet, they focused on commenting on the tickets, adding screenshots, code samples, etc. Once again, the focus was on the process and tool instead of collaboration. Even in remote times, it’s fine to call someone spontaneously and ask for help.
Trying to solve problems through comments on tickets is the right way of generating more problems and causing misunderstandings.
The Ping Pong Game
Does your Scrum Team function as a single unit, or are there micro-teams inside of it? When teams break down into siloes, collaboration suffers, and sub-optimal results become the outcome. Have you ever heard anything similar to the following?
I’ve finished the back-end, now the front-end fellows can implement their part.
I cannot progress because the UX Designer hasn’t finished her work.
I am finished with my part because the front-end works correctly. It’s missing a change with the back-end, which is not my responsibility.
Unfortunately, in many Scrum Teams, a kind of ping-pong game happens. Team members finish part of something and then shift the responsibility to the other. Let me give you an example with Jira:
A developer starts implementing the back-end and then assigns the ticket to her.
The developer finishes the back-end part and assigns the ticket to another developer to implement the front-end.
Once the front-end part is finished, the developer assigns the ticket to another developer to test.
During the test, the developer identifies a bug, comments on the ticket, and assigns it back to the front-end.
The front-end developer reads the comment and understands that as a back-end problem and then assigns it to the back-end developer.
The back-end developer doesn’t perceive it as a bug but as a different request and comment on the ticket and assign it back to the one who tested.
The developer responsible for the test closes the ticket, creates another Product Backlog Item, and assigns it to the Product Owner.
Does this situation look familiar to you? Sadly, many teams work like that. It’s a ping-pong game. When the Scrum Team doesn’t work as a single unit to achieve the Sprint Goal, they become a group of people running in different directions because everyone has a separate goal.
It’s not about finishing a part of the item and pushing it to the next person. This mentality can work with assembly lines but not with software development. Instead of assigning tickets to another person, team members should collaborate to get things done and ultimately deliver value.
“Accountability breeds response-ability.”
― Stephen R. Covey
Simplicity Beats Complexity
Regardless of the tool you work with, you should never forget your ultimate goal of delivering value faster. Don’t let any tool ever distract you from what matters most.
Jira has many features, and they may attract you to use them as often as possible. Yet, I learned that simplicity is vital to building meaningful products. Here are the fundamental attitudes I find in high-performance teams:
Workflows are simple and leave room for spontaneity.
Team members collaborate to progress. Tickets don’t have extensive comments but only comments reflecting agreements made between team members’ exchanges.
All members of the Scrum Team feel accountable for the Sprint Goal. They move smoothly together as a single unit.
Did you like this post? What about becoming a Medium member to benefit from unlimed reading? By doing that, you can support writers like me and thousands of others 😊
