Should companies invest in agile engineering practices—training people on their engineering teams and giving them time to improve? And if they should do that, how much should they invest?

In this article, you will learn why it makes sense for companies—from a business point of view!—to allow their developers to grow professionally, to help them grow and to invest time and money in ways to improve the skills and practices of their teams.

How do You Spend Money Now?

Imagine a company with a very traditional release process. Maybe the process I describe here does not exist anymore, anywhere in the world, but bear with me - I am trying to generalize the conclusions later. Also, I doubt that it does not exist anymore…

When this company prepares for a release, they manually test the code for regressions. Several testers work for two weeks to manually “execute” test plans and check whether everything is still working. While they are doing that, developers fix the defects they find and they also work on some emergency, last-minute changes.

Because the developers do not stop deploying new code, testers often have to execute a test multiple times. They have to re-test when a defect was fixed or when that emergency change was deployed.

The software, on the other hand, grew so big that it cannot be manually tested in two weeks anymore. So, testers select a subset of the available test cases for regression testing—based on some rules and heuristics.

That Money is OPEX - It’s Gone!

That money you spent manually testing your software is an operational expenditure—money you spend to keep your business running.

After you got the release out of the door, the money you spent is gone. And the value it created (knowing that your software does not contain any known regressions) is gone too! As soon as you change a single line of code, you must run all those tests again.

OK, theoretically, if you had a really good software design, you might not have to re-run all of those tests. If your design was cohesive and loosely coupled, if it protected parts of your code from changes in other parts, if the design ensured that changes did not have unexpected side effects and ripple effects in other parts of the code—if you had such a design, you could analyze which parts of the software are effected by a change and only re-run those tests.

But if that company does not have well-designed, fast, valuable automated tests, the software probably also does not have a great design in the rest of the code—I would even bet that it’s quite the opposite.

Not because it’s impossible to create a great design without having tests. But because oranizations either care about both—great tests and great architecture/design—or they care about neither.

Great Design? That Still Wouldn’t Work!

So, you wouldn’t have to re-test if your design was so great, right? That only works when your changes are tiny. When the changes grow bigger or when you accumulate multiple changes, you will soon reach a point where you again have to regression-test everything because analyzing all the areas to test would become too costly.

You would have to ship often, after every tiny change, to make this testing strategy viable (if it would work at all).

But because of all the manual work, releases are too costly to do them often in such an organization.

Can You Turn it Into an Investment?

When you invest the money and time you currently spend on manual regression tests differently, you can turn that money into an investment. When you spend the money on automating tests, the value you create accumulates and becomes bigger and bigger over time. What you create while spending the time and money—an automated regression test suite—will provide value long after you wrote that automation code.

The test suite will reduce the cost of creating a release and speed up the process considerably. It will catch regressions that would otherwise have escapted to production because it suddenly becomes possible to execute all the tests multiple times during a release—e.g. after each bugfix.

When releases become cheaper and faster, teams can do them more often. They can release smaller changes to production and get feedback earlier. They will learn faster what product their users need and not only build what they requested. Time to market for new features decreases.

When teams can release at the push of a button and do it often, there are not “hotfixes” anymore. A problem occured in procution? The fix is just a regular release!

And your testers will finally have time to do exploratory testing and to support product owners and developers in finding edge cases and use cases they forgot—Activities that provide a ton more value than doing manual regression testing!

(But beware of bad tests and the TDD Trap!)

How Can we Generalize this Example?

I took the example above to the extreme. Many companies do not have that slow, manual-only release process anymore (but I bet that there are quite a few companies that are still closer to this than to continuous delivery).

But even if your team does not have this exact problem anymore, are there any other areas where you spend money on a regular basis that you could turn into an investment instead?

I am sure you can find some areas where your team could improve next. And if you want to talk to someone about it, contact me!

But we Cannot Just Stop!

The company that has the fully manual process above—they cannot just stop doing manual regression testing and spend the money on automation instead. It takes some time, maybe even a long time, to get to the point where the automated regression tests provide more value than the manual testing. If they just stopped testing manually, they would not be able to ship software anymore, potentially for a long time.

So, they need to do all at the same time: Invest in training developers and testers in how to create good automated tests, automate tests, continuously improve their test suite and do all the manual regression testing for a while. They would get a lot less done during that time.

They would need to slow down to become faster. And many companies (or managers at companies) are not willing to do that. Probably because the system they are in prevents them from doing the right thing.

Now, that’s a downer ending, right? And I don’t have a perfect solution for it, especially when your management does not give you the time to work on getting better. But you can start in little steps. Have a lunch and learn. Start to write an engineering notebook. Write some tests. Draw some diagrams during your next sprint planning. Discuss quality with your coworkers and managers.

And with this blog post, I wanted to show you that there’s a business case for improving the engineering skills of software teams: Doing it right is an investment that will accumulate value over time! Maybe you want to talk about that in one of your next retrospectives…

Need some pointers where to get started? Check out my book about “Agile Engineering Practices”!