Test-first approach:
Test Driven Development (TDD) has been around for a long time now, I started to use it back in 1999 while working for a major NYC Bank and when our team lead suddenly got inspired after a chance meeting with Kent Beck (leaving this story for another blog). TDD and refactoring have been the major tenets of Extreme Programming (XP). By definition, Test Driven Development (TDD) (Beck 2003), is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.
Image: http://www.extremeprogramming.org/
Both TDD and BDD (for that matter ATDD or any xDD) are test-first development approaches because you have to specify the behaviour before you do the implementation. In both you (have to) write the tests first and that’s how it also becomes a design process. The difference lies in the level at which these tests get abstracted, in other words BDD differs by testing the actual behavior of the system from the end users’ perspective as opposed to the technical code perspective. I have also been referring to this as the test-first onion rings, where the TDD is the inner ring and BDD makes the outer ring.
Image: infolytx.com
BDD extends this same concept and adds to it the idea that the tests should be written in easy-to-understand domain-specific language (gherkin), and that they should express user acceptance criteria. I would refrain from getting into a full blown implementation tutorial on BDD and only highlight that BDD is a collaboration framework amongst the Developers, Testers and PO/BAs, popularly referred to as the “three amigos”.
The Scaling challenge:
When doing BDD at a team level, with light facilitation all this falls in place seamlessly as long as we can avoid the usual anti-pattern of:
However new problems surface while working in scaling model and handling delivery alignment across several teams. In my experience I have seen that initially most enterprises follow Scrum and scale using Scrum of Scrums, at a later stage deploy the scaling framework such as SAFe. A lot depends upon how these Scrum teams, which are typically in various stages of Agile maturity, adopt the framework to coordinate and align with each other.
.png?width=946&name=SoS%20(1).png)
Image: https://agilevelocity.com/
As a precondition to BDD, it is imperative to ensure that there is consensus on the feature backlog and the “Day-1” functionality by taking an economic view. This can be challenging as every business group might want their set of features to live first and need facilitation to reach a resolution.
At the team level we can overcome the usual BDD anti-patterns as listed above. But while working with a bigger and diverse set of business teams, we not only needed to prioritize the backlog but also ensure that this get jointly owned by everyone with a set of business SMEs identified that can work as part of three amigos BDD team. For this purpose having a proxy PO in the teams does not work given the complexity and diverse nature of the product being built, we need the customer’s voice.
We need to think ahead while solving the current problems and here is what I propose:
Step 1: Conduct Feature prioritization workshop using Weighted Shortest Job First
(WSJF) method
Step 2: Having the high-level sizing for features, create Solution Roadmap sequencing the Day1 and Day1+ feature list.
Now not only we have a list co-created and thus owned by all the business heads and while doing this exercise they also identify the domain experts for these features in an organic way. This is very much required as while scaling BDD, we cannot blindly go with the paradigm - Collaboration = Shared Responsibility.
There is a great Chinese proverb which translates to “The shared courtyard never gets swept”. If it’s everybody’s problem, then it is nobody’s problem.
And therein lies the danger.
BDD Collaboration led by the DRIs:
Now the program can be structured for the feature families that rollup to Epics with dedicated Feature Delivery Leads from Business and they worked with the cross functional feature family teams. These Feature Delivery Leads are inspired from the famous Directly Responsible Individuals (DRIs) by Steve Jobs. The aim of BDD is collaboration and gaining transparency over the features to enable program delivery and testability for shared understanding. This leads to faster responses from business and helps accelerate decision-making.
This culture needed to be propagated and visualized at the team level as well and it can be achieved using what I call as the BDD Kanban.
BDD Kanban:
The flow is enabled with each column having a specific responsible team to pull from previous and each column has Definition of Done. We also need to maintain WIP limit for each column which should be reviewed continuously by the Scrum Masters for the respective teams.
BDD Kanban working rules:
One metric
%C&A ~= 100%
All this can be immensely supported by the live dashboards (driven by continuous integration and continuous deployment) that display filters on Gherkin tags and the trends that roll up from team level stories to program level features. Another important aspect is having BDD for the APIs given initial sprints are focused on technical enabler stories. The components teams focus on building architectural runway without the user interface to be consumed only by other feature driven teams. These stories are later pulled into the sprints to develop the UI however since we used BDD scenarios with test doubles and clear specification in business language we can enable the business to assign the Business values to such features and also evaluate progress on the dashboard and assign Actual Value at the PI System demo. More details on the technical execution of the above in the future blogs.
Please Visit Remote Training Calendar 2022
