I have found that one of the main obstacles in the adoption of agile methods by conventional organizations has to do with the impact of a non-conventional layout (like that of Scrum) on a corportation’s organizational chart. In this entry about corporate agilism we deal with the role of Quality Assurance engineers from different perspectives.
During the last decade, methodologists and software engineers have been pushing for a paradigm shift in IT focusing on new roles and creative intereaction among them. The background of those driving the change has conditioned the roles and responsabilities in development teams, forgetting about some of the key actors in more traditional processes:
- QA: Quality Assurance Engineers, mainly functional testers
- Project Manager.
- Project Office.
The challenge in introducing an agile culture in traditional corporations (or just change-resistant ones) requires a review of the role of these and some other actors in software development teams. In this first article on corporate agilism we will provide our vision on the new areas of responsibility for quality assurance engineers.
QA in agile teams
As opposed to heavyweight methods from the 80’s, agile frameworks seem to have reserved a marginal role to QA guys. Formal documentation on functional testing for agile teams is hard to find and the introduction of techniques such as TDD or Continuous Integration may be confused with functional validation.
We firmly believe all agile teams should have specific roles in charge of functional testing and quality assurance.
QA as Product Owner
Product Backlog in Scrum is the ordered list of functional requirements sorted by business value (or ROI). Each item in the list (Product Backlog Item) must contain at least the following data:
- Feature: A functional description (user story).
- Business Value: Relative estimate of value for the client/user.
- Cost: Relative estimate of effort for the team.
- Acceptance Criteria: Definition of Done, Validation and/or regression tests.
Leaving aside estimates for business value (it’s sole responsibility lies on the user) and cost (it’s sole responsibility lies on the development team), data related to a PBI belongs to the area of responsibility of Functional QA testing!
Consider appointing a Funtional tester as Product Owner in order to enhance communication of user stories and maximize quality in every Sprint.
This approach has also, some added benefits:
- User Stories expressed in a more developer-friendly language
- Definition of Done for every user story
- Product Quality in every release, which provides greater reliability on the team and project advance.
Those companies where product quality is critical or software development driven teams are ideal candidates for this layout.
QA as part of the development team
Frequently, rigid organizations do not allow the flexibility and selft-organization required by agiles teams (see Agile Ecosystems). In some cases, responsibility for functional requirements lies in departments outside development or technology.
When it is not possible to have a Quality tester act as Product owner, the team should enfoce product quality in the following practices:
- Planning session. Quality should contribute to the understanding of user stories and Definition of done as these information may have an impact in the cost/effort estimate.
- Tracking. Continuous Integration (on different environments) must be a valuable tool for functional validation.
- Sprint Review. Review sessions should focus on validating that committed features have been delivered completely, satisfying the acceptance criteria (for more info see Sashimi).
Trust in the team (and therefore, in the new paradigm) rely heavily on the quality of every bit of functionality released in a sustained rithm. Thus, product quality must be top priotity for the team.
As we have mentioned, Technology departments on many traditional corporations are not ready for a collaborative environment. To make thing worst, frequently responsiblity for product development is highly distributed: Requirements Manager, Architecture Manager, Sfotware Development Manager, Quality Manager, Project Office…
Sometime the only way to introduce agile in these environments is to create an agile ecosystem.
An agile ecosystem is a protected environment for developers and QA in which conditions for self-organization are set to allow organic growth processes.
A word of warning! An agile ecosystem’s goal is to implement itereative and incremental proceses in organizations that do not allow such models explicitly (as they operate in a closed scope or closed budget approach). This modus operandi may be the only one feasible at a given time but best results can only be obtained when the new paradigm is ambraced by the whole corporation.
QA in Agile Ecosystems
The concept of Agile ecosisystems is not part of any de facto standard or body of knowledge accepted by the community. The following suggestions are just our particular outlook on this subject as a result of several years helping companies embrace the agile paradigm:
- Planning. QA must contribute to cost/effort estimates providing feedback on Acceptance criteria for every user story. Besides, an explicit Definition of Done will be provided by QA for every user story planned for the next sprint.
- Continuous Integration. Sustained product integration along the sprint must be used for automation of funtional tests (whenever possible). QA will have access to testing environments and automation tools to ease continuous delivery on them.
- Tracking tools. Tracking toos and charts (burndown chart, kanban, etc.) will take into account validation as a new stage to evaluate progress. A user story will only be finished once it has made it from the validation stage to the closed status.
By using tools such as Kanban boards and CFD the team must reflect on the optimum number of resources to reduce WIP
- Sprint Review. Sprint review sessions must be aimed to analyzing the fulfillment of commitments. We can’t stress this enough; one of the main goals of an iterative and incremental process in to strengthen the reliability on the team (as well as its self-esteem) which means that any deviation from commitment must be dealt with in the retrospective session.
- Sprint retrospective. In the first sprints development and QA will hold retrospective sessions to analyze in a collaborative fashion the impediments that are stopping the team from increasing velocity as well as structre and process changes that may improve productivity and overall quality.
- Scrum Master. Agile ecosystems introduction must be driven by a great deal of common sense and, above all, by an expert facilitator that can pull the best results in a constrained environment. Degree of success (and time required to achieve it) depend heavily on the experience of this role.
In next entries we will deal with some other factors affecting the introduction of agile in conventional organizations. Keep tuned!