A 2006 Gartner report defined Business Agility as
an organization’s ability to sense environmental change and respond efficiently and effectively to that change. (1)
being able to deploy change in business policies and business rules into day-to-day business activity as fast as business people and Business Analysts can determine the full business impact of the change and assess whether the change makes good business sense (2)
By these definitions, Business agility is different from Agile methodology and BDD.
What does Agile Methodology solve?
In a software project, the problem is that we have two groups of people:
- Stakeholders, customers, users
- Programmers, testers
And we have to improve communication between these groups of people. They come from two different worlds, they speak different languages and they have two different concerns and mindsets.
The success of a software project requires a way of improving communication between these two groups. In an agile approach we use user stories to highlight examples of how we would use the functionality that we are describing.
Agile methodology helps to deliver a project chunk by chunk instead of designing and implementing the whole project upfront.
What is Behaviour-Driven Development (BDD)?
BDD focuses on value and explicitly creates a list of the examples that are gathered collaboratively with technical and non-technical people in the team. The examples that are valuable from both a business and technical perspective.
That approach is incredibly useful because it is readable by non-technical people and creates documentation that describes behaviour of the system that will continue to be accurate over time. That is the specification of a software solution that guarantees the solution does what it is intended to do. Using this approach, the Subject Matter Expert (Domain expert), BA and QA collaboratively work on scenarios and formulate a domain specific language (DSL) to define the behaviour of the system.
Using BDD automated testing tools as part of your development environment turns DSL into a testing mechanism for specific behaviour, and when the programmer has implemented a particular story and realized the BDD scenario, the tests will pass. This is the ‘Test First’ principle of the agile approach.
So when the developer programs to match the behaviour which is defined and specified collaboratively by a team, that is a live specification of the software which is readable and understandable by both non-technical and technical people.
So as far as a BDD is concerned, a definition of a scenario might look like this:
Scenario: Account is overdrawn past the overdraft limit Given account is overdrawn And the card is valid When customer requests cash Then ensure a rejection message is displayed And ensure cash is not dispensed And ensure the card is returned
This scenario is written by BA and QA, and developers will be linking different steps of this scenario to the underlying application functionality. The whole scenario will then be part of an automated build pipeline. When any code is changed and pushed into the build pipeline, this BDD makes sure that the application still works as expected.
What is needed for business agility?
Business agility is the ability of a business to adapt rapidly and cost efficiently in response to change in the business environment. (3)
If we do not let business people modify and extend the behaviours of our application in ways with which they are comfortable, we cannot achieve business agility, even if we have used agile methodology on the development side of the organization. What we can do is provide capabilities in our software that lets our customer achieve business agility. In order to do this, our application must be able to be configured and customized at the customers site in a way they understand. Yet what can guarantee they understand and know how to define and customize behaviours in our system? Nothing – unless our software can speak their language.
So far, we have seen the benefits of DSL in testing. Now let’s say we define a domain specific language (DSL) for the previous scenario that:
1. Is understandable by all stakeholders
2. Can be changed at runtime
3. Defines and derives system behaviour
Then when our organization senses environmental change, it is able to respond efficiently and effectively to that change by modifying the components that drive the software.
In the above mentioned BDD scenario we are just testing the system behaviour in a development environment. Now here is the exact DSL that can implement your application behaviour in a way all those groups of people understand:
@name Account is overdrawn past the overdraft limit given customer, account, card, transaction when customer requests cash account is overdrawn and card is valid then set message state of transaction to “Displayed” set state of card to “Returned” end when account is overdrawn balance of account - amount of transaction <= limit of account end when card is valid state of customer is Active and state of card is Valid and expire date of card < today end
The good thing about this is that it is not just a static and fixed DSL. You can extend it by itself using its DSL! Have a look at the scenario when “customer requests cash”. The first step of the scenario is checking if the “account is overdrawn”. Now this behaviour itself is defined in the DSL too. So you are able to extend the DSL functionality dynamically.
Now this is an executable component of your application that can be changed and drives the application behavior. No need to change the application code. No need for compilation. It is understandable by all groups of technical and non-technical people. That is one of the many things BRMS offers you in order to enable customers to achieve business agility. They sense an environmental change, and now they are able to change the software to their benefit.
- Advanced Domain Specific Language for Business
- Business Glossary
- Business Rule Language
- Agile methodology and BDD vs Business Agility