You are not Agile if you are not automating tests
Over the years I have seen many people who claims to be Agile when they’re really not. Agile is seen as a fad. You are not cool if you are not Agile. Everybody wants to be seen as Agile. Most of the time I had conversations with those who claims to be Agile, they told me that they are now Agile because they do NOT write any documentations. I then asked them whether they deliver completely functional software in shortest time period possible. And they said “NO”. I then asked myself how can you possibly be Agile if you are NOT delivering early and often to your customer?
So before we go any further, let’s take a look at the definition of Agile for a moment.
Agility (n.)
An enterprise’s ability to take advantage of opportunities, respond to challenges, and to do so while controlling risk.
To be quick and nimble.
When we look at the definition of Agile, it is about controlling risks and to do this fast. But how can we control risks if the software is not delivered early and often? That is like keeping the risk to remain high until it is shipped. Some organisations who are still doing Waterfall try to control risks by creating comprehensive documentations. But we know that the quality of the documentation does not reflect the quality of the software and these comprehensive documentations does NOT guarantee that customer will always get what they want because it is just documentations. Without delivering early and often, the risks that the software is not as what the customer expects will remain high until it is shipped. And if things do not go well altogether, the risk may never drop.
But we are at better state now. There are many organisations who are delivering in short cycles. Most of these organisations are using Scrum and they often deliver to production every Sprint. There are many happy customers and happy developers after Scrum is used for software development. But most organisations who are using Scrum are not really Agile. But how can an organisation who are using an Agile method can be called as not Agile?
Despite its simplicity, Scrum is actually very hard. Some organisations even gave up in mid-course because when they first encounter Scrum, they think that Scrum is only about standing up every morning, meeting the customers every 2 weeks and a bunch of sticky notes on the wall. Due to its difficulties, people try to fit in what they already know into Scrum. One thing they did is by treating a Sprint like a mini-waterfall: gather user requirement in the very first few day of the Sprint and test at the last day of the Sprint as shown in the graphic below.
This may work, maybe for a very few Sprints, but I can tell you that it is not Agile. If we go back to the definition of Agile, which is mainly about controlling risks, this approach is actually still very risky and not much different to the traditional Waterfall approach. Some team could not finish all of the testing they’re supposed to do before the Sprint finishes, some take extra overtime at the last day of the Sprint or some even cancel the Sprint Review because the software is not ready to be reviewed for Sprint Review. It is very risky to deploy a software that is not continuously tested because there are many technical debts inside the software. Most people I met are wondering how is it possible not to do mini-waterfall? Most people I met think that it is very natural in software development cycle to do the waterfall approach even if we have shortened the timeline to two weeks.
If you really want to experience how to do continuous testing from the beginning of the Sprint, the Professional Scrum Developer program from Scrum.org teaches you how to do it. From this course many people have understood that Scrum is more than just sticky notes on the wall and standing up every morning.
I have also met many Scrum developers who hate Scrum because as the development progresses they can only develop small number of features and do many manual regression tests for all of the features that they have developed in the previous Sprints. And they blame Scrum for slowing down the development process.
The problem is not really about Scrum, the problem is there are no automated tests. How can they possibly blame Scrum for something they choose not to do?
Despite the promise from automated tests, both managers and developers do not see any value in writing automated tests because it is taking too much time to write it. They argue that it is taking them twice as much time compared to not write it. If time and cost is the only measurement used, then I can see why some people can not see any value in automated tests. In the manufacturing world, it is unacceptable to sell a not well tested product to the market because people can die from a not well tested product. Infact there are people found dead because of software. In manufacturing world, it takes rigorous testing and checking to make sure that the product does not do any harm to the customer. Why should it be any different with software development? If there are no automated tests, then it is very risky for the customer to use the software hence the software actually has little value. So if that is the case then there must be values in writing these automated tests.
Agile is not about what you are NOT doing. Agile is NOT a fad, it is a necessity to be able to compete in the ever changing market. Controlling risks is not a fad. Bringing value to your customer is not a fad. You can’t say you are Agile because you are not writing any documentations and at the same time not writing any automated tests. Agile is not about making shortcuts. Agile is about a state of mind where you keep challenging the choices that you’ve made. Agility has no end state. We keep striving to be Agile. Do not make any shortcuts to be Agile. It takes diligence and patience to BE Agile.
If you are looking for a Professional Scrum Developer course, please check out the public courses I run. I run public courses in the Philippines, Singapore, and Perth.
Other references:
