Making the Agile transition: What QA and test managers need to know

Moving from traditional software development to Agile is a major change. Amy Reichert provides the fundamentals to prepare teams for an Agile transition.

So, you’ve decided to go Agile – you’ve bought that it will improve your bottom line, make your testing faster and eliminate bottlenecks and missed deadlines while improving the actual quality of your software. The official announcement has been made, the documentation has been written and the training classes are completed. You’re Agile. Now what? Everything is official, it’s all in place. Is it really? Have your employees truly been...

allowed to plan and think through the change? If not, how successful is the Agile transition going to be? In this tip, QA and test managers learn more about how they can be change agents to help ensure a smooth transition to Agile for their test teams.

Major change doesn’t happen overnight

A change as significant as altering your development methodology cannot happen overnight. People have well-ingrained habits on how they work, how they create their work, and, specifically for our uses in this article, how they test. Testers are generally habitual creatures who have specific processes they follow, whether they have a physical checklist or a checklist that only exists in their heads. Making the Agile transition requires reviewing and possibly reworking all written processes as well as the ones they do by habit and routine. It’s a daunting task moving from a traditional Waterfall testing methodology to Agile. Software testing teams need time for planning, time for re-creation of task documentation and room for ongoing communication that includes question support with definitive answers and discussion of allowable alternatives.

“We all need to create new habits; otherwise, we won’t change,“says Geoff Quelch, software engineer & Scrum Master at McKesson Provider Technologies. “We need to know the compelling reason why we’re changing habits. You’re taking previously independent roles and altering them from a rarely communicates pattern, as an example, to a method where we’re all communicating all the time.”

The importance of planning

Planning is inherently necessary. Without planning, the change you make will have open gaps where old habits can flourish and find a new home -- like weeds in concrete. After your management team has defined your Agile strategy including the tools you’ll use, if any, and roles for each group, noting that these roles will change and cross borders over time – development, test and requirements. Eventually, the team will be cross-functional, with each member performing multiple or simultaneous roles. As change agents you’ll need a plan for each role that includes specific details to get the team started. 

The figure below outlines a basic example:

Requirements (Analysts)

Development

Test

Create requirements document

Assign resources to iteration changes

Plan regression execution for iteration

Create user stories including acceptance criteria

Scrum Master role

Assign resources to iteration changes

Manage backlog grooming review meetings

Code and code review

Test creation

Product wwner – Final pass for acceptance of change

Unit test

Test execution

Figure 1

Well-defined roles are essential during the beginning, especially when going to Agile creates changes in your workflow. As the team changes and matures into the Agile processes, the role differences disappear and the team members cross roles to serve as needed.  

For testers, you want to give them specific tasks so they can plan their time and know what to expect. In a traditional methodology system, once the requirements are created and reviewed, neither the tester nor the developer generally hears from the analyst group. However, in Agile, these groups stay in constant contact, as development needs to make changes to the design or product owners change their mind based on testing results or input from customer focus groups. The process may also change the skill set slightly that you need in your testers. According to Becky Karch, Director QC/QA – McKesson Provider Technologies, “Instead of just technical skills, you need testers with advanced personal and communication skills. Testers need to be capable of stirring the soup, so to speak, as they work within their Scrum teams.”                

Testers thrive on routine, which overall is a good thing. However, if you have a large group of experienced testers, it will be difficult for them to make the Agile transition without time to plan. Planning is not the announcement meeting -- it’s planning specifically for the test group. Testers adapt more readily to the Agile process if they have time to plan and assimilate the changes into new processes and procedures. 

As a manager or change agent in this scenario, you need to meet with your test group and plan out what specifically the change means to them. Testers are creative, so if you leave it up to them to adapt without any coaching or planning, you’ll end up with confusion, followed by creativity and some sort of hybrid process between Waterfall and Agile. The obvious Agile changes will occur, like the stand-up meetings and use of the tool you’ve chosen, but the full core change will not occur as each group slips back into the habits of your previous methodology. 

QA process documentation review and re-work

As a manager and change agent, be aware that most testing teams have process documentation. It serves to provide training materials for new employees and document processes that testers must follow to fulfill regulatory or organizational requirements. Time needs to be allocated to update these documents and re-train the team on the changes. Resist the temptation to speed the process along by simply designating a manager to rewrite it.   

To socialize the changes, create a small team with representatives from each testing group, at least one test manager representative and one or more Scrum masters. Spend the time up front to get the new testing process documentation ready. Make sure it’s specific and includes contact information for questions. Also, plan on keeping it updated at least once per quarter. Strive to make your processes specific, clear and concise. 

Agile adoption: Has the change really occurred?

How do you measure your Agile transition? How can you tell if the fundamental thought patterns and working process are changing? 

You can create surveys and gather data or meet with individual Scrum teams, as two examples. Surveys can be ignored or vaguely answered. On the other hand, observing the testing team changes by observing team members’ working process is more personal and more involved. Subjective, yes; time consuming, definitely. However, it better serves the close communication associated with Agile, and gives you better insight to possible issues with process adoption.  

Granted most people “behave better” when being observed, but over time you should notice any gaps in understanding, where there is confusion or misunderstanding, where coaching opportunities exist or additional training is needed. Bottom line is, as change agents you need to be in tune and measure and observe if the new methodology is being understood and used.

Another effective way to measure your adoption is to have tune-up training for Agile. Bring in a facilitator, or facilitate it yourself. Either way, review the core Agile principles and generate feedback from the teams on how they’re fulfilling each one. Find out where they are struggling or where team members are slipping back into old habits. If need be, arrange for a formal class to assist the team in the change process.

As successful change agents, managers need to establish a working relationship with their testers in order to ensure the change occurs and to measure its effectiveness. Change is difficult and involves significant time to plan for the change, re-create process and procedure documentation, as well as ongoing training and support. Proper preparation is essential to your testing team’s successful adoption of Agile. Measurement is somewhat subjective, but worth the time to ensure the change is being adopted and worked on. Granted, it won’t happen overnight, but it will happen if the time to properly plan for the change is provided. Testers will adapt more easily when their new processes are in place, and they have your backing for both training and ongoing support. 

Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.

This was first published in June 2012

Dig deeper on Agile Software Development (Agile, Scrum, Extreme)

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close