Even in Agile organizations, processes and tools that support processes, are very important. But you can do it in a way that makes you more Agile. And you can do it in a way that makes you less, or even not, Agile. Let’s take Jira as an example. If you want to be Agile, how should you not use Jira?
Do not close tickets without permission of the requester
A ticket in Jira in general represents a problem or a wish by someone else. First, you read it in a certain way, then you act on it in a certain way. And in the end, you want to close the ticket.
No matter if you have solved the problem or wish, you shouldn’t close a ticket without talking to the requester of the problem or wish. When you have solved it, realize that the only person who can tell you if this is true is the person who requested the ticket. When you haven’t, because you think it’s not needed, realize that this is not your decision. You might have the power to prioritize, but not determine what a person needs. In any other situation, for example, lack of time, the ticket should be left open. So in the future, you have a real overview of the problems and wishes. And not a filtered one.
Why is this important? The most important reason is the fact that you realize miscommunication can always happen. By always talking to and checking with the requester, you can prevent this. But there is another reason. When you talk to a person, you have the option to make a person feel important. Even if he or she doesn’t get what he or she wants. You can answer questions, and explain your decisions. And that has another benefit: they will keep using Jira. If you just close the ticket and a person doesn’t agree, I can guarantee you some people will do anything to avoid Jira or at least also use other channels. Because they will not trust you enough.
Jira is not a communication tool
Jira is a tool that is meant to support you in your process, by giving an overview and helping you manage the process. It is not meant to communicate with colleagues and requesters. Why is that? Ever had a ticket with 30 comments? Ever had a mailbox with 100 Jira tickets?
If you want Jira to give the overview you need, you should make sure it’s easy to find the info you need. This means that comments should be contained to a minimum and should contain only info that is needed.
An example of things to avoid are discussions. If you do not agree, don’t start a discussion in Jira, certainly not in the comments. This will lead to several comments that later are just clutter for someone else. Because at least one opinion will not be relevant anymore.
And yes, it’s true, Jira sends emails in a lot of situations. And if this works for receiver and sender, feel free to use that option. But for persons who use Jira a lot, they might get too many Jira emails. And they might miss important info that way. So, if it is important, using a real communication tool can be the better option.
Do not use Jira as a means of force
In Jira, a lot of things can be made mandatory. Because of that, Jira is often used as a way to force people to work in a certain way. I can guarantee you: people will use every way they can find to go around the mandatory parts. Giving incorrect info in mandatory fields. Changing ticket type, to avoid certain mandatory flows. Or just lying about the status of a ticket, if they cannot do what they want.
You should always try a avoid forcing people. Because force will, most of the time, not give you the result you want. They will not follow the procedure or give you the information you need. At least not always. There is only one way you can get that for certain: convincing them that this is the smart thing to do.
What you can do? You can use Jira to help people remember all the mandatory steps. When you have a lot of regulations, people might by accident forget. When Jira reminds them, they won’t mind.
In general
Agile can only be based on communication and trust. And every tool and process you introduce should also be based on that. A process or tool should improve communication between persons and not replace communication between persons. A process or tool should preferably not only improve your work situation, but also that of all persons involved. And if that is not possible, at least hinder them not that much.
When you need a process or tool to be able to trust someone, you might be right, but you are not Agile. In Agile you should work together toward a common goal. Improve together, learn together, solve together. That can only be done if trust is present. And if the trust is present everywhere, certainly in your tools and processes.
Tools and processes can and should be used to remind people of what they already are willing to do. But don’t do, because it just might be too much to remember. At least, that is, if you really want to claim you are Agile.