Almost all software executives I speak with are struggling with speed. Everyone feels the pressure to deliver more value in a shorter time and faster cycle.
Speed is not only about how fast you get things done but how fast you really get those new things out for the customers. If you had to release a new version every single day or even week, would you be able to do it? Or would you have to courage to do it?
What happens when you pass the speed pressure on to your software teams? Most probably, they’ll start cutting corners to get things done quicker. That means accumulating what is known as technical debt. That, in turn, will accumulate risks. With good luck you may get something out sooner but - as good luck won’t last forever - the pace of your releases will inevitably slow down.The three main things you can do to make things faster with fixed resources are automation, eliminating waiting, and eliminating rework. Automation of slow activities, such as build, testing, and release to production may, indeed, eliminate a lot of work and human errors. But automation can only take you so far.
While automation is a necessary enabler for higher speed the real key to acceleration is in eliminating slowness rather than doing things faster.The easiest place to reduce waiting and rework is the testing cycle. Typically, testers first wait for something to test. Then they test it: automated tests check that what works yesterday works also today while new, manual tests try to find defects in new functionality. Once done, they analyze and report their findings. This may be slower than anticipated because automated tests often need maintenance, manual tests need human work, and at least some of those new manual tests have to automated, too. The quality of your test automation solution and the design of the testing flow make a big difference in speed.
Meanwhile, your developers probably don’t wait. While waiting for the test results they keep building new code on top of existing one - that was buggy: time and effort wasted, at least partially. The test turnaround time matters a lot. What matters even more is the number of open bugs. The buggier the old code the buggier the new code built on it.
In modern software teams, developers often do testing and automation by themselves. Same phenomena of waiting and rework apply. All the time they spend on testing, fixing, and maintaining tests and test tools, is time away from writing code for the customers.
Software teams sometimes reach a state where the number of new bugs found keeps growing faster than the number of bugs fixed and verified. This should ring the loudest of alarm bells. Once this stage is reached, any attempt to speed up will deteriorate the performance even further. Yet, few leaders have the guts to slow new development down although it is the only thing that helps. Speeding up an overloaded team is like forcefully increasing the clock-speed of a CPU: it will burn.
Speed and quality work in tandem. It’s impossible to accelerate speed with poor quality. Likewise, and maybe surprisingly, teams that are able to deliver at a fast pace tend to deliver best quality, too.
Want to try out test automation right away? Start testing now and create own robots with few easy steps.