Over the years I've worked on several teams that have tried to implement automation of one kind or another; automated deployments, testing, triage, you name it. Anything that ends up being a repetitive pain is a good candidate for automation. Here are a few tips that I find help teams focus on creating automation that is sustainable and maintainable. If you keep this in mind as you embark it should save you from having to trash your entire effort and start over.
Tip 1: Create a roadmap
I am still surprised how many teams embark on the journey toward automation without a plan. Often I find that automation happens organically; it seems to crop up around the most painful parts of the development process. For example a team might automate deploying to their development environment if they’re doing that multiple times a day, or they might try to automate their smoke test suite if there's a team that runs the same set of tests manually every time a release is ready. This organic growth leads to an unmaintainable blob of automation that can only be tweaked by a handful of developers.
When you find a candidate for automation sit down and plan out what your north star looks like. Once you know where you want to get to figuring out what you need to get there becomes much easier.
When you find a candidate for automation sit down and plan out what your north star looks like. Once you know where you want to get to figuring out what you need to get there becomes much easier.
Tip 2: Don’t invent your own framework
There are so many frameworks freely available that you would need a really good reason to create your own framework. Often teams will create frameworks with the intention of saving time, money, or sharing work between teams. In reality they end up creating something that works really well for them, but the time it would take to ramp up on developing the framework usually scares other teams away from adopting it.
By sticking with common frameworks like Selenium, Spock, Puppet, or whatever you want to use other developers will already be familiar with what you're using which reduces ramp up time and friction around adoption.
Tip 3: Only POC things you aren’t sure will work
Proof Of Concepts (POC) should be for what the name implies, proving out something that's only a concept. Often teams will use the term "POC" when they're really just trying to learn something new that's already proven and well documented. I once had to evaluate a team that was "POCing Cucumber." My first question was, "what are you trying to prove?" Their answer was that they wanted to prove they could test their web services. For that they could have simply read the documentation, you don't have to prove Cucumber works.
Continuing with this example perhaps a team wants to run a POC to prove their nontechnical product owners can write scenarios that can drive TDD within the development team and reduce the amount of churn in requirements definition. In this POC they will use Cucumber as the BDD framework the product owners will use. We know that Cucumber works, we don't know if asking the product team to write BDD scenarios as requirements will make the development cycle more efficient.
Tip 4: Don’t mix foundational automation in with your normal work stream
Foundation automation is work that isn't critical path for your current deliverable. Build servers, pipelines, regression tests, things like that. When you have deadlines it's pretty typical that anything that's not a feature will not get prioritized. Ideally tasks will contain space for the appropriate automation to manage its lifecycle within the context of the larger system. However that doesn't always happen. Creating user stories for automation tasks is a logical idea but unless you have dedicated resources responsible for getting them over the line they will typically take a long time to get completed, if you ever complete them. If your team can't quite get over the hump because you can't carve out the time to get a solid foundation in place here are some strategies that I've seen work:
- Have a separate team set up the automation in partnership with the owner team. Once everything is set up and handed off they can leave the work with the owner team.
- Dedicate a sprint every once in a while to improving automation. You see this in scaled agile, where teams take a sprint across the organization to catch up on tech debt or improve foundational automation. Catalog your pain points and figure out how to measure them in your feature sprints, then in the sprints where you tackle automation use that data to set goals and prioritize work.
- Have a separate team set up the automation in partnership with the owner team. Once everything is set up and handed off they can leave the work with the owner team.
- Dedicate a sprint every once in a while to improving automation. You see this in scaled agile, where teams take a sprint across the organization to catch up on tech debt or improve foundational automation. Catalog your pain points and figure out how to measure them in your feature sprints, then in the sprints where you tackle automation use that data to set goals and prioritize work.
