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 more documentations. So I halt for a moment without making any judgment about what they are doing at the moment whenever they told me that. I then asked them whether they deliver completely functional software in short time period. And they said "No". I then start questioning 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.
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 really 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 will not guarantee that customer will always get what they want because it is just documentations. It is the software that the customer will use, not the 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.
There are many articles available on the internet and many books available on the market that explains how to be Agile in a Sprint without falling into mini-waterfall trap. But if you really want to experience how to do continuous testing inside a Sprint, the Professional Scrum Developer program from Scrum.org is the hands-on and practical training you would be looking for. I happen to be one of the trainer who is teaching this program throughout Asia Pacific. I have received enormous feedback how this course has helped people understand how to become Agile by using modern engineering practices. 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 software 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 development instead of helping them to become Agile.
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? In Visual Studio, it is currently shipped with many testing suite out of the box ranging from code level unit test, Coded UI test to load test. And if you have a Product Owner who likes to write specs, you should also add Specflow on top of your testing suites.
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.
I have to admit that out of all of Application Lifecycle Management (ALM) practices, testing (software) is the hardest out of them all. Automating tests is even harder, especially when your code base is growing at a fast rate. But this is not a reason to discount automated tests for our software. How will we know the reliability of our software if there are no automated tests? It takes (years of) practice to be able to get used to automated tests. Management should support their developers to write automated tests and developers should be professional and write these tests. Delivering (brittle) software to your customer, no matter how fast and how often you do it, is not Agile.
In the end, Agile is not about what you are not doing anymore. Agile is not a fad. 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. I believe Agility has no end state. We keep striving to be Agile. Agility Path from Scrum.org is a great tool to help you see where you are at the moment with Agility. So if you are already using Scrum or any other Agile methods, keep challenging the choices that you’ve made and keep increasing your Agility. Do not make any shortcuts to be Agile. It takes diligence and patience to be Agile.