Agile Adoption

You are here:
Featured-image
 

 

In February of 2001 a small group of software development pioneers and thought leaders gathered in the mountains of Utah to create a set of four key values and twelve principles better known as the Agile Manifesto. Over the past nine years these ideals have grown throughout the software development community to spawn “agilistas” throughout the world as well as a host of conferences focused on agile concepts.

Zenergy Technologies exhibited at one of these conferences last week in Las Vegas, the Agile Development Practices Conference. Hosted by SQE, publisher of Better Software Magazine and StickyMinds, this conference provided the leadership at Zenergy a chance to do one of its favorite things: take the pulse of the software development community, specifically, a segment of the agile populace.

As attendees visited our booth in search of information about our company and solutions, tchotchkes, and the iPad we planned to give away at the SQE drawing, although not necessarily in that order—we know most people just wanted the iPad; we wanted one too—we took the opportunity to ask them how long they had been using agile methodologies. While our survey was by no means scientific, the answers pointed to the fact that the majority of attendees we met with had been using agile for about 18 months, long enough to begin to feel at ease after having stepped outside their comfort zone of the traditional waterfall methodology, but still new enough to experience a variety of challenges. Three challenges in particular were popular topics at our booth:

  1. Automating tests in an agile environment—Using home grown, open source, and purchased tool sets
  2. Executing performance testing during iterations
  3. Integrating the test team into agile adoption processes
 

Test Automation in an Agile Adoption

 

In the area of test automation, attendees had questions about when to automate, who should do it, what tools to use, the frameworks that best work with agile, and multiple others. There is no one best answer to any of these questions. It depends on the context of the particular organization, but, generally speaking, we favor automating as many tests as possible in an agile environment, certainly at the unit level, but also at the functional and regression levels. We are tool agnostic at Zenergy when it comes to functional automation and seek the optimal automation tool that fits the technology tested, the talent of the people available to create the tests, and the organization’s budget. Also, we recommend low-maintenance automation frameworks such as data-driven, modular, and action/keyword based approaches, but in agile there are times when “throwaway” or record & playback scripts may suit the needs of a specific iteration. Again, to succeed, the right solution must be context driven, which is why it’s important to perform a strategic automation review before you advance too far down the test automation path.

 

Performance Testing in an Agile Adoption

 

Performance testing can be a significant challenge in an agile adoption because of the need to operate in short iterations and complete most functional tests prior to stress testing—ensuring functional defects aren’t the cause of perceived performance issues—as well as devote time for setup, execution, and analysis of the performance tests. That can be a lot to squeeze into a 1-2 week iteration.

On the performance side, Zenergy has established a strategic partnership with Reflective Solutions and its StressTester tool. Although StressTester may not be the appropriate performance tool for all agile projects—the current design is for Web-based applications only—we do view it as an affordable and robust performance tool. An added benefit is its quick and easy setup utilizing an intuitive interface for test script creation. These User Journeys, as they’re named, don’t require scripting expertise to develop. The benefit in agile environments, along with ease of setup, is that it allows non-technical team members to create and execute the scenarios, leaving analysis for more technical team members, which means more collaboration and improved task allocation across the team.

 

Integrating Into Agile Teams

 

At the show we had several conversations regarding how numerous testers find it difficult to fully integrate into agile teams. This is partially due to:

  • Some tester mindsets that revolt against core agile concepts. The ingrained “waterfall” thought process often produces questions such as, “How can I test without fully developed and well-written requirements?” or “How can I collaborate with the developers about the tests I’m writing? They’ll know what I’m going to test, then will write the code so I don’t find bugs.”
  • Development teams that don’t include testers in the planning they perform for each iteration
  • Testers’ lack of technical capabilities, which either makes them uncomfortable, unwilling, or unable to work closely with more technical team members in development
  • A general lack of guidance on how testers should/can work within agile projects—although more information is available than in the past

Obviously we couldn’t offer solutions to everyone’s agile questions within the brief conversations, but we gave them as much insight as the time allowed and found the discussions enjoyable and informative, which leads to an additional thought. After the show ended we bumped into one of the attendees at the airport—a flight delay of 4 hours affords plenty of time for conversation—and talked to him about how long his organization had been using agile. Again, the answer was 18 months. This triggered a recollection of an article we’d encountered showing that project success rates rose from 2000 to 2006. Unfortunately, we were unable to locate the original article, but we’re confident it is related to the somewhat regular and often controversial CHAOS Report issued by The Standish Group. In the article, the author speculated that the tech bubble burst of 2001 caused a strategic shift by many organizations to move from big, hairy, long-term projects to smaller, more iterative and manageable projects due to a reduction in workforce and budget constraints. Since smaller projects tend to be more successful, the author believed this explained the improvement in project success rates.

 

Wrapping Up

 

Agile development techniques fit well within that paradigm shift and over the past nine years have had an opportunity to shift into the spotlight and gain acceptance by project management and executives alike. Is this recent surge of agile adoption focused IT shops the result of the last economic downturn or is agile moving up its “Slope of Enlightenment“? We’re not entirely sure, but are curious what you think. Please give us some feedback in the comments section to any or all of these questions.

  • Is your organization currently implementing agile or undergoing any agile adoption projects?
  • How long ago did you starting working in agile?
  • Why did your organization make the move to agile and what were the top two or three reasons?

We look forward to your answers and possibly resolving this grand mystery. And for those of you that visited our booth at the agile conference, thank you. If you weren’t the lucky attendee who won the iPad we provided in the SQE drawing, make sure you subscribe to the Zenergy blog for a chance to win an iPod touch.

(Contest Closed)

 

Up Next: