As I have said, the driving force behind my creating the Three Pillars was organizational quality imbalance. As I observed what was happening at my client, I clearly recognized the imbalance. However, it was unclear to me how to create a model that would help them. I eventually came upon the following three critical areas, or ‘Pillars’, where I tried to categorize crucial tactics, strategies, and techniques that I have found helpful to agile teams as they create a broad and deep supportive structure for their product quality and testing activities. Here are the pillars at a high level:

PILLAR #1: Development and Test Automation:  This pillar is the technology side of quality and testing, and it is not simply focused on testing and testers. It includes tooling, execution of the automation test pyramid, continuous integration, XP technical practices, and support for ALM-distributed collaboration tools.

Often it is the place towards which organizations gravitate first – probably because of our generic affinity for tools solving all of our challenges. An important way to think about this pillar is that it is foundational, in that the other two pillars are built on top of the tooling. And organizations often underestimate the importance, initial cost, and ongoing costs of maintaining foundational agility in this pillar. Continuous investment is an ongoing challenge here.

Finally, this pillar is not centric to the testing function or group. While it includes testing, tooling, and automation, it inherently includes ALL tooling related to product development across the entire agile organization. It provides much of the ‘glue’ in cross-connecting tools and automation towards efficiency and quality.

PILLAR #2, Software Testing:  This pillar is focused on the profession of testing. On solid testing practices, not simply agile testing practices, but leveraging the teams’ past testing experience, skills, techniques, and tools. This is the place where agile teams move from a trivial view of agile software testing (which only looks at TDD, ATDD, and developer-based testing) towards a more holistic view of quality.

It is a pillar where the breadth and depth of functional and non-functional testing is embraced. Where exploratory testing is understood and practiced as a viable testing technique. It is where the breadth of non-functional testing is understood and applied to meet business and domain needs, including performance, load, security, and customer usability testing.

By definition, this is where testing strategy resides, where planning and governance sit, and where broad reporting is performed. I am NOT talking about traditional testing with all of its process focus and typical lack of value. But I AM talking about effective professional testing, broadly and deeply applied within agile contexts.

PILLAR #3, Cross-Functional Team Practices:  Finally, this pillar is focused on cross-team collaboration, team-based standards, quality attitudes, and, importantly, on building things properly. Consider this the soft-skills area of the three pillars, where we provide direction for how each team will operate – consider them the “rules of engagement”.

For example, this is the place where good old-fashioned reviews and inspections are valued. This would include pairing (across ALL team members), but also slightly more formal reviews of architecture, design, code, and test cases. It is a place where inspection is performed rigorously, as established in the teams’ Definition-of-Done. Where refactoring of the code base and keeping it “well kept” is also of primary importance.

Speaking of Definition-of-Done, this is the pillar where cross-team physical constraints, conventions, and agreements are established. But, more importantly than creating them, it is where the team makes commitments to consistency and actually “holding to” their agreements. Another important focus is on group integrity in conducting powerful retrospectives and fostering continuous improvement in the long term.

Foundational Practices

But beneath the Three Pillars are some foundational principles and practices that glue everything together. For example, taking a whole-team view of quality and testing, where it is not just the job of the “testers”, but of everyone on the team. I still find far too many agile teams that relegate the ownership of quality and testing only to testers. Continuously challenging this position and coaching the teams toward whole-team ownership is an ongoing focus.

Another foundational area is metrics. We all know that what you measure drives the behavior of the team. As we move towards agility, we need to begin measuring the entire team results rather than functional results, and even showing care when measuring the team, such as understanding that velocity is probably not the best metric to measure a healthy team.

One of the core components of the Three Pillars foundation is a thread that permeates through the pillars and the foundation. It embraces the core idea that each agile, self-directed team has a basic responsibility to build the right things (customer value) and to build them properly (design, construction integrity, and quality).

Figure 1 is an overview of the types of activity and focus within each pillar. This is a high-level view and there are important nuances that are missing – mostly due to a lack of space.

Figure 1. High-level View of the Three Pillars

Cross-cutting Strategy

Beyond the individual pillars, the value resides in cross-cutting concerns. I will go back to my original story to help make this point. My client was advanced in BDD practices, but struggling with user story writing, or even understanding “the point” of a user story.

The results would have been better if they had made the following cross-Pillar connections:

• In Pillar #1 – Behavior-Driven Development (BDD) and Acceptance Test-Driven Development (ATDD) are mostly technical practices. They focus on articulating user story acceptance testing in such a way as to make them automatable via a variety of open source tooling. Unfortunately they have an underlying assumption that you understand how to write a solid story.

• In Pillar #2 – One thing I did not mention in the story was that every team had a different view of what a story should look like and the ‘rules’ for writing effective stories. There were no norms, consistency rules, templates, or even solid examples. A focus on the software testing aspects of pillar two would have established these practices, which would have significantly helped their teams.

• In Pillar #3 – An important aspect of the user story that my client failed to realize was the “conversation part” of the story. If you reference the 3-Cs of effective story writing as a model, one of the Cs is having a conversation about or collaborating on the story. It is the most important ‘C’ if you ask me. It is where the “3 Amigos” of the story (the developer(s), the tester(s), and the product owner(s)) get together; leveraging the story to create conversations that surround the customer problem they are trying to solve.

Do you see the pattern in this case?

You cannot effectively manage to deliver on agile quality practices without cross-cutting the concerns and focus. In this case, effective use of user stories and standards, plus BDD and automation, plus the conversations needed to cross all three pillars. It requires a strategic balance in order to implement any one of the practices properly.

I hope this example illustrates the cross-cutting nature for effective use of the Three Pillars, and that you start doing that on your own as well.

Wrapping Up

This initial article is intended to introduce The Three Pillars of Agile Quality and Testing as a framework or model for solidifying your agile quality strategies and initiatives.

I hope it has increased your thinking around the importance of developing a balanced quality and testing strategy as part of your overall agile transformation. As I have observed and learned, it does not simply happen as a result of going agile, and most of the teams I encounter are largely out of balance in their adoption.

I hope you find the model useful and please send me feedback. If there is interest, I may explore more specific dynamics within each pillar in subsequent articles.

Stay agile my friends,

Bob.

As an aside, a colleague of mine and I have written a book on the Three Pillars model. It should be available on Amazon by the time you read this article. You can also get a free PDF of the book by . And in addition to the book, we’ve also developed a Three Pillars strategy assessment tool that should help you measure and plan your agile quality and testing strategies.