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.
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!
Lacking Balance
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. 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. Afterward, 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.”
Three Pillars of Focus
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 & Testing, and I began to coach a much more nuanced, broad, and deep approach for their teams.
Here’s the high-level view of the Three Pillars approach:
When you’re evaluating your agile quality and testing practices, I want you to think of balance across the pillars. For a free PDF copy of the Three Pillars of Agile Quality & Testing, please join my mailing list here. You’ll then gain access to my website downloads area.
Bob Galen will be leading tutorials based on his Three Pillars framework at STAREAST 2015.
