Software delivery becomes on-demand

Organizations need to develop the ability to release valuable software whenever they want. Yet, despite their continuous delivery and agile endeavors, many organizations still cannot release working software on demand. Instead, it often takes multiple sprints lengths to put working software into production. Future-ready organizations develop the ability to bring high-quality software to production instantly.

Why? Because too many activities are delayed until after the sprint although organizations experience an ever increasing need to deliver value to production. This article takes you through the most important pain points IT organizations experience when putting quality software into production. Next, we suggest a series of next steps to start addressing these pain points. This will help organizations to get a very important trend at their fingertips: organizations bringing high-quality software to production instantly.

On-demand software delivery without proper execution of development and testing activities is prone to failure. The goal of software testing as a discipline is to verify whether we built the thing right and to validate whether we built the right thing.

Building the thing right relies on continuously challenging of functionality using a conscious and critical mindset. Automated tests serve as a safety net, but these checks merely show you that software development is not done yet for a current sprint. The real question is, are we building the right functionality that helps us increase market share, outperform the competition, or, ideally, both? A strong role of the product owner and organized continuous stakeholder feedback in combination with techniques such as impact mapping, example mapping, and specification by example are necessary ingredients to understand your organization is building the right thing.

Building the right thing that sound and unambiguous specifications exist for the functionality and are used to continuously check whether the software conforms. Organizations should rely as much as possible on automation to speed up the feedback while developing the software. In other words, there is not much use in putting broken software into production. So, organizations need to combine a balanced spread of automated tests across the various levels of your source code (units, components, integration, end-to-end) with clear insight into test coverage to gain confidence that they are building the thing right.

A combination of both is the way to go. Organizations that do not adhere to an automation mindset will spend their effort in verification and find they do not have, err, allow themselves the room to focus on validation and genuine product improvement. Only then can organizations and agile deliver quality software instantly.

The existing status quo: Pain points in software delivery

Organizations that apply continuous delivery and agile principles can still suffer from a heavy-weight testing process. They typically suffer from the following:

Inefficient organization. Often, the testing process occurs entirely separated from the delivery process. Typical symptoms include:

• Only testing after they’ve built the software; putting findings from the testing process on the backlog then re-inserted in a future sprint, stalling innovation; spending time on fixing bugs rather than developing new functionality.
• Different development team members do the testing, test-only testers. These team members are busy at the end of a sprint (in the case of an agile process), or need to be assigned to the IT project when it’s “testing time.”
• Often, acceptance testing is an entirely black box procedure where users or user representatives define acceptance test scenarios which enter the party quite late, that is, during the acceptance testing phase before a release.

Lack of tool support. Without proper use, it takes days or weeks to set up the environments, install the correct versions of software and services, load appropriate test data, and run the tests. The more effort it takes to set things up, the more likely it is for test results to be flaky and unreliable because of the manual actions performed. Tools can rectify all these effort-prone activities.

No acceptance-first approach. Partly due to the positive mindset and optimism bias, teams are lacking sharpness and focus. An acceptance-first approach describes the desired features in terms of acceptance criteria - features not described as such will simply not be delivered. Using modern yet widely available tools, teams have a laser focus on ‘done’ and in this way can prevent overestimation of their and underestimation of the risks and costs.

Next Steps for Tomorrow - Start Escaping the Testing Quagmire

Feedback is the real cornerstone of every delivery team. Only with the appropriate feedback can agile teams deliver high-quality software instantly. Setting up an immediate quality feedback process encompasses a series of actions:

• Make testing and test automation an integrated part of the software development life cycle. Consider the following activities:
• Amp up your existing continuous delivery pipelines to make all test automation solutions an integrated part of it. Include unit tests, integration tests, and end-to-end tests, and remove all variances in test environments, test data, test execution, and reporting.
• Whether or not you are using a test-first approach, develop a well-balanced test automation pyramid with a sound basis of unit tests, integration/service tests that cover separate functional chunks of the app, and a minimal set of dedicated end to end tests. Each of these tests should rely on the feedback of earlier tests, as such preventing implementation of unnecessary or duplicate tests.
• Grow and nurture a whole-team, agile-quality mindset. Starting with the role of the product owner, write down user stories as executable specifications so tools can be used to automate the checks for these specifications. While being delighted by the feedback, spend valuable team time answering the following questions to grow this mindset:
• What’s the definition of ready and done according to the quality of user stories and delivered functionality? How does the team continuously verify this?
• How does the team receive quality feedback in a matter of minutes rather than hours?
• What’s the expected behavior of individual team members in striving to achieve the team’s charter? Are we encouraging, rather than criticizing, to get the most out of each other?

Where to start?

Although the desired end-result may be clear, it is often cumbersome to start improving. Organizations experience existing ways of working, structure, and internal boundaries that are around for years. How to flip this script? Start small, but be thorough.

Take a vertical slice of a business process, address the complete value chain, and improve by doing the following:

• Create the smallest end-to-end responsible team possible.
• Sharpen the agile mindset towards an acceptance-first approach; for each new user story, develop at least one (or two) acceptance tests, ready for automation. Let the team develop the failed automated test first, and stop development of functionality as soon as the automated tests reports “green.” In the case of defects, develop an automated test that repeatedly exposes this failure first, before the team fixes the error.
• Ensure that new functionality can be developed and tested in isolation. Use a strategy to mock away additional context.
• Be prepared to run all automated tests all the time. If things get slow, improve the feedback cycle by refactoring tests, or adding more (virtual) horsepower.
• Eliminate. All. Manual. Repetitive. Tasks. Adopt a radical automation approach for the slice, and don’t take compromises. Show it can be done!

This article is part of the Urgent Future IT Forecast 2017.