If you are new to agile software development or even have been doing it for a bit, you might be wondering how agile is your team is and more importantly what does being agile really mean anyway?
Agile software development is an approach to software development that helps to deal with changing requirements. Agilists do this by working in short iterations and focusing on the most important value that can be realigned to changes at each new iteration.
So maybe your team is writing stories, doing sprint planning and running sprints. Congrats, that’s a big step in the right direction to being more agile!
Agile teams need to be able to respond to change and adjust dynamically as the system being built evolves over time. However, software teams might find they have a great initial velocity, but after several months it becomes harder and new features and changes take longer than before.
However, one of the telltale signs of an experienced agile teams that can constantly deliver over a long period of time can often be attributed to the automated tests that have been implemented. Your agile team is doing automated tests right? If not, agile teams should have automated testing at the center of their development process or the team’s velocity is going to hit a critical mass and will start to slow down after a time. While it might feel great to be breezing through stories quickly and slapping together quick applications, there is technical debt that will have to be paid back later or the project could run into the risk of failure and come to a slow crawl.
Symptoms of not having automated tests:
Developers have fear modifying code because their changes might break something. Modifying one feature breaks other features in unexpected ways. Nobody really understands what the code does and why it was written. It takes longer to test new functionality than it does to implement the new change. The value of a new feature is not worth the cost and time it takes to implement it.
What Tests Do We Really Need? Acceptance Criteria on a story is used to help determine when a story is done. However, not all acceptance criteria have to be converted into automated tests.
Done should be defined to fully determine when a story is really done. As part of this definition of done, the type of automated tests should be agreed upon by the entire team.
It is very common for seasoned developers to naturally implement unit tests. However, maybe the project doesn’t even have automated acceptance tests or solid integration tests. While this kind of testing is great to have, every project is different and the team should internally determine the level and kinds of automated testing that will be needed before the story is really done.
If your team is not currently doing any automated tests, begin slowly and perhaps by adding some unit tests. If you already have a large application, it can be very time consuming to try and go back and add automated tests to all the existing functionality. Instead start by adding unit tests as new stories are worked on. Over time, the system will start to have more and more automated tests naturally as part of the process. If certain areas of the application are always having quality issues, perhaps a strategic plan to add automated tests around these features is needed sooner.
Introducing solid automated tests to a project can be a challenge. The reward for doing this correctly has great benefits that resolve many of the symptoms listed above. Developers will no longer have fear to modify existing features, because the tests will ensure that the current functionality is not breaking. Testers will spend less time on manually regression testing, and instead focus their efforts on new features. Most importantly the team can respond to change and maintain a consistent delivery velocity and be agile.
Please contact us about your project and let us know how we can help.