Applying agile principles to automation projects | David Tzemach

Automation projects can be very challenging, even for the most experienced teams. Each automation project has its challenges, difficulties, and risks that cannot be forecast at the start of the project. In addition, other factors can affect the project, such as the organizational culture, timelines, pressure from senior management and the available resources and their expertise.

This article will see how agile teams can use agile values and principles to meet challenges when facing an automation project. It makes sense that agile teams can benefit from the agile manifesto and its leading ideas when starting a large, complex automation project. Just think about the main concepts presented in the manifesto: collaboration, courage, safe environment, continuous feedback, communication, and most importantly: continuous improvement.

Taking the time to do it right the first time

Every automation project will demand investment from the team before finding the best solution. In addition, an agile team works under tremendous pressure to deliver commitments after a very short period; therefore, the team must know how to work with senior management to get the time they need to succeed with the project.

Commonly, senior management focuses more on what the team delivers at the end of each sprint rather than on the work they need to do to succeed. Automation projects significantly impact the whole project, but they are not delivered to the customer. This is why the team must get management to understand that implementing reasonable automation solutions takes time and clearly explain the trade-offs.

Implementing automation solutions the "right" way takes time because it demands upfront planning and investigation, similar to any other coding project that includes planning, design, coding, and testing. The team won’t benefit from the automation solution in the short term, but it will save a significant amount of time in the long term. Let's take the scenario of an agile team pressured to deliver many features without being given the time to automate regression tests to ensure these features keep working once they are released to the market. This common scenario will most likely lead to a high cost in the long term due to an accumulation of technical debt that will not allow the team to deliver the same business value they did at the beginning of the project.

To allow the team to succeed, the team must work at a sustainable pace that will enable them to deliver the most valuable PBIs and work on the frameworks that will prevent the need for manual test efforts in future iterations.

Mistakes are part of the solution.

Automation projects take time and a significant amount of effort. During this time, the team will most likely make mistakes, such as lack of communication, and encounter technical issues. In agile practices, mistakes are seen as just another way to improve the team and the overall quality of the product. Mistakes are the best growth engine for both the team and the individual. In addition, mistakes are great for triggering learning cycles. The more problems you have, the more you'll learn during the process.

Build the simplest thing that could work

Automation projects can be very complex, even for the most experienced teams. To help deal with this complexity, we can use one of the best-known principles of Extreme Programming (EP), which states that teams should develop with simplicity by "doing the simplest thing that could possibly work."

This mantra of keeping things as simple as possible applies to automation projects and any coding project. For an agile team that needs to automate as a key to their ability to deliver fast and early, it might mean starting with a simple test design, minimal project scope (which will be extended at advanced phases of the project) and using the most simplified automation framework that does the job.

There is an excellent reason why simplicity is a core agile value. Simplicity does not mean that the team does only the easiest things. The simplification mindset and practices will drive the team to think deeply about what they want to achieve and how to approach it step by step instead of developing a large, complex plan that will increase risk and uncertainty. In case of a wrong choice, the team will have more room to handle their mistake.

Automation test projects should start at the lower layer of the application, the unit level, which can be easily automated compared to the more complex layers (component, integration, and system). Once the team has a solid test infrastructure at the unit level, they will gain more confidence in automating the higher levels of the application step by step and test by test.

Continuous feedback

Continuous feedback is a significant concept in agile software development, allowing agile teams to work in short iterations. The team gets fast, productive feedback at the end of each iteration instead of getting it at the end of the project (which is more relevant to traditional software development).

Automation projects can benefit from this concept because it allows the team to experiment with versions, automation designs, frameworks, and evaluation of the execution results while getting quick feedback and changing course if needed.

Automation projects will take at least a few iterations to find the automation framework— in-house framework, open-source tool —used for implementation. At the end of each iteration, the team will benefit from two streams of feedback, first when they present their work (during the review meeting) and receive feedback from the relevant stakeholders, and second by just looking at the work done and examining what's working and what's not.

The use of these streams will allow the team to understand whether they chose the right path or if they need to adjust the current solution to support the feedback they received. In addition, continuous feedback will allow the team to adjust their work without getting stuck in automation projects that consume many resources, time, and effort (which a team does not have in an agile environment).