Who do you think would win this fight? Many of you might say Chuck Norris, no contest. But if I may be so blunt — you’d be wrong! Bruce Lee would win this fight, hands down! Heck, he could win with his hands tied behind his back!
The same goes for the agile method. Some people will swear up and down that agile is the reason their project failed while others feel just as strongly that this methodology was the best change they could have made to their projects.
There are many ways an agile project can fail, though. In this post I’ll explain what can be done to avoid one of the most common mistakes.
I strongly believe that Implementing Agile test driven development is one method to help your project succeed. There are some important roles in agile methodology, such as the product owner and scrum master. The product owner is not only the person who knows the business rules, but also the one who drives the features of the software. Agile is about delivering shippable software that works how the user needs it to work. The product owner needs to be an expert in their field, but I also believe that knowing how agile works will greatly benefit them as well.
A way to help the product owner express the business rules without knowing its implementation details is called the Gherkin language. If we invest time training a product owner to learn this business-readable language, it will help the project succeed. Since agile is all about delivering the right software to the right people, we need this communication between the users and the developers. From my perspective, this is the key. We need to coach the product owner in this because it is an effective way to communicate with the scrum master, testers and developers.
“Do The Simplest Thing That Could Possibly Work.”
― Kent Beck
I have been a developer since 2006, and I am not going to lie. I never thought I could say something would work without writing the code first. My mind spun 360 degrees when I tried do tests first. I honestly was not able to understand why someone would write tests first. It was pretty hard for me to come around to this way of thinking. As a coder, I always wanted to write the code first to make it work before thinking about the test. It is still hard but I have to admit, writing tests first actually does work. It’s totally changed the way I view the coding side of things. The perfect world would be to write 100% of tests first. On the other hand, writing 100% of tests first is still almost impossible. For example, if you’re trying to refactor a generic pattern on the backend code, I don’t think that could be done with the test first approach. I need to emphasize that in the real world there is the possibility of 100% of tests first based on gherkin language.
On the other hand, I have to share my own experience about not writing tests first. It is always hard to fix code that has been written the old fashioned way, without test driven development. The only person that could actually fix this type of code would usually be the one who wrote it. Given that, the first inclination from an outside coder would be to just rewrite the whole thing instead of trying to fix it. It would take less time that way.
Agile is about speed, productivity and reducing unnecessary cost. It is also about shortening the gap between the unknown and unexpected problems that happen along the road to success. Agile and test driven development helps minimize that gap between developers and product owners. It helps focus on what the product owner actually needs.
From my perspective, agile is linked to Test driven development. In a study conducted by the Department of Computer Science, North Carolina State University, they emphasize great results from using agile practices with tests driven development. “Our data indicates that the TDD practice can aid in the production of high quality products. This quality improvement would compensate for the moderate perceived productivity losses on the Sustained Use of a Test-Driven Development Practice at IBM. Using this practice, these teams were able to deliver robust software. The case study shows the difference between a team who used TDD in agile practices and a team that did not use TDD.
Tips To Remember
Train your product owner on how to write acceptance criteria using The Gherkin Language
Don’t allow developers to use the excuse of not having time to write the tests
Never stop doing retrospective on the project
If developers are not doing Test Driven Development, train them
In conclusion, if you are implementing the agile methodology, I think you should train the team before getting involve with TDD and the Gherkin to make your project successful. Training your product owner and developers in this methodology is a great step if you want to create a robust software. Agile is not only about developers, testers and scrum masters, it involves all aspects of software development. Get involved with Agile and Test driven development now!
Tags: Agile, Gherkin, Test Driven Development
“Nobody said that creating software was easy!”