Scrum-team

Corporate agile

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.

Agile Ecosystems

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.
Kanban & QA in Greenhopper

By using tools such as Kanban boards and CFD the team must reflect on the optimum number of resources to reduce WIP

CFD in Greenhopper
  • 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!

Author: Eduardo Mayor

Eduardo Mayor is a software engineer with 20+ years of experience. He is also the founder of Novagenia Information Technologies, a company focused on introducing agile methods and tools to companies worldwide.

Visit us in: http://www.novagenia.com
Share this...

One thought on “Corporate agile

  1. Un post muy interesante, aunque no estoy de acuerdo con algunas cosas.

    “los procesos ágiles que han surgido en la última década parecen haber reservado un papel residual a los ingenieros de calidad”

    Para nada! quizá en los inicios, pero a día de hoy por ejemplo, en Bridging the communication Gap, explican como el rol del equipo de calidad no solo se mantiene sino que se amplia para hacer que participe más en el proyecto.

    “Dejando a un lado las estimaciones del valor de negocio (responsabilidad exclusiva del cliente) y de coste (responsabilidad exclusiva del equipo de desarrollo), el resto de los datos incluidos en cada historia de usuario forman parte del ámbito de responsabilidad habitual del equipo de Calidad funcional de producto!”

    Que va! La elaboración de los criterios de aceptación de ser responsabilidad conjunta de cliente, equipo de desarrollo y equipo de calidad! Siendo el papel del equipo de calidad muy importante por su habilidad para buscar corner cases y ver rapidamente donde puede “romper” el sistema.

    De nuevo, te recomiendo Bridging the communication Gap que explica mucho mejor de lo que yo podría las responsabilidades de managers/developers/testers en la metodología agile acceptance testing (AKA ATDD)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>