We don't talk enough about how important change management is for successful BDD

Recently, we had a really interesting conversation regarding the differences between BDD and BDA Is Cycle “doing BDD”? and discussed where Cycle fits into that equation.

@branko makes a really good point that:

BDD on the other hand has its purpose but it’s not automation. It’s a development practice. But it turns out that behavior in prose can be used to drive automation.

Ok got it - so BDD is a practice that may or may not involve automation. It’s really about alignment, collaboration, and requirements discovery. And that’s great. But, the challenge I have, is that the need to realign, to discover new requirements, to readjust and make changes to the system under test never stops. So, in the truest sense of BDD (and I’m talking about the purists’ view out there) is BDD impossible to achieve once an application has been deployed for the first time? Or can we back into it?

At Cycle, we often engage with a customer when they have a need to introduce automation to solve ongoing issues - almost always after the solution has been in production for sometime. We aren’t afforded the luxury of starting at the beginning with them but we do have an opportunity to improve quality by conducting BDD-like ceremonies, producing meaningful and valuable Feature files that realign the team, help discover miscommunications and missed requirements. And ok, since we aren’t starting before the solution was deployed maybe this isn’t BDD in the purist sense – maybe like @branko points out it’s really BDA.

It seems like the question at hand isn’t how you’re approaching the construction of the Feature files and automation but simply a question of when you did it. So can the ceremonies be the same but BDA not be BDD because you are starting after the fact? It’s an interesting question.

At Cycle, what we are seeing is that we can often prove the value of behavior-driven testing strategies (call it BDD or BDA) by coming in after the fact, producing meaningful Features and eventually working our way left (shifting-left) such that new changes are actually pushed through a more traditional BDD process BEFORE production. But we did’t start that way ---- we needed to prove the value first.

So can BDA actually become BDD? Is BDA a gateway to BDD or can you never get there once an application has been deployed? If new changes are introduced by using BDD but the original Feature files were built using BDA – where do those two concepts come into alignment? It seems like @magowan has some practical experience doing this with our largest customers and I would love this thoughts.

And all of that aside, I think we often get so hung up on the concept of “is it BDD or not” that we overlook the amount of organizational change management required to actually meaningfully change how these large organizations work. Moving to a purist version of BDD practices/ceremonies is not a small feat. At a smaller organization or startup maybe we can get everyone around the idea and start that way. But in large enterprise organizations, it really takes a massive change and organizational commitment from the financial stakeholders, the project managers, the business analysts, the systems analysts/developers and the QA team to make that shift happen. And to make a change like that is expensive in terms of resources when an organization may not necessarily buy into the value of that change. Change after all, is uncomfortable.

I see a ton of back and forth online regarding whether something is BDD or not. But I don’t see a lot of discussion about the incredible amount of organizational change it takes to shift how these organizations work. Why is that?

Are we too hung up on when something starts and what it is to focus on what it takes to actually achieve the benefits?


@jillian.ketterer - I would love your thoughts on this. I know change management is close to your heart :slight_smile:

@basdijkstra / @heathh / @AutomationPanda - What do you think? Why don’t we see that much conversation around the change management aspects of what it takes to achieve BDD in larger organizations?


Time is not linear in software. Many things that will exist in the future in software actually already exist. Example, in ecom systems people have been ordering widgets for 20+ years. Therefore the software solutions to produce an online order already exist. So, if you are working on ecom software today, you aren’t developing something new even though it might feel like that. You are improving on existing solutions, although you may have done this without the code that was originally written in that first online ecom system. Even then, you didn’t start from scratch. You likely used existing building blocks to do the heavy lifting. And certainly you used existing concepts and designs. Folks aren’t re-writing online credit card processing. They are using Stripe. Or even more to the point, are developing their stores on things like Wordpress or Drupal or Magento and the like.

Rarely is a thing “new” in software, so if we have to start “fresh” to abide by a process, then that process isn’t likely to work in software efforts.

