An Advantage of Agile Development: The Ability to Consistently Test in a Real-World Environment

An Advantage of Agile Development: The Ability to Consistently Test in a Real-World Environment

There is nothing like running a process in a real-world scenario. Trying the process itself is better than any amount of thinking about all the possible issues that could arise. 


I’ll give a simple example to demonstrate this, and then explain how this applies to agile software development.


Test driving a car.


While obviously I know that the car will drive, turn, and brake before I drive it, but by using it in a real life environment I may notice that the car also has some safety features like ‘Lane Departure Warning’ or ‘Blind Spot Warning’.


And even if I tried to think of all the possible features I would want from, or need from the car, I wouldn’t come up with every feature. 


In fact, I once bought a car and after owning it for a couple of months I needed to drive 4 and a half hours to Penssylvania and back. On the way back I put on the cruise control expecting it to have ‘Adaptive Cruise Control’ (which means that the car uses lasers, radar, cameras, or a combination of these systems to keep a constant distance between you and the car ahead, automatically maintaining a safe following distance, thereby making driving long distances much easier.) but realized it only had basic cruise control. I was frustrated because at the moment I really needed ‘Adaptive Cruise Control’, and I had expected it because my old car had had the feature. 


But I never thought to ask about that feature when purchasing the car, because I didn’t think of the need until I experienced it in real life.


(We see a similar example in the SaaS industry, that most SaaS’s offer a free trial period, because having the prospect use the SaaS in their business for a little while shows the prospect how useful the SaaS is to them, more than anything else)


Now, how this applies to the agile software development methodology you ask? 


Well, in agile development, instead of creating the entire product from start to finish, the product is built and tested step by step. Therefore each step can be tested in a real-world scenario as soon as it is developed and allows you to learn from the testing. (This is commonly referred to as ‘build, measure, and learn’)


And therefore, through using that part of the software in its real life environment, it allows you to see if that part of the software actually accomplish its goals the way it was intended to. Or if it gives room for errors and can use improvements.


But if the entire product is built out and only then it is tested, it makes it very difficult to pick up all errors and possible areas of improvement.


I’ll tell you an actual example we recently went through while doing product management for a client’s software that demonstrates this idea well.


We were building a custom ERP for a manufacturing business and were working on the part of the process that went from manufacturing to shipping. We released a working version for testing. The person tasked with running the project at the company went through the entire process within the software and was happy with the results.


Then we began testing with the actual users, the employees who would be using the software day to day to carry out their jobs.


Everything was going great.


But then while we were doing the walk through with the warehouse staff, as they carried out the process we realized a fatal flaw.


After the goods were manufactured and packed into a box the worker would just stack them up behind him. But the boxes had no information on them, and therefore It left a huge gap for error of orders being mixed up, orders shipping incomplete etc.


So we worked in a development requirement for the next sprint that would automatically print labels with box information when the box is marked as packed. That way any passing employee could easily identify which order it related to should it get misplaced.


Now, if we would have not tested things at this stage and instead continued on developing, than we would not have picked up on this issue. Because the software itself worked. And the chances of recognizing that area of the software that left room for error is slim when testing the entire product.


But months down the line, after a few errors of orders being mixed up and thousands of the business’s dollars being wasted, we would have then had to come in and identify where in the process is the issue coming about, and only then find a way to fix things.


But testing it in a real-world scenario at that stage allowed us to pick up the issue before it ever happened, and let us identify exactly where in the process needed ‘fixing’.

If you need more help using software to grow your business I’d be happy to help!

Contact me at:



Mendy Donin


Email us or Schedule a call at your convenience.