Wednesday, August 1, 2018

Barriers to incorporating automation in agile teams | Supreme Agile

As I’ve written numerous times, agile teams must automate many aspects of their work, such as testing and build creation, as well as any other process whose automation would save time for the team.

However, despite it being clear to me that it’s very logical for agile teams to use automation for any product backlog item (PBI), I’ve come to the conclusion that it's simply not as obvious as I thought. As a result, I decided to write this article about the main reasons agile teams fail when trying to implement an automated solution. 

Developers’ attitudes towards automation

To understand developers’ attitudes toward automation solutions, we need to look at how they see automation in traditional environments, where separate QA teams do all the testing work without involving developers in the testing process. The direct result of this environment leads developers to become less involved in the testing process (why bother testing if there are dedicated QA teams to do the work for us).

In addition, the waterfall development process is built with different phases for development and testing, which make testing even more remote to developers who do not need to do much after their phase is done and they have already moved on to the next project.

In an agile environment, there is no separate QA department that provides a safety net for developers. The agile development team must ensure the quality of the product, and developers must become involved in all aspects of the testing process, from the unit test level till system testing.

Developers must change their attitude, mindset, and culture to allow the team to succeed in an agile working environment. Developers who fail to do this will impede the team in being able to deliver on their commitments.

Unrealistic maintenance costs

The main goal of automated frameworks is to boost the team’s ROI while increasing the efficiency of the test execution, build creation and overall process. So if we think about it, one of the main goals of using automated frameworks is to free engineers from performing manual work so they can focus on other aspects of the project.

But what happens when the team selects the wrong automated framework and uses poor test design that consumes most of their time in maintenance and stabilization of the written tests? This leads to an unrealistic situation where the team spends hours and days of manual work on frameworks that were supposed to free up their time.

A classic example of this scenario that I often see is agile teams that do not want to spend time on user-interface (UI) testing. The first thing they do is to develop or purchase a third-party vendor capture tool to record their tests, expecting it to solve all their automation problems. Well, this will not work. The creation of thousands of lines of UI test scripts that (usually) don’t follow code practices will create a situation where, over time, no one knows what they are supposed to do or why they were written at all. This leads to unrealistic maintenance time on tests that are maybe no longer relevant.

To overcome this barrier, the team must choose the right framework for the automation they want to achieve. Someone who is capable of seeing the big picture must invest time in great test design and the future roadmap, and the team must use the relevant code practices that will make the code readable and easy to maintain over time.

Previous bad experiences

One barrier that is very common among engineers is actually very basic and that is a previous bad experience in automation projects that didn't pay off.

There are many challenges in automation projects and therefore more opportunities that can cause teams to fail, such as poor design, unstable automated frameworks, and many others. In this case, the organization must analyze the reasons for the failures and ensure they will not recur in future projects. 

Legacy code

This is a simple fact: most engineers prefer to write their own code, rather than getting legacy code that was written by other programmers. When writing automated tests, we have another layer of testing, which makes it even harder for a developer to succeed with the project.  

The first barrier is the code itself. If a developer needs to work with code that he didn’t write or participate in the design of, it may be hard for him to understand the code itself and what tests should be created to provide good test coverage.

The second barrier is legacy code that isn't designed for testability, which makes it almost impossible for an engineer to create automated test scripts without needing to refactor the legacy code.  

Letting testers do the work

If I need to select one reason that will lead to failure again and again, I would probably say that it is letting testers write the automated tests when they do not have the necessary knowledge and experience in the coding field.

This is just one classic example of how all team members of an agile team should be working as a single unit without separating between programmers and testers. Otherwise, the entire project can fail by letting the testers know that if they cannot handle basic test scripts they have nothing to offer in the agile world.

In the opposite direction, a strong agile team will not let testers do this job without a supporting framework from the rest of the team. The team must understand that any automation project is the team’s problem, not the responsibility of the testers just because they were responsible for quality in the old traditional environment. 

Job security

Agile teams contain testers that in many cases were added to the team as a legacy from the previous environment. These testers often do not have coding experience and therefore focus on manual testing, which is less suitable in an agile environment. These testers may reject the idea of using automation processes for testing for fear of it making them less relevant in the future.

Fear of failure

Due to challenges inherent in automation projects, from determining the goals to the implementation itself, automation projects can be scary to engineers. As I learned over the years, programmers may have the knowledge to write great production code, but once they focus their efforts on writing automated tests, they will face many logical and technical issues that they do not have in their day-to-day work.

Lack of support and knowledge 

I think that every engineer who has common sense about automation’s benefits will want to use it to simplify work. But what happens when this engineer has neither the knowledge nor the time to invest in the creation of this framework? How can he free time, in an already stressed environment, to learn new tools such as automated frameworks and design practices such as TDD and refactoring?

To allow the team to gain the knowledge they need to master this area, the organization must step in to provide the necessary coaching. An external expert is a great option to help the team get set up and save a great amount of time. Coaching is needed in both the theoretical and technical aspects of automation practices. More important is to free the team so they can really learn and adopt this new approach in their day-to-day activities.

An investment that will not pay off right away

The team will need to invest time to create, plan, and design the automated solutions that will reduce the manual work in the long term. But although the benefits are clear, we need to remember that even with the entire agile team working on the automated solution, it still requires a big up-front investment that will reduce their ability to deliver functional PBIs in the first few sprints. This can be a big problem in an agile environment.

There is a huge psychological barrier that agile teams and the organization run into when they understand the investment that they need to make at the beginning of the automated project, an investment that will not pay off right away. Both the team and the organization must know that it takes time to decide on which processes and tests should be (and can be) automated as well which frameworks to use.

As I’ve seen in almost any automated project, the team must show senior management how automated solutions will help the organization increase the ROI. Although they will not see an increase in ROI in the first few iterations, without knowing the benefits, there is no chance that the organization will allow the team to invest the time they need to succeed with their automation challenges.

Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile

No comments:

Post a Comment

My Presentations