Teams & Processes: Orchestrating Quality in a BDD Framework

‘If you want to change the world, start off by making your bed.’

I’ll come back to the genius behind this quote, but this fits accurately for organizations planning to overhaul everything they’ve been doing in a bid to take on digital. There are transformation agendas and restructured ‘lean and mean’ teams. But then, do I see the world changing any time soon?

To be more specific, I’ll take Behavior-Driven Development or BDD as the point of reference. With its customer-centric approach, BDD allows organizations to excel in digital, where :: end-user experience is brand equity. I’ve talked about this at length here. I’ve also delved into deploying automation for faster returns. But to get all of this off the ground, you need people – the teams that come together to potentially change the world. (Ah, well, humor me here!)

Which brings me to this blog – the third in a series of how organizations can successfully transition to a BDD model, and excel at it too. Here, I take a step back and ask you to look at your team players – the business analyst, the developer and the tester – and see if you know them, or if they know each other? Are they talking in a language they all understand? Are they on the same page? Do they know exactly and in clear terms what the product being developed is meant to do? Do they know the target audience, or do they realize how important a role they all play in making this product a success?

If this requires some soul searching, know your BDD implementation is not on a solid footing.

Why Collaborate & Orchestrate

BDD incrementally builds communication. It defines requirements based on end-user behavior, focusing on features with a direct bearing on business outcomes. Here the user stories are specified by a business analyst, designed by a developer and validated by a tester – all based on expected customer behavior with declarative grammar, concrete examples and solid feedback loops.

The reason why BDD fails to deliver expected results for several organizations is because their implementation is facile. For instance, they take Gherkin to be a language that lets them automate faster, whereas it has so much more to offer. We need to understand that BDD is a culture change, where you don’t just get a new tool to automate, it is a whole different ball game – that cuts across the barriers we have created between teams.

Here’s what you could do to align your teams to a BDD work culture:

•        Training: Ensure all teams involved in implementing BDD are trained in the requisite concepts before kicking-off the actual implementation. This would act as an ice-breaking session, helping them understand the need for the change and appreciate their roles in this transformation.
•         Commitment: Once your internal stakeholders are on the same page, ensure they remain committed to carrying out the agenda. This would require frequent brain-jam sessions, establishing end-to-end visibility of expected goals and the role that each stakeholder plays in taking the exercise to its logical conclusion.
•         Start Small to Make it Big: Begin with shorter iterations or flow-based work, slowing the teams to develop a protocol to specify, implement and deliver relatively small chunks of functionality. Once successful, scale the model to bigger projects.
•         Identify Toolset: Identify and enable your team to do more with a proper toolset across the lifecycle.

When all the players act to collaborate and corroborate, they are in a better position to deliver the right quality – with orchestration of their expertise, tools, processes across the lifecycle.

All In: How QE Architects Help in Orchestrating Quality

To pull the right strings, a seasoned BDD architect can come handy in identifying hotspots, sharing best practices from prior implementations, hand-holding the teams through the journey, evaluating potential dip in velocity during initial sprints and tying outcomes to quantifiable business value through relevant metrics.

Introducing Quality Engineering Architect – your go-to person for orchestrating quality across teams and processes for a successful BDD implementation. A few checkpoints a QE Architect may follow to build consensus are:

•         Conduct working sessions where each team contributes in writing user stories and acceptance criteria.
•         Establishing a robust feedback loop for acceptance criteria from user-side teams such as Ops and UAT.
•         Reviewing acceptance criteria and securing a sign-off from PO.
•         Delineating step definitions and developing validation script with identified tools.
•         Ensuring in-line automation for all in-scope functionalities.
•         Demonstrating each sprint to review test results with all stake holders.
•         Documenting learning after each Sprint

With incremental automation, common understanding and collaboration, organizations can achieve expected outcomes in terms of robust quality in-line with customer perspective. The central tenet is taking ownership of your teams, making it easier for them to collaborate and take initiatives. After all, it all starts with making your own bed!

And now, getting back to the genius behind the starting quote, well… why not take initiative here, Google his name and write it down as a comment? :-)