How Agile Do You Have to be to be Considered Agile?

[Guest Post]

QA managers may struggle with landing on a clear definition of a truly agile team.

Given how quickly word has spread about the benefits of agile testing methodologies, it’s no wonder that quality assurance managers everywhere are considering making a change to their test management strategy. Agile can seem like a nebulous concept to some individuals, however. Despite the existence of the agile manifesto, some confusion remains regarding what it means to be truly agile. In addition, QA teams may leverage their own approach to implementing these processes, with some taking too many liberties with agile principles

Kaizen - Continuous Improvement
Kaizen – Continuous Improvement

while others adhere too closely to the letter of the law. With so much uncertainty, team leaders may find themselves asking, “How agile do you have to be to be considered agile?”

When determining a team’s level of agility, it’s important that managers don’t get bogged down in the details of the methodology and instead focus on its overarching principles. Agile Zone contributor Nitin Bharti explained that there are several key characteristics that define an agile team, most notably the ability and willingness to alter an application as needs arise. It may become necessary for QA members to make changes to in-development or recently released software because the current product does not adequately satisfy end users. That is why user feedback is so critical to agile teams and should be collected and reflected upon with regularity. Truly agile teams continually strive to improve not only their programs, but their internal processes as well. Agile QA managers should never feel complacent with the current makeup of their team or strategy and look to enhance both whenever possible.

Embrace customization, improvement

Although the agile manifesto clearly spelled out the overarching ideas at the heart of the methodology, that doesn’t mean test team leaders need to be slaves to the details. Customization is an inevitable and entirely necessary result of going agile. Team leaders will quickly learn that not all processes are ideal for their specific organizations and will need to make changes while still being true to the spirit of agile. Fellow Agile Zone contributor Matthias Marschall suggested that agile adopters drop any features that either aren’t working for them or are just not gelling with team members. These may even include processes that are closely tied to agile such as daily scrum meetings.

“While there are certain basic principles you should keep in mind, you need to experiment with the processes you use to organize your work,” Marschall wrote. “By observing how your experiments influence your work, you can learn and adapt. … Customize your process according to what you learned from your experiments. You don’t need to care about whether you’re still allowed to call it scrum or whatever. The only thing that counts is whether you can create more value, faster.”

At the end of the day, there’s no one true measure for a team’s level of maturity when it comes to agile. Customization will always come into play, making every implementation unique. It’s important that QA managers stay focused on adhering the core concepts of the methodology and continue working to improve their test management strategy whenever possible.

Sanjay_Zalavadia[About Sanjay Zalavadia – Sanjay brings over 15 years of leadership experience in IT and Technical Support Services. Throughout his career, Sanjay has successfully established and grown premier IT and Support Services teams across multiple geographies for both large and small companies. Most recently, he was Associate Vice President at Patni Computers (NYSE: PTI) responsible for the Telecoms IT Managed Services Practice where he established IT Operations teams supporting Virgin Mobile, ESPN Mobile, Disney Mobile and Carphone Warehouse. Prior to this Sanjay was responsible for Global Technical Support at Bay Networks, a leading routing and switching vendor, which was acquired by Nortel.]

HT: Zephyr

2 Replies to “How Agile Do You Have to be to be Considered Agile?”

  1. Thanks for sharing this great article.
    I totally agree with the need to customize. “inspect and adapt” a basic principle and a major purpose for most of the Agile ceremonies.

    What I see as the flaw in the article besides not recognizing that “inspect and adapt” is at the core of Scrum is that neither Agile or Scum are methodologies. They are frameworks, values and principles. The methodology that an organization implements is totally customized to and by that organization. The issue is to what extent does your organization scale Agile, and that dictates much of the methodology designed and implemented for every part of the scale.

    Also, I do not believe that QA should be absolutely supreme, QA should not be the sole decision that “It may become necessary for QA members to make changes to in-development or recently released software because the current product does not adequately satisfy end users.” (and does the author really mean is said …”QA members…makes changes to… software” …). “Members” is a key word here (though maybe not for the author) as in members of a larger team that includes people who are part of the QA functional group.

    However, call it what you want, but if the implemented methodology does not subscribe to the “Agile” values and principles, don’t call it “Agile”. If the methodology does not subscribe to the “Scrum” ceremonies, don’t call it Scrum.

    Just my 2 cents.

Leave a Reply