Hello everyone and welcome to the Cognixia podcast!
Every week, we bring you an exciting new episode full of interesting information about the latest emerging technologies. And we are back with a brand-new episode of the Cognixia podcast.
This week we are going to talk about something very interesting – SAFe 5.1 and Behavior-driven Development. In today’s competitive environment, these two are very, very important, so we decided let us have an episode discussing these. So, without any further ado, let’s begin!
Before we get into the details of behavior-driven development, let us first talk about SAFe.
What is SAFe?
SAFe is a knowledge base of proven, integrated principles, practices, and competencies for achieving business agility using Lean, Agile, and DevOps. The latest version of SAFe is SAFe 5.1, which is built around the seven core competencies of the lean enterprise that are critical to achieving and sustaining a competitive advantage in these increasingly digital times.
Now, what are these seven core competencies? These seven core competencies are:
- Lean-agile leadership
- Team and technical agility
- Agile product delivery
- Enterprise solution delivery
- Lean portfolio management
- Organizational agility, and
- Continuous learning culture
SAFe 5.1, the latest version of SAFe aims to enable the business agility that is required for enterprises to compete and thrive in the digital age.
To achieve this, every function in the organization to actively adopt the principles and practices of lean and agile, be it development, operations manufacturing, legal, marketing, finance, compliance, or sales.
Now that we have a fair understanding of what is SAFe, let us move our attention toward understanding what is behavior-driven development.
Behavior-driven Development or BDD is a test-first, agile testing practice that enables one to achieve built-in quality. This is done by defining and automating the tests before or as part of specifying system behavior. Behavior-driven development is a highly collaborative process that aims to create a shared understanding of requirements between the business and the agile teams.
There are three key goals of behavior-driven development:
- Guiding development
- Decreasing rework
- Increasing flow
Behavior-driven development tests do not usually focus on internal implementation. Instead, they revolve around business-facing scenarios that go on to detail the behavior of a particular feature or a capability from a user perspective. Once these BDD tests are automated, the system will constantly meet the defined behavior, even if your system is evolving. When this happens, the teams can deliver a Release-on-Demand. These automated BDD tests are undoubtedly a very definitive statement about the as-built system behavior and effectively replace the other types of behavioral specifications.
When an enterprise is developing innovative systems, it can be challenging to align on exactly what to build. Communicating new ideas is another challenge faced by enterprises, especially when a diverse set of stakeholders are involved in system implementation. So, to define solution behavior, three perspectives would be needed:
- The perspective of customer-centric stakeholders who understand customer requirements and business needs, based on which they can gauge the relative desirability and viability of a new requirement
- The perspective of development-centric stakeholders who understand the solution space and can discuss the technical feasibility of the new requirement
- The perspective of the test-centric stakeholders who understand the testing process and can provide a thorough analysis of the exceptions, edge cases, and boundary conditions for the new behavior
In essence, it can be said that cognitive diversity is essential to define solution behavior. When all these three perspectives are available and combined, the teams have a better picture of what needs to be developed thereby reducing possibilities of rework and errors, in turn accelerating the flow of value.
This is what behavior-driven development is all about. Now while we are at it, let us take a peek into the behavior-driven development process, shall we?
The BDD process has three key phases:
During these phases, the acceptance criteria evolve into acceptance tests and eventually get automated.
In the discovery phase, a product owner or a product manager would define the acceptance criteria for the behavior-driven development being undertaken, in the form of writing say a story or a feature. This phase is super collaborative and the team members would be actively involved in contributing to this criteria-defining process. During this phase, the backlog items would gradually move closer to implementation.
Once it is closer to implementation, the next phase – formulation begins. During this phase, the acceptance criteria would be strengthened further by devising acceptance tests. Initially, it is understandable that the acceptance criteria would be ambiguous or very generalized and maybe even a little vague, which is ok, there is a whole process they will go through, and it will get better down the timeline – and this would take place during this formulation phase. During the formulation phase, the ambiguities will be eliminated as during this phase, the acceptance criteria are transformed into very detailed acceptance tests. These acceptance tests would be very specific, clear, and unambiguous.
The last phase in BDD is the automation phase. As the name suggests, this phase would automate the acceptance tests that got designed in the formulation phase. Automating the tests enables the enterprise to run the tests continuously and also validate that the system is equipped to support the new behavior at all times.
Here, it is important to understand that the main emphasis of behavior-driven development is eliminating unambiguity and not just devising the acceptance tests and automating them. Also, it is important to note that these acceptance tests would work as a means to record the decisions which get made by the team and the product owner or the product manager, enabling the team to get a better understanding of the specific and intended behavior.
Sometimes, the behavior-driven development process is also referred to by some other names, such as:
- Behavior-driven design
- Acceptance test-driven development
- Specification by example
Now with the different names, there could be some slight variations in the approaches, but more or less they signify the behavior-driven development process.
To conclude, we will like to emphasize one very important thing – why is important to automate these acceptance tests? The tests can be carried out manually just fine too. The key reason here is to support regression and continuous delivery. In today’s fast-paced times, continuous delivery is more important than one could even imagine. It is also necessary to remember that these story acceptance tests would be written and executed in the same iteration as the code development. The simple thumb rule here would be that s a story does not clear the acceptance tests, the team working on the story would get no credit for it. New features and capabilities would require their own acceptance tests which would involve multiple stories working together in a much broader context with much larger workflow scenarios, with iterations running all along the time the feature or capability is realized.
So, that is all about behavior-driven development. That’s one very interesting and efficient process now, isn’t it?
And with that, we come to the end of this week’s Cognixia podcast. Now, as we said before, SAFe 5.1 is very important in today’s competitive and fast-paced times. So, if you would like to learn more about SAFe 5.1, a good step to take would be to be a Certified SAFe Agilist. And, you already know what you need to do to get started, right? Reach out to us on our website, on our social media handles, call us, drop us a WhatsApp, any way you prefer, and we will reach out to you, guide you through the whole process, and you will be all certified and ready to take on the world in no time! So, find us and talk to us today!
Until next week then!
Happy Learning, folks!