Introducing QA to Agile team
Introducing QA consultants into a software development lifecycle (SDLC) usually starts with an initial knowledge transfer phase that may take from a week up to a couple of months. By default, knowledge transfer phase duration depends on two significant factors:
- Development phase. QA team that starts working simultaneously with the development team requires less effort to get on board in comparison with the latest project phases when the requirements are partly outdated due to changes in technical decisions or business priorities.
- Project and domain/area complexity. Providing QA for typical end-users’ products (e.g., social networks or shop sites) doesn’t require a long period of team adaptation in comparison with complex business solutions.
However, there is another factor to consider – process adaptation. I’d like to cover this aspect based on the Agile environment (Scrum in particular). According to a1qa experience with more than 100 projects completed using Scrum, there are three significant issues each team faces:
1. Development team has never worked with QA professionals before
Scrum suggests that Agile teams should be cross-functional. And most of the development teams try to follow this rule when establishing Agile techniques.
After a while they encounter two major problems:
- Developers are not good enough in software testing and miss obvious defects or spend too much time on the task
- Developers are demotivated by doing the job they are not interested in.
Having a cross-functional team has its own benefits, and the most considerable is a feeling of responsibility.
However, imagine that you need cardio surgery. At a hospital, they say it will be performed by a dentist explaining that their team is 100% cross-functional. Would you take this risk?
For most companies, the only solution is to introduce a professional QA team. In most cases, it will affect the established process familiar to everyone, e.g., defect management should be introduced together with other QA activities that are often neglected in cross-functional teams.
To avoid misunderstandings and conflicts, a QA team should be eager to introduce changes and reason them.
a1qa also advises to set up training sessions for development and management to give an understanding when, why, and for sure, how QA works. Regular (informal) Q&A by quality assurance sessions are a very popular way to get a development team involved in what QA engineers are doing.
And of course, a QA team should become a part of a project team doing Sprint plannings, Scrum meetings, and retrospectives accepting responsibility for team success or failure.
2. Development or QA team has no experience working Agile
Agile is called so for its flexibility in rules and regulations. Scrum is usually considered to be easy to adopt and follow, especially considering other methodologies like RUP.
At the same time, to be effective in Agile, the team should spend at least 2-3 full Sprints to get accustomed to the speed and process, understand the best practices, feel the team responsibility, and get used to each other.
The most effective Agile teams are those that have been working with no staff changes for 3+ months. During this timeframe, a team will go through some successful and unacceptable Sprints, define their own velocity, get more familiar with estimates and risks based on their team experience.
A good practice is to have at least 50% of the team members who have been working in Agile before. They may give a hand to newcomers, share knowledge and expertise.
a1qa tries to balance Agile teams starting with at least 75% of Scrum gurus and keeping teams unchanged for 6 months and more. We also do an introductory training in Scrum for all crew members who are joining a1qa team as well as for development teams.
3. Communication aspect. Another default rule in Scrum is team co-location
The world is changing introducing globalization into everything (and cloud computing is a good sample for IT). Communication is still a very important part of the Scrum team. Normally, Scrum meetings should be held in one room, where everyone should stand up and provide their update to the crew.
For distributed teams, we use the same approach but different tools – the team has daily Scrum meetings using Skype, GoToMeeting, or Polycom. Therefore, while the tools change, the process itself stays the same.
To cut a long story short, involving the QA team in an Agile process is challenging. Nevertheless, consider the benefits you get: high-quality products, happy customers, time to market reduction, costs optimization, and effective developers.
