Welcome!

My "Quick" Thoughts

Early in my career, I came across the idea of Behavior Driven Development as a way to help teams close that "communication" gap between business, technical and project stakeholders.

Figuring out what a client wants can be tough sometimes. Any company or person trying to understand what their client wants probably has experience in hearing we delivered something close to what they wanted but still missed the mark and didn't provide them with the most value?

Most days, I feel competent enough to meet my client's needs. Make this do 'x', patch this, add this new feature, analyze these bugs, etc. Each year, I try to work on myself and try to improve what value I bring to the table (regardless of the role). Improving a current skill, learning a new one, or just sharing whatever knowledge I have learned. I try to add value.

It's all about the conversation

John Ferguson Smart instructor of various courses on Serenity within the Serenity Dojo. He stated "it's all about the conversation." After 10+ years in software development, I 100% agree. I would argue even the client isn't 100% sure on what they want, at least not initially.

An idea of how the page should look, how elements interact with each other, what the page flow should be, and much more are sometimes decided early on. Prior to a team fully understanding what business problem their trying to solve.

With more discussion around examples of what high-level steps our users might take within our system; improves team collaboration, understanding, and much more.

"Men have become the tools of their tools." -- Henry David Thoreau

It's easy to get fixated on an idea/behavior and continuously run with it; not realizing it's causing us more harm than good.

A specific technology, a tool, or even a way of how one might run a grooming meeting when breaking down the team's work are things we can get caught up in doing the same ol, same ol. We spice it up by adding a little bit of "the new" and get a sense of safety for the moment. Not realizing those little adjustments are just blinders to help us make an excuse for why we shouldn't take on a bigger change, adapt, and really explore the unknown which may (and most likely) provide you the most value.

Imagine a scenario where the power goes out at your house in the middle of the night and you have to flip the main breaker to reset the power. You grab a flashlight and, with the house completely dark, you shine the light straight toward the door leading to the breaker. You quickly make your way to the door and, without shining the light in those dark areas; focused on that door, you stub your toe against a toy in the way of your path.

You've made it. But oh the pain and cost it took to get there. Even with this project, I've had times where I hyper focused on one way of doing it and have had to redo multiple portions. Especially as I read and learn more about BDD and using Serenity BDD). I too put blinders on.

Why this project?

Let's take off the blinders and explore the unknown together! At least for this project. The incredible value a team can gain from having those 'good' conversations around what they are delivering is, in my opinion, invaluable. Now I would like to try and bring that knowledge to others by running through a mock project. This project.

I’m still learning about Behavior Driven Development, and it will show — in this project and more. However, this project is going to be the starting pad for me to learn and apply BDD while using the Serenity BDD framework.

"Policy Search with BDD POC"

Behavior Driven Development (BDD) is more than just a development method; it encapsulates a cultural shift within companies and teams. It encourages collaboration, user-focus, and an iterative approach to software development. It harmonizes seamlessly with agile processes to enhance the software development lifecycle (SDLC).

With this in mind, a small group of co-workers and friends wanted to join me in trying to bring BDD to life and see Behavior Driven Development in action. No, not just by reading the 'BDD In Action' book. By helping me in this POC project. I hope, as we develop the application, we get to experience the full capabilities of adding BDD to our SDLC. By practicing BDD in a conscious, purposeful way, we hope to:

1. Illustrate our shared understanding through example mapping examples. Helping our team focus on having those meaningful conversations around the business requirements to ensure everyone is on the same page.

2. Formulate executable specifications from our example maps (groomed during our meetings) for our team and stakeholders to use as a clear explanation on what value is being provided to the client.

3. Automate the same executable specifications, or scenarios, to ensure our team remains focused on delivering the ultimate value out of our application. It also helps ensure developers focus on best practices while they Create the software to pass those automated test.

4. Demonstrate those scenarios by leveraging Serenity BDD reports to capture comprehensive insights (including images) on all the behaviors early on in the SDLC so stakeholders can get real-time updates on the development progress.

Where to now?

Head on over to the Starting-Mock-Scenario to get an idea of how I visualized the start of this project going with a mock team.

Upcoming ...

Links etc. to deployed application, reports, etc.