It is almost guaranteed that when I work with new organizations, one of the first questions that comes up is “How does the development organization work with the Q/A organization?” This question is a stinker. A seemingly simple question actually is pointing out much deeper organizational issues that go beyond testers to how we see all roles within an Agile environment.
That question usually indicates that most managers are trying to force-fit Agile methodologies into the old organizational structure. This is not just inefficient, it is detrimental. When thinking about moving to an Agile framework, an organization must consider what we are delivering and how. Practicing Agile means delivering small, vertical slices of the product every iteration. Vertical in this case means a slice that encompasses a feature from the customer-visible front-end to the back-end and everything in between.
The key mental sound bite here is that a slice isn’t done until the customer sings (with joy and praise, that is). To be done with a vertical slice, it needs to be developed, integrated and the whole product (up to that point) tested. To say a slice is done, means it is usable by the customer and is as close to shippable condition as possible. (I will have future posts on how to use this model with mixed software and hardware development).
The most efficient way to accomplish this is to reform a team from component-based teams into vertical teams. A vertical team is made up of all resources I need to finish that vertical slice. This may mean a GUI developer, the business logic fellow, the database expert, the network security professional, etc. – whoever is needed to complete the feature in its entirety. This also means that a Q/A professional is a part of the team, working hand-in-hand to create a high-quality increment. Developing even a small chunk and then ‘throwing’ it over to a separate Q/A group will not yield the efficiencies that well-practiced Agile teams boast about.
With that said, keep in mind that the Q/A professional’s role changes within the team. We don’t just want to put a tester with developers. We don’t want to create a situation where developers throw completed items over a mini-wall to have tested. Rather, the developers themselves will do as much of their own testing as possible. The goal is to create a team that has powerful skills to deliver the highest quality product. The Q/A professional will be responsible for ensuring all test cases for that iteration are defined, mentoring developers on building testing skills, including how to think about, write and execute test cases as well as helping the team automate as many test cases as possible. Just as they teach the team how to test, the team will teach the tester how to do simple coding for the sake of test automation.
Last but certainly not least, an essential part of the vertical team is the Customer – or at least the best representation of the customer that we have internally, usually a Product Owner. Unlike someone who furnished a book of requirements, expects delivery many months later and wants no communication in-between, a Product owner works with the team(s) on requirements, is essential in breaking them down vertically and works side-by-side with the team during the iteration planning and reviews. Product Owners may not necessarily be co-located but will answer any questions asked by the team in a matter of hours, not days or weeks.
To be truly agile, you need to plan, think, build on a feature-by-feature basis. To accomplish this most efficiently and effectively, the team needs to be vertical – have all the resources that are necessary to complete the features within the team. This includes, developers, Q/A personnel, Product Owners, documentation, etc. Pets, however, are optional.
