Most times the first thing a team will automate is their build process. This is an easy target for productivity improvement, and is table-stakes for most (if not all) software teams. Then, teams will automate their deployment pipeline, and someone will wave a checkered flag and poof the team is now practicing “DevOps”.
Congratulations! There’s nothing left to automate, right?
Sounds absurd when I say it like that, doesn’t it? Like, we all know and feel there’s more to be done, but it’s hard to put our finger on it, isn’t it? The code part has been automated, the part the developers control by themselves is automated. Therefore, there must be nothing left to automate.
Put another way, left to their own devices, developers will automate everything they think can be automated or will improve their day-to-day work. Most developers, absent time and the ability to think deeper on the subject, would never think to automate the handoffs, or the tasks they do repeatedly but aren’t visible problems, or non-tech workflows.
We accept a certain level of manual intervention when we deal with JIRA because that’s what we’re used to. We’re used to developers manually creating their own branches, or manually reaching out to people who know that area of the code well, or manually letting testers know it’s ready for review, or manually de-assigning themselves items when it gets close to the end of the sprint, or letting the build notify everyone when it’s broken instead of a targetted alert to the person that broke it, or manually decide who needs to be in on a feature meeting.
Those things add up, and they add up quickly, but these things I list are automatable — and JIRA already contains all the information we need to automate these processes. What keeps us from automating it (besides not realizing it’s automatable) is that we don’t realize its effect on everyone on the team. How much of your day is spent responding to a code review request only to find out there’s one or two people on the team who have even worked on that feature previously? Or how we create hooks and automations to enforce branch and commit naming conventions but we don’t automate the creation of the branch itself; or automate the commit message itself? Or that we don’t automatically have JIRA send an email to the Project manager de-assigning lower priority items from a developer who is overloaded; and suggesting re-assignment to someone who has worked in that area of the code before and has bandwidth? If you use the ability to label feature areas in JIRA, then you already know who has completed work in which feature areas in the past, and boom, that’s a good starting point for a code review or a feature discussion. No need to spend human time figuring something out that the machine already knows.
In our next segment, we’ll talk about the underlying principles that cause this to be the case, and give a recipe to fix them.