The Art of Evolution: Effective Agile Transformations

By Matthew Done, Head Of Development, Australia, Worldfirst

Matthew Done, Head Of Development, Australia, Worldfirst

As businesses have come to realise that their success in technology will define their commercial success, it became apparent that a departure from ineffective models of software development and BAU operations was necessary. Agile came to the rescue, and today, Agile transformations are either currently in-flight, completed or on nearly every company’s roadmap. In fact, 97 percent of companies in the annual State of Agile Survey say they are already adopting Agile methods, and 78 percent of these report that their transformation is still evolving. From my experience in IT across many different industries, leading many Agile transformation initiatives that encompass over 20 years, it is safe to assume that the outcome of similar initiatives will usually be successful if:

• The staff running the transformation has influence across the organization. Agile is a whole of the company initiative

• There is willingness from all staff to change and adopt new ways of working

• Company-wide priorities and budgeting processes are aligned

• There is a mature test and release practice.

Each of the points above can derail an Agile transformation but maturity of testing and release practices is what I’d like to focus on in this article, as I believe, this is one of the most common contributors to unsuccessful agile transformations. It is all well and good to have high performing teams with daily stands ups and an engaged business but if there is no solid test and release process, things will get ugly, fast!

Without question, the “Test and Release” process must be automated. A red flag to any agile transformation is having a team of testers that is as big if not bigger than your development team. If you are embarking on an Agile transformation and this is the case, then stop, and focus on Test and Release automation first.

Scrum is one of the most adopted Agile frameworks in use today. It prescribes that after each sprint (typically 2 weeks of development and test effort), we should have a potentially shippable product. Success is measured in terms of working software. I would go further to say success should be measured in terms of high-quality working software. Any team can produce working software, but it‘s the quality that matters. Quality assurance can only come with a high level of testing across all aspects of your application.

Typically, in organizations with low automation maturity, an end-to-end Quality Assurance (QA) processes can take weeks if not months to complete. If you push QA out to the end of a sprint or worse yet into its own sprint, then the various items in your development backlog are not actually done - they are “almost done”. Almost done backlog items are a killer to predictability and successful Agile.

Automating Your System Tests Via UI Automation can have One of the Best ROI For Your Business

Testers will invariably find bugs and feed those into the current sprint or into a future sprint. This unplanned work delays the project as items need to be fixed and re-tested. This often results in negative progression, with stakeholders blaming Agile.

So what is the solution? Automate. Automate it all! Well, at least that should be the goal. Easier said than done you say?With the help of mature tools, release automation should be relatively straightforward for most applications. You take what is in the heads of your dev and ops teams and script it. They do it repeatedly, so it is probably a well-documented process, or at least it should be. Teams should be able to take this knowledge and move it into one of the many tools on the market today; Jenkins, TeamCity, Travis Ci - or one of my favourites, GoCd, an open-source project, sponsored by ThoughtWorks. Manual intervention should be avoided at all stages of the release process.

The next more complicated element is test automation. Testing typically comes in two flavours; functional and non-functional. Functional testing is a type of software testing whereby the system is tested against the functional requirements/specifications. Non-functional testing is defined as a type of testing implemented to check non-functional aspects (performance, usability, reliability, etc). In my experience, non-functional test coverage is easier to achieve than functional. Many providers and tools can help with non-functional testing without knowing a huge amount about your domain. These types of test are still important but can usually be outsourced.

However, the harder tests are your unit tests and your business logic tests, sometimes referred to as system tests. Unit tests test an individual software component or module and are typically done by a programmer and not a tester. Development managers like to have a suite of unit tests that cover a percentage of the number of lines of code in a system. A metric greater than 80 percent of lines covered is indicative of a development team that puts testing at the forefront of their development lifecycle. In saying that, unit tests are very difficult to create retrospectively. If you have a large system with little or no unit test coverage, then it is going to a take a large commitment from the business to get you to a reasonable level of coverage in a reasonable timeframe. Unit tests make your system more robust by massively reducing runtime bugs and decreasing the chances of your new features unexpectedly breaking other parts of the application. This makes sense to developers, but quite often, the business case to increase unit test coverage is difficult to justify, especially to non-tech stakeholders.

Another more palatable option is to automate your system tests. Typically, this can be done by automating the interactions a tester/customer would take in your user interface (UI). System testers start by gathering all the business logic requirements for your system. Most of the time they can talk to testers and subject matter/domain experts in the business, which helps, keep the development teams free from interruptions. Once the requirements are collected, system testers can apply a ‘Combinatorial Testing’ technique called ‘Pairwise Testing’ to assess all the potential functional permutations in order to reduce the number of required tests without sacrificing useful coverage. It is usually impractical and time-consuming to test all possible combinations for all those requirements. So instead, a subset of combinations is generated to satisfy all factors. How is this done? There are a few systems on the market today, but an industry leader is System Testing software Tosca, developed by Tricentis. They can automate this analysis for you to find optimal test combinations. More recently, they have been using AI to improve this analysis. Tosca will take your requirements and map them to UI interactions, which can run repeatedly in your CI/CD pipeline. Tosca can also help with service virtualization, which is a method to help you emulate your service dependencies, but I’ll leave that for another article.

In my opinion, automating your system tests via UI automation can have one of the best ROI’s for your business. Almost without fail, quality goes up and predictability increases. It also goes a long way in helping you be successful in your Agile transformation journey.