The most successful changes I have see in the field with respect to a “better” way, a more “modern” way have started small with one step. Pick a thing, any thing. Try your thesis out. I’ve done this with components of what people might call BDD like an example map. I find that people are receptive in trying out an idea to help clarify the problem. The trick where @jillian.ketterer 's passion comes in handy is having a champion on hand to carry that break through forward and to enlist the next decision maker, and then the next decision maker, and then the next decision maker until suddenly we wake up and see an example map on the morning news to help clarify a problem :wink:


Wow, such an interesting topic.

Well, I think in general that:

  1. People and teams don’t change until they are ready.
  2. Readiness can be determined a lot of ways, but I see it as (a) they believe they have a problem, (b) they want it solved, (c) they will find the resources necessary to make the changes needed to solve it.
  3. Readiness in an organization varies across teams/hierarchies, but it always helps to get decision-makers and champions on board because they can help to instigate and manifest readiness to change across teams/hierarchies.

I think one of the challenges teams have with changing to BDD is that one or more aspects of readiness is missing (in #2).

For example: If there is a disconnect between the user’s needs and the stories a dev team is working on, the development team believes implicitly that they are meeting users’ needs if they satisfy the requirements in the story. If resulting feedback does not flow back to a development team and spur iterations on previous work, the gap that BDD helps to fill may not be obvious to a dev team. So, they don’t believe they have a problem.

Another challenge is that decision makers (#3) don’t always (or often) care about the development process or the details of “how” work gets done, so getting their support in instigating readiness to change to BDD can be something of an art. You have to start with outcomes they care about and are not getting, and then walk them toward the gap in a way they can receive, and in a way that motivates them to support a different way of working.

If I am ok with the status quo and I am getting all the outcomes I care about, I’m not motivated to change status quo, especially if I am comfortable. I need to be uncomfortable and in search of something better. Further, if someone is happy with their process but I come along and point out issues with it and ways it could be improved, they might be more likely to get defensive than open to change.

A team member, team, or decision maker asking for help with a certain thing is often a good predictor that they might be ready and willing to change to solve that problem.

It sounds so obvious when I type it out, but it is amazing how these fundamental human principles can get lost once we start working together on software (or anything, really). I’m certainly guilty of forgetting sometimes!

From a BDD perspective, automating tests after the fact implies that the automation phase is either missing or lacking in the development process. The challenge to transition then becomes how to fill that gap. It’s a bit like writing unit tests after all the code has been implemented. It’s not easily done and not particularly enjoyable either. To successfully shift testing left, the ability to integrate automated testing into the development process and CI pipelines becomes necessary. For Cycle, this would mean cycle tests.

Can the transition be made after the code has already been deployed? I think it can be done gradually if the testing can easily be integrated into CI. BDD is an iterative process and you can start doing it for new features or change requests at any time. But the questions then become; How much of your Cycle testing (for example) would you move across? How much confidence is required to release? Is it more or less testing than what is done currently? How is testing after the fact then impacted?

To transition, you need to have stakeholder buy-in and you need to enable developers and testers to automate and run tests during development and not after. These should run often and ideally; quickly. All of this can be a large shock to all parties involved in an existing project and have ripple effects on existing processes and seemingly impossible for large enterprises. Splitting up a large project into smaller micro-projects and adopting BDD on those (or just one of them to start with) might be easier.

1 Like

Great points, @branko! The questions you pose truly are the operative ones, aren’t they!?

At Cycle Labs, most of our customers aren’t actually developing anything. They are implementation/deployment teams who are using packages solutions to drive critical business processes. So our “development” phase is really more of a configuration phase most of the time - but I think the principles still apply.

And I think your point on integrating Cycle tests into CI is a really interesting one. That is where a lot of our focus is now – ensuring the tests we build become part of a deployment pipeline and are continually used for future changes. This means we have to ensure we are finding that balance of automation/value and only building tests that truly provide ongoing ROI and risk reduction. Then, further, we are educating our clients on why they should be using automation & CI/CD to manage these deployments.

Part of our mission is proving that deploying these existing systems face the same challenges as building software from the ground up (like miscommunication, misalignment, and missed requirements) because practically speaking – we are still building software it’s just that we are using larger building blocks (existing solutions not code).

And I think you’re right - and I believe what we are seeing in our projects is that we have to start small. Get a few BDD wins, prove the value, then expand.

1 Like