Agile Quality
“Whole Team” Ownership
By
Tom Churchwell
Overview
Many times, QA is an event that occurs after development is done;
like a chef tasting cookies after they are baked. The common problem with that is finding out
we missed a key ingredient after all the mixing and baking and frosting is
finished; the worst time to detect a flaw. Good bakers test along the way and
maybe even call a spouse in from the living room to taste the cookie dough
too! Getting direct customer feedback
during development helps ensure quality throughout the process. Finding flaws early provides an ability to
adjust, adapt or start over with time to recover. Metaphorically, quality cannot be “tested in”; rather it must be “baked in”.
If your teams are doing a lot of manual testing, or if you have a
“QA Testing/Tested” phase after development, then your teams are likely attempting
to test rather than bake quality in. It is a common practice and, for most
teams and organizations, it is intuitively the way development has always been
done. Most traditional IT projects stink; based on Forrester research, more
than 60% are unsatisfactory. The QA after development tradition stinks. It is a
tradition that produces untold and commonly accepted suffering by the teams
delivering solutions and the customers who want to use them.
Breaking this tradition can require some changes to both thinking
and practices. Hiring non-traditional and
highly collaborative thinkers, blending and overlapping roles, including the
customer when things are still in flux and building for the capacity to adapt
rather than “nail things down” are just a few of the changes teams need to work
toward.
Tradition dictates that roles should be clearly articulated and
separated. Things should be done in a particular order with specialists doing
their particular part in a particular way and at a particular time. Plans and
processes should be clear and followed.
Requirements should be captured up front and fastidiously tracked. Being
able to predict exactly what will get delivered, by when and how much it will cost
is of paramount importance. Changes
should go through a formal change request process. And everything should be
captured in writing. Everything should be well thought out, maybe even well
documented ahead of time and if anything changes, the implication is that it
was likely a failure in planning or execution and someone must have done
something wrong.
As good corporate citizens, teams try to work with these background
assumptions, knowing all the time that things will change and the team will
have to adjust. The teams delude themselves by thinking that with the right
people, and just the right amount of heroics, the team will power through the
challenges and make the fixed deadlines. In reality however, superior quality
falls through the cracks and chasms of miscommunication that exist between even
the most well specified roles. Two
people may own their roles and execute in them to a “T” and still miss
something major. Examples abound where
the customer says “That’s not what I wanted” and the developer retorts “That's exactly what you asked for in the requirements”. Deadlines loom and hard choices are forced on
the team and in many cases, after a painful deadline death-march, the project
goes to production with significant flaws. For teams steeped in traditional
software development practices, their suffering is perceived as a “normal” part
of doing business.
Changing
the way we own quality
The whole team concept is founded in part on the emphasis on
individuals and interactions over process and tools. In it is the premise that all aspects of quality
can be held by the whole team. Teams vary, and the degree to which they are
ready to take whole team ownership varies as well. With an effective and experienced QA Guide, over
time, the knowledge, expertise, and capacity to “bake quality in”, can and
should be held by the whole team.
Test Driven practices have been gaining momentum and with them,
changing the way quality is owned by a team. The “Definition of Done” for Value
Stories and User Stories changes significantly.
Meeting quality standards becomes a part of the “Definition of Done” for
development teams and like our baker testing for quality all along the way, testing
every aspect of a story is now accomplished throughout development.
Definition
of Done
Starting with a big picture view of what is ultimately needed for
the project to be successful, teams can move quickly to planning the most
effective and expedient way to produce it.
Team members can then collaborate to specify what success looks like at
the functional level (“Definition of Done”) and how the team might go about
producing it for every story from inception all the way through to production.
Specifying a shared definition of done is something the team
does collaboratively at the beginning of the project. It establishes and reinforces beliefs, norms
and practices for the whole team throughout development. It is a reflection of the collective values
of the members and the standards to which the team aspires. Some of the standards may be dictated to the
team, like the level of required automated regression test code coverage or
some other metrics, but most of the standards should be specific to that team
or that particular project.
Many of the fundamental concerns will be the same from
project to project, but the nuance of each project requires that the team come
together to ratify a definition of done that the whole team can live with and
can agree to hold each other accountable for.
Quality standards should be included as part of that definition of
done. Once specified, a QA lead or any designated
team member can track, manage and report quality metrics both to the team and
to management. As much as possible, Big
Visible Charts should be used to keep quality metrics a highly publicized part
of the ultimate solution. Big Visible
Charts are a straightforward way to help everyone quickly know where the
project stands and to foster the culture of quality with the team.
Inevitably...It comes down to team
Agile solution delivery is a team sport and QA is a
contributing member from the start. As
with a traditional project, some events occur in sequence, but with agile, many
once segregated responsibilities are now owned by the team and executed as a
team. The agile approach is evolving and
so too, is how QA participates on an agile team. Many QA concerns and tasks are still the sole
responsibility of QA, however, depending on a teams “Definition of Done”, many
concerns and tasks may be absorbed and owned by the whole team. In order to become a contributing member of
an agile team, QA skills may need to be expanded. Deep technical and development skills make QA
a more powerful team contributor and helps to socialize the role of QA into the
team as a whole. This socialization of
QA relieves some bottlenecks that have existed on traditional teams and opens
up the possibility for increased velocity for the team as a whole. The role continues to evolve, and with it,
the possibilities for how solutions will be delivered in the future.
No comments:
Post a Comment