I was employed a few years ago at a wonderful company. I first joined them as an agile coach and Scrum Master. I had been spending an inordinate amount of time on the road teaching, so this local opportunity to coach a set of agile teams was timely and incredibly welcome by my family and I.
After joining, I was soon promoted to a Director of Software Development role and became a member of the senior leadership team. That was my title and my primary role, but I continued to coach and champion agility across the organization.
I used to joke about arguing with myself because I had two halves. I had the dark-side responsibility of “management” (Darth Vader) and the light-side responsibility of coaching our self-directed agile teams (Luke Skywalker). Although I felt I achieved a reasonably good balance, it certainly was challenging at times to keep my heavy breathing to a minimum.
The Triad?
I was lucky in my role that I discovered two colleagues who became my partners in our agile journey. Not only were their roles central to the partnership, but we were all reasonably like-minded in our commitment to agile methods and to creating a great team environment.
One was the Director of Quality Assurance & Testing and the other, the Director of Product Management. Including my role, this meant that we had coverage across major functions within our technology organization, including—
- Software Development & Project Management
- Quality & Product Testing
- Product Management & Marketing
A “Triad” if you will.
We established a group or committee amongst ourselves where we focused on providing consistent leadership & guidance for our enterprise-level agile adoption. Our triad provided consistent vision, mission, and goal setting for our agile direction. To our credit, we realized early on that agile adoption wasn’t only a play at the technical team level. While that level was certainly important, it also needed senior leadership understanding and support for effective steering.
Linking from the notion of Scrum of Scrums, we likened ourselves to being a Scrum of Scrums of Scrums or providing an S3 and S4 level committee. We wanted to focus on guiding our evolution from a structural and guideline perspective, but also providing the visionary and supportive leadership that is so important to a successful agile adoption.
We discovered over time that this model worked incredibly well because most of our initiatives could never have been driven by any individual function. I’ll explain more of that later by way of an example, but suffice it to say that our synergy truly mattered.
Implications to Agile Project Management
I think the first lesson from this is that an individual function or group cannot solely drive agile adoption alone. That agility isn’t simply a “collaborative game” from a team perspective. But it’s also requires collaboration across various levels within your organization.
Organizations need to be aligned and integrated across:
- The team level themselves
- Across middle management tier
- Across the senior leadership tier
In my example, we were operating at the senior leadership tier. We were coaching and supporting our teams. But importantly, we were spending a great deal of time coaching our middle management tier in their adjustments towards leading agile teams.
From an agile project management perspective, I’m implying that your reporting / transparency, agile methods guidance, and execution leadership needs to be applied simultaneously across all three structural tiers. Perhaps not at an equal pace or velocity, but each needs to be moving forward in order for true progress to be made.
Embracing ATDD or BDD as an example
In order to illustrate the power of the triad in focusing on the right things, I’ll use a real example.
An organizational adopting agile was supporting a Software-as-a-Service (SaaS) product suite of e-commerce applications. At one point, it was determined that the application had some significant bugs that were causing charge-backs to the company—costing them “real” money.
One of the team members, a senior software developer, had the idea of leveraging Cucumber and acceptance test driven development (ATDD) or behavior driven development (BDD) techniques as an approach to ‘debug’ the business logic in a specific set of transaction components.
Supporting the initiative
The triad came into play in the following ways as we used these testing tools and techniques first to isolate and then to repair this set of really challenging bugs—
From the Development-side:
- First of all, there was the initiative shown by the individual engineer in suggesting a ‘novel’ and potentially risky approach to sorting out through some hairy legacy code and trying to solve the bugs.
- This was essentially a “refactoring play”—so more courage to champion a method
- Learning new approaches and techniques can be risky and time consuming. These bugs & issues had tremendous visibility and were costing the firm ‘real’ revenue. So there was outstanding visibility and pressure towards fixing them ASAP. Kudos to the team for maintaining their balance in taking the right approach.
- Finally, the development teams in this context took a whole-team view towards quality. It was everyone’s job and they took that approach to initiating and delivering this repair.
From the Quality-side:
- The quality or testing team members brought some familiarity with Cucumber to the table. They would also need to support any test automation that was created as part of this effort.
- They had to be open-minded to an automation centric idea that was largely coming from outside the testing team.
- The testers demonstrated the solution in the Sprint Review. They ran the tests and needed to assure that the tests were well constructed and the test designs sound.
- They also took the ball after the demo and ‘wired’ these new tests into our ATDD-based regression suites so that we would catch future business logic bugs before release.
From the Product-side:
- The first leap of faith here was allowing the teams to pursue “testing infrastructure” over delivering features. We needed the Product Owner to ‘trust’ their teams’ recommendation into how to attack this problem. Given the nature of the Triad, we got that.
- We also needed the product organization to run interference or cover for the team while they investigated this approach. While they might not understand what we were trying, they needed to support the approach externally. And they did.
- We also needed the Product Owner to establish the correct business logic that was required. This was crucial in the testing design phase. Keep in mind that in ATDD, we developed the tests first to mimic the exact business logic that was intended. Then ran the code through the tests. Starting with a crisp definition of the logic helped us isolate the exceptions that were covered incorrectly.
The Delivery
With our triad-based cross team support, the team delivered a repaired solution in a single sprint. At the review, they identified three critical bugs that were repaired as a result of the effort. But beyond that, they identified three more unseen logic bugs that they repaired as part of this overall effort. So the business logic was thoroughly repaired and now had a set of repeatable automated Cucumber tests that could be run against it.
We had a tough not easily impressed CEO at this company. But I think, just think, I may have seen a tear come to his eye during the demonstration.
Wrapping Up
I hope my example illustrated to you the necessity for and power of the Triad in agile teams. It’s much harder (or even impossible) for an individual function to initiate continuous improvement change by themselves.
Instead you need the power of collaboration via the triad model of (Development + Quality + Product) to share perspectives and fully deliver on the promises of agility. And this isn’t only at a team level, but is important at all levels within your organization.
As an Agile Project Manager, you’ll want to focus on triad-based interactions at all levels within your team and organization. Always reinforce whole-team solutions and collaboration. And discourage silo-based thinking as much as possible. Remember, agile adoption is not “a technology only based methodology” play, but instead is an “organization-wide transformation” play.
By taking this broader view, you’ll deliver better solutions with your teams.
Go Triad!
Thanks for listening,
Bob.
Post-script
I’ve leveraged the idea of the Triad as an organizational collaboration model. However, it’s often used to illustrate the agile team collaboration model that helps define, refine and deliver on customer requirements.
Ken Pugh has written a wonderful book that speaks directly to this ‘Triad’ of Developer + Tester + Product Owner.
George Dinwiddie has written about it with a slightly different label. He speaks about the 3 Amigos, but it’s essentially the same topic and point.
In both of these cases the triad is driving collaboration towards building what the client truly needs that solves their real challenges and problems. Both are highly recommended. Like I said earlier…Go Triad!