Introduction

A few years ago, I entered an organization to do some agile-focused coaching and training. From the outside looking in, it was a fairly mature agile organization. They had internal coaches in place, had implemented Scrum while also leveraging Extreme Programming technical practices for a couple of years, and seemed to be fairly committed and rigorous in their application of the methods.

It was a global financial firm that delivered their IT projects via highly distributed teams. There were a wide variety of tools in place for application lifecycle management (ALM), software development, and software testing support. In my first few days, everything I encountered, while albeit in superficial detail, just felt like a mature agile organization and I was pleasantly surprised. Heck, I was impressed!

For the purposes of this article, my observations will shift to being quality, testing, and tester centric.

Too Narrow a Focus

One of the things I noticed is that the firm had gone “all in” on Behavior-Driven Development (BDD) leveraging Cucumber. They had invited in several consultants to teach courses to many of their Scrum teams and, as a result, everyone was excited and “test infected”.  Teams were literally creating thousands of BDD-level automated tests in conjunction with delivery of their software. From their teams’ perspective, there was incredible energy and enthusiasm. Literally everyone contributed tests and they measured the number of increasing tests daily.

These tests were executed as part of their continuous integration environment, so there were visible indicators of coverage and counts. It was truly visual and very inspirational. And I could tell that everyone was focused on increasing the number of automated tests – so there was a unity in goals and in each team’s focus.

However, a few days into my coaching, I was invited to a product backlog refinement session where a team was writing and developing their user stories. What I expected was to simply be an observer. What actually happened is that I soon realized that the team did not know how to write a solid user story. They could barely write one at all, which shocked me. After this gap became clear, they asked me to deliver an ad-hoc user story writing class for them. Afterwards, the team was incredibly appreciative and everyone seemed to ‘get’ the place that stories held in developing their BDD-based acceptance tests.

Over the next several days, I started to realize something very important. The organization was at two levels when it came to its agile quality and testing practices. People were either “all in” or they were “unaware or under-practicing” specific techniques. For example, they were “all in” on BDD and writing automated BDD (Cucumber) tests and on continuous integration. However, they struggled mightily with writing basic user stories and literally had no clear or consistent Definition-of-Done.

I also realized that this “seesaw effect” of focusing on a handful of the more technical practices was doing them a disservice. Why? Because it is actually the interplay across practices that influences the effectiveness of your agile testing and the product impact of your quality practices. I prepared a model for them to illustrate the balance that I think is critical in agile quality practices.

I called it The Three Pillars of Agile Quality and Testing, and I began to coach a much more nuanced, broad, and deep approach for their teams.

While this is more of a strategic play and a longer-term focus, the discussions and the changes they drove had an immediate impact on the organization. People started to connect the dots between the technical and softer skill practices. They became much more aware of the interplay across practices and how this drove an improvement in quality results.

I want to share the “Pillars” in this article in the hope that it will help your agile quality strategy development as well.

A Bit More on Strategy

A really important sub-text to the development of the Three Pillars is my ongoing observation that agile organizations at best might have a strategy for their overall transformation. But rarely do they develop or are able to articulate their overall strategy for agile quality and testing.

I guess the assumption is that these aspects are “along for the ride” as part of the development-driven strategies in their agile adoption. But I could not disagree more with that point of view.  I believe that calling out, making transparent, and focusing on your quality and testing agile strategies strongly aligns with the Agile Manifesto and makes for a much more rigorous and successful agile transition.

The ultimate value of the Three Pillars is to help organizations think about, articulate, and realize their agile strategies in these areas and, most importantly, to hopefully achieve evolutionary balance.

Wrapping Up

In the concluding episode of this post, we’ll explore the Three Pillars in more detail. We’ll also explore the foundation of the model and how the pillars are intended to drive a more cross-cutting view in your agile testing and quality strategies. Please check out part-2 here

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.

Stay agile my friends,

Bob.

 

Learn more about Velocity Partners offshore software development company