Smell #3: The Quality Assurance Wall
The QA Wall is essentially any structural practice that tries to maintain one or more levels of separation between Quality Assurance Engineers and Software Developers. It's based in Waterfall SDLC and is a strong odor for any Scrum team.
The wall can take many forms: a separate QA team, who plans its work in its own set of sprints away from the development teams; QA Engineers who are "embedded" within a development team, but have no input into the development process; the list of different forms can be quite extensive. Most of these practices cite a perceived need to keep some distance between Development and QA as an audit control.
The teams I'm observing currently have a different form of wall: QA maintains its own source control rail (there are no branches, so it's not a trunk) that developers merge their code into from the "Development trunk" as stories are completed. Testing cannot begin until code has been built from this QA rail and the final product delivery is made by QA from a build using the QA rail. There is no Continuous Integration environment in place. (CI is technically an eXtreme Programming practice, not Scrum, but it is a highly recommended practice.) Additionally, the QA teams' cubicles are all co-located -- adjacent to the developers, but not mixed in with them.
As you can probably imagine, keeping the QA rail and Development trunk in sync is paramount and involves a lot of extra, and I would argue unnecessary, labor.
What makes this a bad smell for Scrum is that the effort involved in keeping the QA rail updated generates and reinforces bad practices on the part of the Developers. They delay merging their changes because it is such a painful process. As a result, QA Engineers don't get their hands on most things until near the end of the sprint and any mistakes made in the merge process by the Developers create build headaches for the QA engineers who aren't build experts to start with.
This practice, combined with the lack of inter-mixing of workspaces and the issues resulting from Smell #2 all combine together to reinforce the "us vs. them" mentality. That mentality is causing bad blood between the two groups and has completely inhibited any environment of trust.
Contrast this with the Scrum teams I've run, which have had amazing levels of camaraderie, trust and quality software releases. On those teams, QA performed most of their testing from the Development staging servers, which were staged automatically by the Development build server from the Development source code trunk. Stories are tested often the same day they are checked into source control, or by the next morning at the latest. When possible, the QA staff were sitting mixed-in with the Developers, who were available to help the QA engineers with coding questions. (The majority of my QA engineers have been Computer Science graduates doing a mix of manual and automated testing.) When my QA staff has been remote, we've fostered an environment of "Instant message often, call on the phone more, email less" to keep people in constant contact. When a current story fails acceptance testing, it's turned around to the Developer immediately by talking to them over the low cubicle wall or by a quick phone call. My QA staff has as much input into the development process and tweaking of user stories as anyone else. Retrospectives, as a result, are honest, frank and based on the ability to trust the other members of the team. My QA people, who all report to me, actually like the Developers they work with. There is no "us vs. them".
In summary, a good Scrum team is able to perform QA reliably and faster when there are no walls in place. Faster QA means earlier detection of software faults, faster turnaround of defects and a higher-quality product.
Bottom line: Don't create the QA Wall!
No comments:
Post a Comment