Best practice for automation
We live in a world where anything is possible. But just because it can be doesn't mean it should. I advocate to automate everything, to make my life as easy as I can. Even with this view, there are still right and wrong times to automate. There are best practices that help us build scalable, efficient automations for the future. Early last year, I did a talk with two fellow community leaders & Appfire at Atlassian’s Team ‘24 event. You can check out the full recording of the follow up webinar HERE.
The following blog however is, how we can implement those best practices as best as we can.
Implementing best practices for automation within a business is absolutely essential for ensuring overall efficiency, consistency, and scalability in operations. By standardising processes and effectively leveraging technology, organisations can significantly minimise human error, enhance productivity levels, and ultimately reduce operational costs.
Adopting a structured and methodical approach to automation not only streamlines workflows but also frees up valuable resources and time, allowing teams to concentrate on strategic initiatives and drive innovation. This proactive stance helps businesses remain competitive in a rapidly evolving market, enabling them to respond swiftly and effectively to changing demands while maintaining a consistently high standard of service delivery to their customers.
“Just like our ever changing world, automation is inevitable for teams to stay ahead”. While inevitable teams often can do one of two things. Not know where to truly start, so don’t or run away with the automations without considering the end goal. So let’s start clarifying all these things.
Where to start
Get your requirements in plain english (native language)
Having simple sentences with very clear written requirements, eliminates jargon or the biases of preconceived understanding from the equation. For example. “I need this automation to run at midnight every day and find me all issues where the due date is tomorrow, and edit the assignee if they are not already in the done status to me”.
This seems like a mammoth requirement when written, but the individual components are very clear:
The automation needs to be scheduled to run ever day at midnight.
We need to see all issues where they are NOT in the done status.
We need to see all issues that also have a due date of tomorrow
We need the rule to edit the assignee to XXX person.
Now we have clearly written requirements, our chance of first time success massively increases. It removed the bias information that the requestor may have thought the rule should worked & allowed you the admin to design it as efficiently as possible while still hitting these requirements.
Naming your rule
While this seems insignificant, I can tell you from experience that naming rules certainly helps identify issues when in a pinch. Rodney Nissan, The Jira Guy, explains that every rule should be appropriately named to answer the following three questions:
What does it do?
Who owns it?
When did they do it?
While you can find the answers to all these three with enough digging, When you are in an incident with actions happening all around you, anything we can do to shorten the outage time is appreciated by all.
From here, we can see a clear name, description, owner and possibly space or project it would affect. If we were having an issue with pages randomly being assigned labels, we would be able to much better grasp which rule could be the problem quicker with clearly assigned names.
You will also 100% make both your future self & the person following behind you like you that little bit more.
Creating your rule
Think about the right tool for the right job
There are lots of brilliant automation apps that can help get you to where you want to be. So how do we not only know what we have at our disposal, but which one the right tool is?
The first step in any of this will be to speak to your IT team about all options that are available to you. Things to consider about the right tool are how many people know the application & could administer the rule? Do you have to know specific coding languages to build the rule? Would you be building additional reliance on third party systems (non native functionality) for this to work?
Once you have worked out the right application, now it comes to trial the rule building. Make sure you always trial in a sandbox environment where it cannot hurt production data. I can however never recommend trialing things enough. You’ll figure out how to make rule actions more efficient and simpler all while keeping the business flow as normal.
Playing devil's advocate
What I can say is that this step is the most overlooked. Rules do not just stop once they are created. Like teams, they will mature with the processes as time continues. A great way to get ahead of future changes is to play the devil’s advocate. Think about how the rule would change IF the team doubled in size, IF this rolled out to more teams etc. By thinking about some of these things up front, you remove some of the maintenance cost to ensure you always stay positive. If the team did double & your rule was calling out specific assignees in conditions to action other elements, this isn’t that efficient. Could you re-write the rule to think about using the lookup table action and advanced branches for example.
Thinking about maintenance and reducing technical debt
While I push teams to automate everything, YOU MUST only actually automate where the benefits outweigh the cost of implementing and maintaining. While proactive thinking can certainly reduce the ongoing costs, it unfortunately wont stop rules needing updates. Nor should it. Teams & their processes never stop evolving so why should our automations. So how do we reduce the technical debt with automation? The easiest step is to just pause. Take stock of your automation landscape. Understand how rules are working, where they overlap, what tools you have at your disposal. Then plan.
The easiest rules to decrease debt on are rules that are over engineered in regards to using a higher debt application (scripting engines) for simple change of assignees, update custom field etc. Look to move these to point and click automation options that are done natively or through the use of marketplace apps. Scripts 100% have their place, but scripts also have the biggest barrier to entry. By swapping how these rules work you can reduce the reliance on having to know specific coding languages meaning you can have increased delegation etc.
Another way to reduce tech debt is to remove bottlenecks for creation. Providing delegated controls for trusted individuals means teams are able to adapt and trial without the reliance on admins. Of course governance and care need to be applied but wherever possible, this is a great way to help.
Some important advice when scaling
While the first seems incredibly obvious to most, I can assure you very rarely do I see it happen well enough. Yes, that’s right! Documentation. I know every person hates doing it. Funnily enough there are apps that can help with this, but even without apps, you need to document. It won't just be for your future self. It is for every person following in your footsteps. Providing answers to Rodney's previous questions around who, what, when & why can make sure that at the first sign of upcoming maintenance or an incident, everyone is on the same page.
Create a Confluence page for your major automations, provide details, screenshots, and how-to guides if it goes wrong. All of these means anyone can resolve the problem. This can also server as an automation repository. A backup for automation rules!
Next would have to be providing audit trails for actions that might not be so obvious to users. If you have an automation that sends emails, for full transparency, have a copy of the email as a comment on the issue. Creating a fully holistic issue, encompassing every aspect is incredibly important for working out how & what could have changed data.
Finally, Education & Governance. We want every company to succeed. This means not creating bottlenecks, not creating an over reliance on specific technologies, documenting, but most of all training everyone on how to be better. Don’t assume you know everything either!! Creating an automation guild to share best practices & tips can be vital to a company's success. It can help with peer to peer reviews, placing good control checks within software to reach a level of governance or just simply be there for some friendly advice if you are not sure how to proceed.
Key takeaway
If there was only ONE thing I hope this article will do, it would be to embrace automation. It is something to love and not fear. Just because it should be loved, doesn’t mean you shouldn’t build with scale in mind however.
