What’s the Buzz Around “Agile?”
If you’ve set foot into the world of software you’ve probably heard the word “Agile” more times than you can count. You may have heard this word associated with constant collaboration, continuous delivery, releasing faster, adapting constantly, or any other “features of being Agile.” It is clear that teams who are involved in all phases of the software development lifecycle are starting to adopt this “Agile” methodology as its increase in popularity continues to grow at a fast rate.
Earlier this year, over 5,000 professionals in Software Development, QA, and Testing responded to the SmartBear 2017 State of Software Testing Survey, and one of the most intriguing areas of the survey results was on this idea of being “Agile.” Through this survey we asked teams to categorize their development styles as either Agile, DevOps, Waterfall, Dependent on the Project, or Other and some results we found were expected while others were surprising.
Our first finding that was expected was that DevOps teams are releasing multiple times a day; comparatively much faster than those who defined themselves as anything but DevOps. However, and this was something truly noteworthy, there was no significant difference between release cycles for teams that defined themselves as Agile versus those that defined themselves as a team using a waterfall methodology. In fact, teams that followed a non-Agile model, not including DevOps teams, were more likely to release daily or multiple times a day than Agile-based teams. This shocked us! Wasn’t a key part of being Agile releasing more frequently? This made us step back and think… what is the true definition of the word agile in the context of the software development world?
A Brief History Lesson
The term agile came from the Agile Manifesto where seventeen leaders came together at the Snowbird Ski Resort. At this meetup, the leaders started to think about a new approach to software projects. This approach focuses on being feedback-driven where the people who are driving the project are the ones doing the work. The authors of the Manifesto came from many areas of software development from extreme programming (XP) to Dynamic Systems Development Method (DSDM) and the co-creators of Scrum, however it was Brian Marick who summed up the ideas: “The software people have figured out how to build systems; please let them do it.”
There are twelve principles that make up the Manifesto describing what exactly Agile is including changing requirements, shipping software frequently, and the idea that face-to-face conversation is the most effective way to convey information. With this Agile methodology comes the need to test in a more effective and efficient way. The Agile-testing process needs to be fully integrated into an Agile software development methodology to truly achieve the 12 principles laid out in the Agile Manifesto. How can this be possible? Some solutions may include diversifying your testing suite, incorporating automated testing where possible, continuously testing, and being able to adapt to ever-changing conditions and requirements.
Fast-Forward to Today
Many teams have begun to incorporate strategies to accelerate their testing pipeline. First and foremost, teams have begun to start automating more of their tests using the test automation pyramid as a reference, automating more unit tests and fewer API and UI tests while still recognizing it is near impossible to completely be rid of exploratory testing altogether. Additionally, teams have started using continuous integration tools so they do not have to constantly rebuild the wheel and can integrate their workflows with tools they are already using. Another way teams are trying to test faster is through constant collaboration such as holding Three Amigos meetings where a developer, tester, and product owner get together to constantly provide feedback to one another on what works and what didn’t work.
But Is My Team Really Agile?
So, this leads us to the question posed today: Do you need to meet all 12 principles to truly be considered Agile? Is speaking the Jira lingo, working in sprints, and having constant communication between all parties invested in the project enough to mean you are practicing an Agile methodology? Do integrating with Jenkins, having small teams, learning quickly, and constant adaptation mean you’re Agile? What if you are doing 11 of the principles but you are still releasing on a quarterly basis; are you Agile?
I think it’s important for all teams to consider what their true definition of Agile is. As Agile continues to increase in popularity every team should know the Agile that they want to practice. Maybe teams who are using Agile-marketed tools, incorporating continuous integration tools, and using all of the Agile best practices do believe they are Agile even if they are not releasing faster—and if that’s is the case, that’s okay. However, if teams think there is a clear need to be Agile, and that the only way to truly be Agile is by meeting all 12 criteria of the Agile Manifesto, teams need to think about best practices moving forward.
As I mentioned above, one finding that came out of our studies is that teams are not as Agile as they think they are. And this is okay. I challenge all teams who consider themselves Agile, whether or not you took this survey, to reflect back and think about the important principles of being agile. Maybe you thought you were incorporating all of them but there is still room for improvement. Maybe you thought you were an Agile team but are practicing more of a waterfall methodology meaning you can find better tools to support you in these efforts. Whatever the case, it is important to take a step back, look at how your team is functioning, and ask yourself… is the way we’re working today the most effective and efficient we can be?
Tweet this article.