“Whole Team” Ownership
By Tom Churchwell
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.