Podcasts about behavior driven development

En este episodio, tenemos el placer de recibir nuevamente a uno de nuestros Engineering Leads, Pablo Carballo. Pablo nos ha acompañado en otros episodios del podcast para hablarnos sobre SBE y el rol de Team Lead. Sin embargo, en esta ocasión, y a raíz de su nuevo blog post sobre Automatización de Testing, vamos a profundizar en este tema tan relevante. Además de compartir su conocimiento sobre automatización, Pablo nos contará sobre su trayectoria y nos contará su experiencia trabajando durante dos años para un cliente americano, aportando una perspectiva valiosa sobre el desarrollo y la automatización de testing.  ¡Esperamos que disfruten de la historia y los aprendizajes que Pablo tiene para compartir en este episodio! Herramientas y fuentes mencionadas en este episodio:  Especificación del hub https://thebddcoach.com/ Behavior Driven Development with Cucumber Specification By Example

Conosciamo Peter Bittner, co-maintainer di behave e appassionato di testing in Python. Scopriremo come ridurre gli ostacoli a un testing efficace ed entreremo nel mondo del Behavior-Driven Development (BDD).

In this episode of the Add Dot podcast, Vaughn Vernon and Paul Rayner discuss the evolution of the Domain-Driven Design (DDD) community in North America. The conversation highlights the importance of fostering connections and providing valuable learning experiences.Throughout the conversation, Vaughn and Paul share insights into the complexities of modernization efforts, particularly in large organizations with legacy systems. They stress the importance of strategic thinking, focusing on core domains, and avoiding the "boil the ocean" approach. The episode concludes with a teaser for the upcoming Explore DDD conference in Denver, Colorado, scheduled for March 12-15, 2024, featuring keynotes by Eric Evans and Vaughn Vernon.Paul Rayner is a developer, instructor, coach, consultant, and popular conference speaker with over thirty years of software development experience. Paul provides DDD and EventStorming training and coaching through Virtual Genius.Paul is the founder and chair of the Explore DDD conference, the premier Domain-Driven Design conference in North America, and co-founder of DDD Denver. He is also the author of The EventStorming Handbook, and a co-author of Behavior-Driven Development with Cucumber. He lives in Denver, Colorado. Hosted on Acast. See acast.com/privacy for more information.

Cette semaine dans Qalisty, on parle de BDD. Vous ne savez pas ce que c'est ? Cliquez sur l'épisode, vous ne serez pas déçu. Mon invité, Jeremie, nous y explique pourquoi et comment cette méthodologie peut amener à une meilleure organisation du point de vue des tests mais surtout à une meilleure communication entre les parties prenantes sur un projet digital. Retrouvez Jeremie Ici. Ressources citées dans l'épisode : The "Future of QA" Let the code Speak - Cypress vs Selenium Guide du BDD Quel framework de test automatisé ? "Let the engineers speak" Le TDD - La taverne du testeur Si cet épisode vous à plût, parlez en autour de vous, c'est la meilleure manière de faire connaître ce podcast.  N'hésitez pas à me suivre sur Tik tok: @⁠Qalistypodcast⁠ et instagram : @⁠qalisty⁠ . Et si vous avez des questions, ou juste envie d'échanger, vous pouvez me contacter sur Linkedin : Nancaidah Touré-Chauvin Crédits : Musique par Uppbeat : https://uppbeat.io/t/hybridas/open-spaces License code: PF01L4PTL1WPDXBG

BONUS: The Art Of Crafting User Stories with Christopher Lee In this episode, we talk with Christopher Lee about his latest book, "The Art Of Crafting User Stories." Christopher shares the fascinating origin story of his book and how principles of product management were applied to its creation.  Product Development Insights Christopher draws intriguing parallels between software development and book creation, highlighting two key concepts that apply to both realms. He introduces the concept of "debugging for books" and shares essential tips, like the importance of having multiple content reviewers and utilizing the technique of "Rubber Duck Debugging" for authors. The examples he uses also clarify how his approach to Product Management can help you with software products. Learning To Empathize With The User We discuss how understanding the user perspective is a critical skill for Product Owners and teams, and enables them to write better User Stories. Christopher emphasizes the development of perspective-taking and compassion for others, starting with self-reflection. He introduces tools like "The Feeling's Wheel" and explores the concept of uncovering the needs behind user needs, known as "Jobs to be Done." In this segment, we also refer to User Story Mapping, Google Design Sprints, and the book Radical Candor. Crafting User Stories: Avoiding Ambiguity Christopher shares some of the most effective tools to help teams truly empathize with their software users, fostering a deeper understanding that can greatly inform the user story process. Delving into the actual act of writing user stories, Christopher provides invaluable advice on avoiding ambiguity. He advocates for collaborative efforts with engineering and design teams, using user stories as a foundation. Additionally, he introduces the "Given - When - Then" format for clarity and efficiency. Navigating User Story Estimation, Other Planning Challenges  Christopher addresses common challenges in user story estimation and emphasizes the importance of adaptability in Agile and User Stories. He offers strategies to prevent downstream consequences and encourages direct engineer-user interaction for swift feedback. Prioritization is a critical aspect of planning that Christopher dives into, providing a toolkit of models and methods. He emphasizes the importance of aligning product development with organizational mission and North Star metrics, ultimately honing in on the right end-users. Expert Interviews, Bringing Different Perspectives On User Stories Christopher introduces a unique element in his book—expert interviews. These interviews offer diverse perspectives on Agile, user stories, and collaborative work, enriching the reader's experience and understanding. Parting Words of Wisdom In a final piece of advice, Christopher underscores that crafting user stories is a team effort, emphasizing that no one person can do it alone. About Christopher Lee Christopher Lee is a seasoned Product Management Coach, known for his expertise as a product manager and technology consultant. His insights into the industry are encapsulated in his book, 'The Art of Crafting User Stories', and advanced product management methodologies he created when at Ernst & Young. You can link with Christopher Lee on LinkedIn and connect with Christopher Lee through the Product Coach Labs.

“BDD is about helping you collaborate with the different parties involved in software delivery to understand what's actually required of your system, why you need to deliver it, and then find the best possible way to automate your requirements." John Smart and Jan Molak are the co-authors of “BDD in Action: Second Edition”. In this episode, we discussed in-depth behavior-driven development (BDD) and its essentials. Jan and John first began by introducing what BDD is, the benefits of using BDD, and the Gherkin language with its given-when-then syntax. They gave advice on how to introduce and apply BDD, especially for legacy software, and how to manage the BDD specifications effectively. Jan and John then shared several BDD techniques, such as feature mapping, example mapping, impact mapping; and went deep into the screenplay pattern and the Serenity projects they both create to implement screenplay pattern. Towards the end, Jan and John shared their insights on which testing layers we should apply BDD and some anti-patterns we should avoid.   Listen out for: Career Journey - [00:04:49] Challenges Before BDD - [00:11:30] Behavior Driven Development (BDD) - [00:15:24] Benefits of BDD - [00:22:33] Gherkin - [00:27:39] Introducing BDD - [00:32:24] BDD for Legacy Software - [00:38:41] Managing BDD Specifications - [00:43:15] Screenplay Pattern - [00:47:09] Serenity Project - [00:58:42] Other BDD Techniques - [01:11:33] Testing Layers to Apply BDD - [01:14:13] BDD Anti-Patterns - [01:18:28] 4 Tech Lead Wisdom - [01:23:01] _____ Jan Molak's BioJan Molak is a consulting software engineer and trainer who specialises in enhancing team collaboration and optimising software development processes for global organisations. Jan is the author of the Serenity/JS acceptance testing framework, a contributor to the Screenplay Pattern, and a co-author of a renowned book “BDD in Action, Second Edition”. John Ferguson Smart's BioJohn Ferguson Smart is a specialist in BDD, automated testing, and software lifecycle development optimization. He is the founder of the Serenity Dojo, an online training platform for testers who want to become world-class Agile Test Automation Engineers, and the creator of the Serenity BDD test automation framework. Follow Jan: LinkedIn – linkedin.com/in/janmolak X – @JanMolak Follow John: LinkedIn – linkedin.com/in/john-ferguson-smart X – @wakaleo Serenity Dojo – serenity-dojo.com _____ Our Sponsors Miro is your team's visual workspace to connect, collaborate, and create innovations together, from anywhere.Sign up today at miro.com/podcast and get your first 3 Miro boards free forever. Like this episode? Show notes & transcript: techleadjournal.dev/episodes/148 Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Buy me a coffee or become a patron.

The podcast by project managers for project managers. How can agile project managers create conditions for self-organizing teams to thrive? In the agile world of a self-organizing team, the trend is to empower the team so the individuals doing the work can make decisions. So, what role do project managers play?  Hear about the three responsibilities of the new agile leader and some important skills to level up in order to lead an agile project. Table of Contents 03:03 … Humanizing Work03:50 … Empowering Decision-Makers05:21 … Changing the Role of Managers08:20 … Challenges for Project Managers09:32 … Complex Systems11:33 … Defining the PM Role13:58 … Coordinate and Collaborate16:35 … Who Does It Well?18:29 … What's in a Title?20:33 … The Three Jobs of Agile Management23:49 … Project Manager Skills27:25 … Visualization Skills33:10 … Is Agile Right for Me?36:39 … Contact Peter and Richard38:19 … Closing PETER GREEN: ... one of the things that has been an underlying theme to these amplifier skills we've talked about – coaching, facilitation – is a real trust that the people doing the work can figure out how to solve it if I do the three jobs well.  If I create clarity, if I increase capability, and if I improve the system for them, they will be able to knock this project out.  They don't need me to manage it... WENDY GROUNDS:  You're listening to Manage This, the podcast by project managers for project managers.  My name is Wendy Grounds, and with me in the studio are Bill Yates and our sound guy, Danny Brewer.  We're so excited that you're joining us, and we want to say thank you to our listeners who reach out to us and leave comments on our website or on social media.  We love hearing from you, and we always appreciate your positive ratings.  You will also earn PDUs for listening to this podcast.  Just listen up at the end, and we'll give you instructions on how to claim your PDUs from PMI. Our two guests today are from Colorado and from Arizona, so we're kind of jumping around the place.  But we're very excited to have Richard Lawrence and Peter Green from Humanizing Work join us.  Richard's superpower is bringing together seemingly unrelated fields and ideas to create new possibilities.  Richard draws on a diverse background in software development, engineering, anthropology, design, and political science. He's a Scrum Alliance certified enterprise coach and a certified scrum trainer.  His book “Behavior-Driven Development with Cucumber” was published in 2019. Our other guest is Richard's co-worker, Peter Green.  At Adobe Systems, Peter led an agile transformation and he co-developed the certified agile leadership program from the Scrum Alliance.  He's also a certified scrum trainer, a graduate of the ORSC coaching system, a certified leadership agility and leadership circle coach, and the co-founder of Humanizing Work.  What I found interesting was, with all his other creative activities, Peter is also an in-demand trumpet player and recording engineer. BILL YATES:  Which will appeal to Andy Crowe, our founder, because he loves to play the trumpet.  Wendy, we are delighted to have Richard and Peter join us.  We've had conversations planning for this today with them, and they bring so much knowledge and experience to the table.  Here's the thing.  Project managers traditionally are taught to direct and control team members.  So what role does management play in the agile world of a self-organizing team?  If my team's self-organizing, what am I supposed to do; right?  How can they create conditions for self-organizing teams to thrive?  What is the function of managers in this new world, and what does an agile organization need from its management team?  Those are some of the questions that we want to tease out with them today. WENDY GROUNDS:  Hi, guys.  Thank you so much for joining us. RICHARD LAWRENCE:  It's great to be here. Humanizing Work WENDY GROUNDS:  We first want to find out a litt...

Want to know how to deliver software that does what it's supposed to do? In this episode, John Ferguson Smart, author of the book BDD in Action, shares how to use Behavior-Driven Development to guide your software projects to success with collaboration, communication techniques, and concrete requirements you can turn into automated tests. Discover how BDD positively affects teamwork, dynamics, and stakeholder collaboration to help teams discover and analyze needs, uncover assumptions, reduce risks, make acceptance, integration, and unit testing more effective, automate reporting and living documentation to improve transparency, and much more. Listen up!

En este episodio hablamos con el desarrollador Full Stack Pablo Carballo, que nos cuenta sobre su proyecto con una empresa en EEUU dedicada a crear motores inteligentes y sustentables. Pablo trabaja bajo la metodología Specification by Example, y en esta conversación nos cuenta de que se trata el SBE y sus beneficios a los proyectos de desarrollo. Links mencionados en este episodio: “Specification By Example”, de Gojko Adzic: https://www.amazon.com/Specification-Example-Successful-Deliver-Software/dp/1617290084/ “Behavior Driven Development with Cucumber”, de Richard Lawrence y Paul Rayner: https://www.amazon.com/Behavior-Driven-Development-Cucumber-Collaboration-Software-ebook/dp/B07S649RQ8/ Para aprender el lenguaje Gherkin: https://behave.readthedocs.io/en/stable/ ¡Seguinos! @octobotdev en Twitter, Instagram y Dribble, y @octobot en LinkedIn

Conhecendo BDD (Behavior Driven Development) Links úteis: https://docbehat.readthedocs.io/pt/v3.1/guides/1.gherkin.html Meetup: https://www.meetup.com/dotnet-RioPreto/ Weekly: https://dotnetriopreto.substack.com/welcome Youtube: https://www.youtube.com/channel/UCGbvC7EK7E-SnHLvpmvFvwA Twitter: https://twitter.com/dotnetriopreto Discord: https://discord.gg/rDVQypBc Link do Whatsapp: pergunte para um dos administradores. Código de Conduta: https://github.com/dotnetriopreto/codigo-de-conduta

00:58 - Paul's Superpower: Participating in Scary Things 02:19 - EventStorming (https://www.eventstorming.com/) * Optimized For Collaboration * Visualizing Processes * Working Together * Sticky (Post-it) Notes (https://www.post-it.com/3M/en_US/post-it/products/~/Post-it-Products/Notes/?N=4327+5927575+3294529207+3294857497&rt=r3) 08:35 - Regulation: Avoiding Overspecifics * “The Happy Path” * Timeboxing * Parking Lot (https://project-management.fandom.com/wiki/Parking_lot) * Inside Pixar (https://www.imdb.com/title/tt13302848/#:~:text=This%20documentary%20series%20of%20personal,culture%20of%20Pixar%20Animation%20Studios.) * Democratization * Known Unknowns 15:32 - Facilitation and Knowledge Sharing * Iteration and Refinement * Knowledge Distillation / Knowledge Crunching * Clarifying Terminology: Semantics is Meaning * Embracing & Exposing Fuzziness (Complexities) 24:20 - Key Events * Narrative Shift * Domain-Driven Design (https://en.wikipedia.org/wiki/Domain-driven_design) * Shift in Metaphor 34:22 - Collaboration & Teamwork * Perspective * Mitigating Ambiguity 39:29 - Remote EventStorming and Facilitation * Miro (https://miro.com/) * MURAL (https://www.mural.co/) 47:38 - EventStorming vs Event Sourcing (https://martinfowler.com/eaaDev/EventSourcing.html) * Sacrificing Rigor For Collaboration 51:14 - Resources * The EventStorming Handbook (https://leanpub.com/eventstorming_handbook) * Paul's Upcoming Workshops (https://www.virtualgenius.com/events) * @thepaulrayner (https://twitter.com/thepaulrayner) Reflections: Mandy: Eventstorming and its adjacence to Technical Writing. Damien: You can do this on a small and iterative scale. Jess: Shared understanding. Paul: Being aware of the limitations of ideas you can hold in your head. With visualization, you can hold it in more easily and meaningfully. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: MANDY: Welcome to Episode 271 of Greater Than Code. My name is Mandy Moore and I'm here today with a guest, but returning panelist. I'm happy to see Jessica Kerr. JESSICA: Thanks, Mandy. It's great to see you. I'm also excited to be here today with Damien Burke! DAMIEN: And I am excited to be here with both of you and our guest today, Paul Rayner. Paul Rayner is one of the leading practitioners of EventStorming and domain-driven design. He's the author of The EventStorming Handbook, co-author of Behavior-Driven Development with Cucumber, and the founder and chair of the Explore DDD conference. Welcome to the show, Paul. PAUL: Thanks, Damien. Great to be here. DAMIEN: Great to have you. And so you know, you are prepared, you are ready for our first and most famous question here on Greater Than Code? PAUL: I don't know if I'm ready, or prepared, but I can answer it, I think. [laughter] DAMIEN: I know you have prepared, so I don't know if you are prepared. PAUL: Right. DAMIEN: Either way, here it comes. [chuckles] What is your superpower and how did you acquire it? PAUL: Okay. So a couple of weeks ago, there's a lake near my house, and the neighbors organized a polar plunge. They cut a big hole in the ice and everyone lines up and you basically take turns jumping into the water and then swimming to the other side and climbing out the ladder. So my superpower is participating in a polar plunge and I acquired that by participating with my neighbors. There was barbecue, there was a hot tub, and stuff like that there, too. So it was very, very cool. It's maybe not a superpower, though because there were little kids doing this also. So it's not like it was only me doing it. JESSICA: I'll argue that your superpower is participating in scary things because you're also on this podcast today! PAUL: [chuckles] Yeah, there we go. DAMIEN: Yeah, that is very scary. Nobody had to be fished out of the water? No hospital, hypothermia, any of that? PAUL: No, there was none of that. It was actually a really good time. I mean, being in Denver, blue skies, it was actually quite a nice day to jump into frozen. MANDY: So Paul, you're here today to talk about EventStorming. I want to know what your definition of that is, what it is, and why it's a cool topic to be talking about on Greater Than Code. PAUL: Okay. Well, there's a few things there. So firstly, what is EventStorming? I've been consulting, working with teams for a long time, coaching them and a big part of what I try and do is to try and bridge the gap between what the engineers, the developers, the technical people are trying to build in terms of the software, and what the actual problem is they're trying to solve. EventStorming is a technique for just mapping out a process using sticky notes where you're trying to describe the story of what it is that you're building, how that fits into the business process, and use the sticky notes to layer in variety of information and do it in a collaborative kind of way. So it's really about trying to bridge that communication gap and uncover assumptions that people might have, expose complexity and risk through the process, and with the goal of the software that you write actually being something that solves the real problem that you're trying to solve. I think it's a good topic for Greater Than Code based on what I understand about the podcast, because it certainly impacts the code that you write, touches on that, and connects with the design. But it's really optimized for collaboration, it's optimized for people with different perspectives being able to work together and approach it as visualizing processes that people create, and then working together to be able to do that. So there's a lot of techniques out there that are very much optimized from a developer perspective—UML diagrams, flow charts, and things like that. But EventStorming really, it sacrifices some of that rigor to try and draw people in and provide a structured conversation. I think with the podcast where you're trying to move beyond just the code and dig into the people aspects of this a lot more, I think it really touches on that in a meaningful way. JESSICA: You mentioned that with a bunch of stickies, a bunch of different people, and their perspectives, EventStorming layers in different kinds of information. PAUL: Mm hm. JESSICA: Like what? PAUL: Yeah. So the way that usually approach it is, let's say, we're modeling, visualizing some kind of process like somebody registering for a certain thing, or even somebody, maybe a more common example, purchasing something online and let's say, that we have the development team that's responsible for implementing how somebody might return a product to a merchant, something like that. The way it would work is you describe that process as events where each sticky note represents something that happened in the story of returning a product and then you can layer on questions. So if people have questions, use a different colored sticky note for highlighting things that people might be unsure of, what assumptions they might be making, differences in terminology, exposing those types of unknowns and then once you've sort of laid out that timeline, you can then layer in things like key events, what you might call emergent structures. So as you look at that timeline, what might be some events that are more important than others? JESSICA: Can you make that concrete for me? Give me an example of some events in the return process and then…? PAUL: Yeah. So let's say, the customer receives a product that they want to return. You could have an event like customer receive product and then an event that is customer reported need for return. And then you would have a shift in actor, like a shift in the person doing the work where maybe the merchant has to then merchant sent return package to customer. So we're mapping out each one of these as an event in the process and then the customer receives, or maybe it's a shipping label. The customer receives the shipping label and then they put the items in the package with the shipping label and they return it. And then there would be a bunch of events that the merchant would have to take care of. So the merchant would have to receive that package and then probably have to update the system to record that it's been returned. And then, I imagine there would be processing another order, or something like that. A key event in there might be something like sending out the shipping label and the customer receiving the shipping label because that's a point where the responsibility transfers from the merchant, who is preparing the shipping label and dispatching that, to the customer that's actually receiving it and then having to do something. That's just one, I guess, small example of you can use that to divide that story up into what you might think of as chapters where there's different responsibilities and changes in the narrative. Part of that maybe layering in sticky notes that represent who's doing the work. Like who's the actor, whether it's the merchant, or the customer, and then layering in other information, like the systems that are involved in that such as maybe there's email as a system, maybe there's the actual e-commerce platform, a payment gateway, these kinds of things could be reflected and so on, like there's – [overtalk] JESSICA: Probably integration with the shipper. PAUL: Integration with the shipper, right. So potentially, if you're designing this, you would have some kind of event to go out to the shipper to then know to actually pick up the package and that type of thing. And then once the package is actually delivered back to the merchant, then there would be some kind of event letting the merchant know. It's very hard to describe because I'm trying to picture this in my mind, which is an inherently visual thing. It's probably not that interesting to hear me describing something that's usually done on some kind of either mirror board, like some kind of electronic space, or on a piece of butcher's paper, or – [overtalk] DAMIEN: Something with a lot of sticky notes. PAUL: Something with a lot of sticky notes, right. DAMIEN: Which, I believe for our American listeners, sticky notes are the little square pieces of brightly colored paper with self-adhesive strip on the back. PAUL: Yeah. The stickies. DAMIEN: Stickies. [chuckles] I have a question about this process. I've been involved in very similar processes and it sounds incredibly useful. But as you describe it, one of the concerns I have is how do you avoid getting over specific, or over described? Like you can describe systems until you're talking about the particles in the sun, how do you know when to stop? PAUL: So I think there's a couple of things. Number one is at the start of whatever kind of this activity, this EventStorming is laying out what's the goal? What are we trying to accomplish in terms of the process? With returns, for example, it would be maybe from this event to this event, we're trying to map out what that process looks like and you start with what you might call the happy path. What does it look like when everything goes well? And then you can use pink stickies to represent alternate paths, or things going wrong and capture those. If they're not tied back to this goal, then you can say, “Okay, I think we've got enough level of detail here.” The other thing is time boxing is saying, “Okay, well, we've only got half an hour, or we've only got an hour so let's see how much we can do in that time period,” and then at the end of that, if you still have a lot of questions, then you can – or you feel like, “Oh, we need to dig into some of these areas more.” Then you could schedule a follow up session to dig into that a little bit more. So it's a combination of the people that are participating in this deciding how much level of detail they want to go down to. What I find is it typically is something that as you're going through the activity, you start to see. “Oh, maybe this is too far down in the weeds versus this is the right level.” As a facilitator, I don't typically prescribe that ahead of time, because it's much easier to add sticky notes and then talk about them than it is to have a conversation when there's nothing visualized. I like to visualize it first and lay it out and then it's very easy to say, “Oh, well, this looks like too much detail. So we'll just put a placeholder for that and not worry about out it right now.” It's a little bit of the facilitation technique of having a parking lot where you can say, “Okay, this is a good topic, but maybe we don't need to get down in that right now. Maybe let's refocus back on what it is that we're trying to accomplish.” JESSICA: So there's some regulation that happens naturally during the meeting, during interactions and you can have that regulation in the context of the visual representation, which is the EventStorming, the long row of stickies from one event to the other. PAUL: Right, the timeline that you're building up. So it's a little bit in my mind, I watched last year, I think it was on Netflix. There was a documentary about Pixar and how they do their storyboarding process for their movies and it is exactly that. They storyboard out the movie and iterate over that again and again and again telling that story. What's powerful about that is it's a visual medium so you have someone that is sketching out the main beats of the story and then they're talking it through. Not to say that EventStorming is at that level of rigor, but it has that kind of feel to it of we're laying out these events to tell the story and then we're talking through the story and seeing what we've missed and where we need to add more detail, maybe where we've added too much detail. And then like you said, Jess, there's a certain amount of self-regulation in there in terms of, do we have enough time to go down into this? Is this important right now? JESSICA: And I imagine that when I have questions that go further into detail than we were able to go in the meeting, if I've been in that EventStorming session, I know who to ask. PAUL: That's the idea, yeah. So the pink stickies that we said represent questions, what I like about those is, well, several things. Number one, it democratizes the idea that it's okay to ask questions, which I think is a really powerful technique. I think there's a tendency in meetings for some people to hold back and other people to do all the talking. We've all experienced that. What this tries to do is to democratize that and actually make it not only okay and not only accepted, but encourage that you're expected to ask questions and you're expected to put these sticky notes on here when there's things that you don't understand. JESSICA: Putting the questions on a sticky note, along with the events, the actors, and the things that we do know go on sticky notes, the questions also go on sticky notes. All of these are contributions. PAUL: Exactly. They value contributions and what I love about that is that even people that are new to this process, it's a way for them to ask questions in a way that is kind of friendly to them. I've seen this work really well, for example, with onboarding new team members and also, it encourages the idea that we have different areas of expertise. So in any given process, or any business story, whatever you want to characterize it as, some people are going to know more about some parts of it than others. What typically happens is nobody knows the whole story, but when we work together, we can actually build up an approximation of that whole story and help each other fill in the gaps. So you may have the person that's more on the business, or the product side explaining some terminology. You can capture those explanations on sticky notes as a glossary that you're building up as you go. You can have engineers asking questions about the sequence of events in terms of well, does this one come before that one? And then the other thing that's nice about the questions is it actually as you're going, it's mapping out your ignorance and I see that as a positive thing. JESSICA: The known unknowns. PAUL: Known unknowns. It takes unknown unknowns, which the kind of elephant in the room, and at least gets them up as known unknowns that you can then have a conversation around. Because there's often this situation of a question that somebody's afraid to ask and maybe they're new to the team, or maybe they're just not comfortable asking that type of question. But it gives you actually a map of that ignorance so you can kind of see oh, there's this whole area here that just has a bunch of pink stickies. So that's probably not an area we're ready to work on and we should prioritize. Actually, if this is an area that we need to be working on soon, we should prioritize getting answers to these questions by maybe we need to do a proof of concept, or some UX work, or maybe some kind of prototyping around this area, or like you said, Jess, maybe the person that knows the answers to these questions is just not in this session right now and so, we need to follow up with them, get whatever answers we need, and then come back and revisit things. JESSICA: So you identify areas of risk. PAUL: Yes. Areas of risk, both from a product perspective and also from a technical perspective as well. DAMIEN: So what does it take to have one of these events, or to facilitate one of these events? How do you know when you're ready and you can do it? PAUL: So I've done EventStorming [chuckles] as a conference activity in a hallway with sticky notes and we say, “Okay, let's as a little bit of an icebreaker here –” I usually you do the story of Cinderella. “Let's pick the Disney story of Cinderella and we'll just EventStorm this out. Just everyone, here are some orange sticky notes and a Sharpie, just write down some things that you remember happening in that story,” and then everyone writes a few. We post it up on the hallway wall and then we sequence them as a timeline and then we can basically build up that story in about 5, or 10 minutes from scratch. With a business process, it's not that different. It's like, okay, we're going to do returns, or something like that and if people are already familiar with the technique, then just give them a minute, or so to think of some things that they know that would happen in that process. And then they do that individually and then we just post them up on the timeline and then sequence them as a group and it can happen really quickly. And then everything from there is refinement. Iteration and refinement over what you've put up as that initial skeleton. DAMIEN: Do you ever find that a team comes back a week, or a day, or a month later and goes, “Oh, there is this big gap in our narrative because nobody in this room understood the warehouse needed to be reordered in order to send this thing down”? PAUL: Oh, for sure. Sometimes it's big gaps. Sometimes it's a huge cluster of pink sticky notes that represents an area where there's just a lot of risk and unknowns that the team maybe hasn't thought about all that much. Like you said, it could be there's this third-party thing that it wasn't until everyone got in a room and kind of started to map it out, that they realized that there was this gap in their knowledge. JESSICA: Yeah. Although, you could completely miss it if there's nobody from the warehouse in the room and nobody has any idea that you need to tell the warehouse to expect this return. PAUL: Right and so, part of that is putting a little bit of thought into who would need to be part of this and in a certain way, playing devil's advocate in terms of what don't we know, what haven't we thought of. So it encourages that sense of curiosity with this and it's a little bit different from – Some of the listeners maybe have experienced user story mapping and other techniques like that. Those tend to be focused on understanding a process, but they're very much geared towards okay, how do we then figure out how we're going to code up this feature and how do we slice it up into stories and prioritize that. So it's similar in terms of sticky notes, but the emphasis in EventStorming is more on understanding together, the problem that we're trying to address from a business perspective. JESSICA: Knowledge pulling. PAUL: Yeah. Knowledge pulling, knowledge distillation, those types of idea years, and that kind of mindset. So not just jumping straight to code, but trying to get a little bit of a shared understanding of what all is the thing that we're trying to actually work on here. JESSICA: Eric Evans calls it knowledge crunching. PAUL: Yes, Eric called it knowledge crunching. DAMIEN: I love that phrase, that shared understanding. That's what we, as product teams, are generating is a shared understanding both, captured in our documentation, in our code, and before that, I guess on large sheets of butcher paper. [laughs] PAUL: Well, and it could be a quick exercise of okay, we're going to be working on some new feature and let's just spend 15 minutes just mapping it out to get a sense of, are we on the same page with this? JESSICA: Right, because sometimes it's not even about we think we need to know something, it's do we know enough? Let's find out. PAUL: Right. JESSICA: And is that knowledge shared among us? PAUL: Right, and maybe exposing, like it could be as simple as slightly different terminology, or slightly different understanding of terminology between people that can have a big impact in terms of that. I was teaching a workshop last night where we were talking about this, where somebody had written the event. So there was a repair process that a third-party repair company would handle and then the event that closed that process off, they called case closed. So then the question becomes well, what does case closed mean? Because the word case – [overtalk] JESSICA: [laughs] It's like what's the definition of done? PAUL: Right, exactly. [laughter] Because that word case didn't show up anywhere earlier in the process. So is this like a new concept? Because the thing that kicks off the process is repair purchase order created and at the end of the process, it's said case closed. So then the question becomes well, is case closed really, is that a new concept that we actually need to implement here? Or is this another way of saying that we are getting a copy of that repair purchase order back that and it's been updated with details about what the repair involved? Or maybe it's something like repair purchase order closed. So it's kind of forcing us to clarify terminology, which may seem a little bit pedantic, but that's what's going to end up in the code. If you can get some of those things exposed a little earlier before you actually jump to code and get people on the same page and surface any sort of differences in terminology and misunderstandings, I think that can be super helpful for everyone. JESSICA: Yeah. Some people say it's just semantics. Semantics' meaning, its only meaning, this is only about out what this step actually means because when you put it in the code, the code is crystal clear. It is going to do exactly what it does and whether that clarity matches the shared understanding that we think we have oh, that's the difference between a bug and a working system. DAMIEN: [laughs] That's beautiful. It's only meaning. [laughs] JESSICA: Right? Yeah. But this is what makes programming hard is that pedanticness. The computer is the ultimate pedant. DAMIEN: Pedant. You're going to be pedantic about it. [laughter] PAUL: I see what you did there. [laughter] DAMIEN: And that is the occupation, right? That is what we do is look at and create systems and then make them precise. JESSICA: Yeah. DAMIEN: In a way that actually well, is precise. [laughs] JESSICA: Right, and the power of our human language is that it's not precise, that it allows for ambiguity, and therefore, a much broader range of meaning. But as developers, it's our job to be precise. We have to be precise to the computers. It helps tremendously to be precise with each other. DAMIEN: Yeah, and I think that's actually the power of human cognition is that it's not precise. We are very, very fuzzy machines and anyone who tries to pretend otherwise will be greatly disappointed. Ask me how I know. [laughter] PAUL: Well, and I think what I'm trying to do with something like EventStorming is to embrace the fuzziness, is to say that that's actually an asset and we want to embrace that and expose that fuzziness, that messiness. Because the processes we have and work with are often inherently complex. We are trying to provide some visual representation of that so we can actually get our head around, or our minds around the language complexities, the meanings, and drive in a little bit to that meaning. JESSICA: So when the sticky notes pile on top of each other, that's a feature. PAUL: It is. Going back to that example I was just talking about, let's say, there's a bunch of, like we do the initial part of this for a minute, or so where people are creating sticky notes and let's say, we end up with four, or five sticky notes written by different people on top of each other that end up on the timeline that all say pretty much the same thing with slight variations. JESSICA: Let's say, case closed, request closed. PAUL: Case closed, repair purchase order closed, repair purchase order updated, repair purchase order sent. So from a meaning perspective, I look at that and I say, “That's gold in terms of information,” because that's showing us that there's a richness here. Firstly, that's a very memorable thing that's happening in the timeline – [overtalk] JESSICA: Oh and it has multiple things. PAUL: That maybe means it's a key event. Right, and then what is the meaning? Are these the same things? Are they different things? Maybe we don't have enough time in that session to dig into that, but if we're going to implement something around that, or work with something around that, then we're going to at some point need some clarity around the language, the terminology, and what these concepts mean. Also, the sequence as well, because it might be that there's actually multiple events being expressed there that need to be teased apart. DAMIEN: You used this phrase a couple times, “key event,” and since you've used it a couple times, I think it might be key. [laughter] Can you tell us a little bit about what a key event is? What makes something a key event? PAUL: Yeah, the example I like to use is from the Cinderella story. So if you think about the story of Cinderella, one of the things, when people are doing that as an icebreaker, they always end up being multiple copies of the event that usually is something like shoe lost, or slipper lost, or glass slipper lost. There's something about that event that makes it memorable, firstly and then there's something about that event that makes it pivotal in the story. For those that are not familiar with the story [chuckles]—I am because I've EventStormed this thing maybe a hundred times—but there's this part. Another key event is the fairy godmother showing up and doing the magic at the start and she actually describes a business policy. She says, “The magic is going to run out at midnight,” and like all business policies, it's vague [laughter] and it's unclear as to what it means because – [overtalk] JESSICA: The carriage disappears, the dress disappears, but not the slipper that fell off. PAUL: Exactly. There's this exception that for some bizarre reason, to move the plot forward, the slipper stays. But then the definition of midnight is very hazy because what she's actually describing, in software terms, is a long running process of the clock banging 12 times, which is what midnight means is the time between the first and the twelfth and during that time, the magic is slowly unraveling. JESSICA: So midnight is a duration, not an instant. PAUL: Exactly. Yes, it's a process, not an event. So coming back to the question that Damien asked about key events. That slipper being lost is a key event in that story, I think because it actually is a shift in narrative. Up until that point in the story, it's the story of Cinderella and then after that, once the slipper is lost, it becomes the story of the prince looking for Cinderella. And then at the end, you get the day tomorrow, the stuff that happens with that slipper at the end of the story. Another key event would be like the fairy godmother showing up and doing the magic. DAMIEN: [chuckles] It seems like these are necessary events, right? If the slipper is not lost, if the fairy godmother doesn't do magic, you don't have the story of Cinderella. PAUL: Right. These are narrative turns, right? DAMIEN: Yeah. PAUL: These are points of the story shifts and so, key events can sometimes be a narrative shift where it's driving the story forward in a business process. Something like, let's say, you're working on an e-commerce system, like order submitted is a key event because you are adding items to a shopping cart and then at some point, you make a decision to submit the order and then at that point, it transitions from order being a draft thing that is in a state of flux to it actually becomes essentially immutable and gets passed over to fulfilment. So there's a shift in responsibility and actor between these two as well just like between Cinderella and the prince. JESSICA: A shift in who is driving the story forward. PAUL: Right. Yeah. So it's who is driving the story forward. So these key events often function as a shift in actor, a shift in who's driving the story forward, or who has responsibility. They also often indicate a handoff because of that from one group to another in an organization. Something like a sales process that terminates in contract signed. That key event is also the goal of the sales process. The goal is to get to contract signed and then once that happens, there's usually a transition to say, an onboarding group that actually onboards the new customer in the case of a sales process for a new customer, or in e-commerce, it would be the fulfillment part, the warehousing part that Jess was talking about earlier. That's actually responsible for the fulfillment piece, which is they take that order, they create a package, they put all the items in the package, create the shipping label, and ship it out to the customer. JESSICA: And in domain-driven design, you talked about the shift from order being a fluid thing that's changing as people add stuff to their cart to order being immutable. The word order has different meanings for the web site where you're buying stuff and the fulfillment system, there's a shift in that term. PAUL: Right, and that often happens around a key event, or a pivotal event is that there's a shift from one, you might think of it as context, or language over to another. So preorder submission, it's functioning as a draft order, but what it's actually typically called is a shopping cart and a shopping cart is not the same as an order. It's a great metaphor because there is no physical cart, but we all know what that means as a metaphor. A shopping cart is a completely different metaphor from an order, but we're able to understand that thread of continuity between I have this interactive process of taking items, or products, putting them in the shopping cart, or out again. And then at some point that shopping cart, which is functioning as a draft order, actually it becomes an order that has been submitted and then it gets – [overtalk] DAMIEN: Yeah, the metaphor doesn't really work until that transition. You have a shopping cart and then you click purchase and now what? [laughs] You're not going to the register and ringing it up, that doesn't make any sense. [chuckles] The metaphor kind of has to end there. JESSICA: You're not leaving the cart in the corral in the parking lot. [laughter] PAUL: Well, I think what they're trying to do is when you think about going through the purchase process at a store, you take your items up in the shopping cart and then at that point, you transition into a financial transaction that has to occur that then if you were at a big box electronic store, or something, eventually, you would make the payment. You would submit payment. That would be the key events and that payment is accepted and then you receive a receipt, which is kind of the in-person version of a record of your order that you've made because you have to bring the receipt back. DAMIEN: It sort of works if the thing you're putting in the shopping cart are those little cards. When they don't want to put things on the shelf, they have a card, you pick it up, and you take it to register. They ring it up, they give you a receipt, and hopefully, the thing shows up in the mail someday, or someone goes to the warehouse and goes gets it. PAUL: We've all done that. [chuckles] Sometimes it shows up. Sometimes it doesn't. JESSICA: That's an interesting point that at key events, there can be a shift in metaphor. PAUL: Yes. Often, there is. So for example, I mentioned earlier, a sales process ending in a contract and then once the contract is signed, the team – let's say, you're signing on a new customer, for a SaaS service, or something like that. Once they've signed the contract, the conversation isn't really about the contract anymore. It's about what do we need to do to onboard this customer. Up until that point, the emphasis is maybe on payment, legal disclosures, and things like that. But then the focus shifts after the contract is signed to more of an operational focus of how do we get the data in, how do we set up their accounts correctly, that type of thing. JESSICA: The contract is an input to that process. PAUL: Yes. JESSICA: Whereas, it was the output, the big goal of the sales process. PAUL: Yes, exactly. So these key events also function from a systems perspective, when you think about moving this to code that event then becomes almost like a message potentially. Could be implemented as say, a message that's being passed from the sales system through to the onboarding system, or something like that. So it functions as the integration point between those two, where the language has to be translated from one context to another. JESSICA: And it's an integration point we can define carefully so that makes it a strong boundary and a good place to divide the system. DAMIEN: Nice. PAUL: Right. So that's where it starts to connect to some of the things that people really care about these days in terms of system decomposition and things like that. Because you can start thinking about based on a process view of this, based on a behavior view of this, if we treat these key events as potential emergent boundaries in a process, like we've been describing, that we discover through mapping out the process, then that can give us some clues as to hmm maybe these boundaries don't exist in the system right now, but they could. These could be places where we start to tease things apart. JESSICA: Right. Where you start breaking out separate services and then when you get down to the user story level, the user stories expect a consistent language within themselves. You're not going to go from cart to return purchase in a case. PAUL: [laughs] Right. JESSICA: In a single user story. User stories are smaller scope and work within a single language. PAUL: Right and so, I think the connection there in my mind is user stories have to be written in some kind of language, within some language context and mapping out the process can help you understand where you are in that context and then also understand, like if you think about a process that maybe has a sales part of the process and then an onboarding part, it'll often be the case that there's different development teams that are focusing on different parts of that process. So it provides a way of them seeing what their integration point is and what might need to happen across that integration point. If they were to either integrate to different systems, or if they're trying to tease apart an existing system. To use Michael Feathers' term, what might be a “scene” that we could put in here that would allow us to start teasing these things apart. And doing it with the knowledge of the product people that are part of the visualization, too is that this isn't something typically that engineers do exclusively from a technical perspective. The idea with EventStorming is you are also bringing in other perspectives like product, business, stakeholders, and anyone that might have more of that business perspective in terms of what the goals of the process are and what the steps are in the process. MID-ROLL: And now a quick word from our sponsor. I hear people say the VPNs have a reputation for slowing down your internet speed, but not with NordVPN, because it's the fastest VPN in the world. I don't have to sacrifice internet speed for better security. With NordVPN, my internet traffic is routed through a secure encrypted tunnel, which protects my data and privacy. I can also have it on up to six devices like my laptop, phone, TV, iPad—all my devices are protected. Grab your exclusive NordVPN deal by going to nordvpn.com/gtc, or use the code GTC to get a huge discount on your NordVPN plan plus one additional month for free. Plus, a bonus gift! It's completely risk-free with Nord's 30-day money back guarantee. JESSICA: As a developer, it's so important to understand what those goals are, because that lets us make good decisions when we're down in the weeds and getting super precise. PAUL: Right, I think so. I think often, I see teams that are implementing stories, but not really understanding the why behind that in terms of maybe they get here's the functionality on delivering and how that fits into the system. But like I talked about before, when you're driving a process towards a key event, that becomes the goal of that subprocess. So the question then becomes how does the functionality that I'm going to implement that's described in this user story actually move people towards that goal and maybe there's a better way of implementing it to actually get them there. DAMIEN: Yeah, it's always important to keep that in mind, because there's always going to be ambiguity until you have a running system, or ran system, honestly. JESSICA: Yeah! DAMIEN: There's always going to be ambiguity, which it is our job as people writing code to manage and we need to know. Nobody's going to tell us exactly what's going to happen because that's our job. PAUL: Right. JESSICA: It's like if the developer had a user story that Cinderella's slipper fell off, but they do didn't realize that the goal of that was that the prince picked it up, then they might be like, “Oh, slipper broke. That's fine.” PAUL: Yeah. JESSICA: It's off the foot. Check the box. PAUL: Let's create a glass slipper factory implementer object [laughter] so that we can just create more of those. JESSICA: Oh, yeah. What, you wanted a method slip off in one piece? You didn't say that. I've created crush! PAUL: Right. [laughter] Yeah. So I think sometimes there's this potential to get lost in the weeds of the everyday development work that is happening and I like to tie it back to what is the actual story that we're supporting. And then sometimes what people think of as exception cases, like an example might be going back to that merchant return example is what if they issue the shipper label, but the buyer never receives it. We may say, “Well, that's never going to happen,” or “That's unlikely.” But visualizing that case, you may say, “That's actually a strong possibility. How do we handle that case and bake that into the design so that it actually reflects what we're trying to do?” JESSICA: And then you make an event that just triggers two weeks later that says, “Check whether customer received label.” PAUL: Yes, exactly. One thing you can do as well is like – so that's one possibility of solving it. The idea what EventStorming can let you do is say, “Well, that's one way of doing it. Are there any other options in terms of how we could handle this, let's visualize.” With any exception case, or something, you could say, “Well, let's try solving this a few different ways. Just quickly come up with some different ideas and then we can pull the best of those ideas into that.” So the idea when you're modeling is to say, “Okay, well, there's probably more than one way to address this. So maybe let's get a few ideas on the table and then pick the best out of these.” JESSICA: Or address it at multiple levels. PAUL: Yes. JESSICA: A fallback for the entire process is customer contact support again. PAUL: Right, and that may be the simple answer in that kind of case. What we're trying to do, though is to visualize that case as an option and then talk about it, have a structured conversation around it, say, “Well, how would we handle that?” Which I think from a product management perspective is a key thing to do is to engage the engineers in saying, “Well, what are some different ways that we could handle this and solve this?” If you have people that are doing responsibility primarily for testing in that, then having them weigh in on, well, how would we test this? What kind of test cases might we need to handle for this? So it's getting – [overtalk] JESSICA: How will we know it worked? PAUL: Different perspectives and opinions on the table earlier rather than later. JESSICA: And it's cheap. It's cheap, people. It's a couple hours and a lot of post-its. You can even buy the generic post-its. We went to Office Depot yesterday, it's $10 for 5 little Post-it pads, [laughter] or 25 Office Depot brand post-it pads. They don't have to stay on the wall very long; the cheap ones will work. PAUL: [laughs] So those all work and then it depends if you have shares in 3M, I guess, with you. [laughter] Or Office Depot, depending which road you want to go down. [laughter] JESSICA: Or if you really care about that shade of pale purple, which I do. PAUL: Right. I mean, what's been fascinating to me is in the last 2 years with switching to remote work and that is so much of, 95% of the EventStorming I do these days is on a collaborative whiteboard tool like Miro, or MURAL, which I don't know why those two product names are almost exactly the same. But then it's even cheaper because you can sign up for a free account, invite a few people, and then just start adding sticky notes to some virtual whiteboard and do it from home. There's a bunch of things that you can do on tool like that with copy pasting, moving groups of sticky notes around, rearranging things, and ordering things much – [overtalk] JESSICA: And you never run out of wall. PAUL: Yeah. The idea with the butcher's paper in a physical workshop, in-person workshop is you're trying to create a sense of unending modeling space that you can use. That you get for free when you use online collaborative whiteboarding tool. It's just there out of – [overtalk] JESSICA: And you can zoom in. PAUL: And you zoom in and out. Yeah. There's a – [overtalk] JESSICA: Stickies on your stickies on your stickies. [laughter] I'm not necessarily recommending that, but you can do it. PAUL: Right. The group I was working with last night, they'd actually gone to town using Miro emojis. They had something bad happen in the project and they've got the horror emoji [laughter] and then they've got all kinds of and then copy pasting images off the internet for things. JESSICA: Nice. PAUL: So yeah, can make it even more fun. JESSICA: Okay. So it's less physical, but in a lot of ways it can be more expressive, PAUL: I think so. More expressive and just as engaging and it can break down the geographical barriers. I've done sessions where we've had people simultaneously spread in multiple occasions across the US and Europe in the same session, all participating in real-time. If you're doing it remote, I like to keep it short. So maybe we do like a 2-hour session with a 10- or 15-minute break in the middle, because you're trying to manage people's energy and keep them focused and it's hard to do that when you just keep going. MANDY: I kind of want to talk a little bit about facilitation and how you facilitate these kind of workshops and what you do, engage people and keep them interested. PAUL: Yeah. So I think that it depends a little bit on the level of detail we're working at. If it's at the level of a few team members trying to figure out a feature, then it can be very informal. Not a lot of facilitation required. Let's just write down what the goal is and then go through the process of brainstorming a few stickies, laying it out, and then sequencing it as a timeline, adding questions. It doesn't require a lot of facilitation hand. I think the key thing is just making sure that people are writing down their questions and that it's time boxed. So quitting while people are still interested and then [laughter] at the end, before you finish, having a little bit of a conversation around what might the next steps be. Like what did we learn? You could do a couple of minutes retrospective, add a sticky note for something you learned in this session, and then what do you see as our next steps and then move on from there with whatever action items come out of that. So that one doesn't require, I think a lot of facilitation and people can get up and running with that pretty quickly. I also facilitate workshops that are a lot more involved where it's at the other end of the spectrum, where it's a big picture workshop where we're mapping out maybe an entire value stream for an organization. We may have a dozen, 20 people involved in a session like that representing different departments, different organizational silos and in that case, it requires a lot more planning, a lot more thinking through what the goal of the workshop is, who would you need to invite? Because there's a lot more detail involved and a lot more people involved, that could be four, or five multi-hour sessions spread over multiple days to be able to map out an entire value stream from soup to nuts. And then usually the goal of something like that is some kind of system modernization effort, or maybe spinning up a new project, or decomposing a legacy system, or even understanding what a legacy system does, or process improvement that will result inevitably in some software development in certain places. I did a workshop like that, I think last August and out of that, we identified a major bottleneck in the process that everyone in the workshop, I think it was just a bunch of pink stickies in one area that it got called the hot mess. [laughter] It was one area and what was happening was there were several major business concerns that were all coupled together in this system. They actually ended up spinning up a development team to focus on teasing apart the hot mess to figure out how do we decompose that down? JESSICA: Yes. PAUL: As far as I know, that effort was still ongoing as of December. I'm assuming that's still running because it was prioritized as we need to be able to decompose this part of this system to be able to grow and scale to where we want to get to. JESSICA: Yeah. That's a major business risk that they've got. They at least got clarity about where it is. PAUL: Right. Yeah, and what we did from there is I coached the developers through that process over several months. So we actually EventStormed it out at a much lower level. Once we figured out what the hot mess was, let's map it out and then they combined that with some flow charting and a bunch of other more engineering, kind of oriented visualization techniques, state machines, things like that to try and get a handle on what was going on. DAMIEN: We'll get UML in there eventually, right? PAUL: Eventually. [laughter] You can't do software development without some kind of state machine, sequence diagram. JESSICA: And it's approximating UML. You can't do it. You can't do it. [laughter] You will either use it, or you will derive a pigeon form of it. PAUL: Right. Well, I still use it for state diagrams and sequence diagrams when I'm down at that technical level. What I find is that there's a certain level of rigor that UML requires for a sequence diagram, or something like that that seems to get in the way of collaboration. So EventStorming sacrifices some of that rigor to be able to draw in everyone and have a low bar of entry to having people participate. DAMIEN: That's a huge insight. Why do you think that is? Is it the inability to hold that much information at a high level of rigor, or just people not used to working at that sort of precision and rigor? PAUL: I think that when I'm working with people that are not hands-on coders, they are in the everyday, like say, product managers, or stakeholders, to use those terms. They're in the everyday details of how the business process works and they tend to think of that process more as a series of steps that they're going through in a very specific kind of way. Like, I'm shipping a certain product, or supporting the shipping. or returning of certain types of products, those kinds of things. Whereas, as developers, we tend to think of it more in terms of the abstractions of the system and what we're trying to implement in the code. So the idea of being able to tell the story of a process in terms of the events that happen is a very natural thing, I find for people from a business perspective to do because that's how they tend to think about it. Whereas, I think as programmers, we're often taught not so much to think about behavior as a sequence of things happening, but more as the structure we've been taught to design in terms of structures and relationships rather than flow. JESSICA: Yet that's changing with event sourcing. PAUL: I think so. EventStorming and event sourcing become a very natural complement for each other and even event-driven architecture, or any event-driven messaging, whatever it happens to be. The gap between modeling using EventStorming and then designing some kind of event-driven distributed system, or even not distributed, but still event-driven is much more natural than trying to do something like an entity relationship diagram and they'd get from that to some kind of meaningful understanding of what's the story of how these functions and features are going to work. JESSICA: On the topic of sacrificing rigor for collaboration, I think you have to sacrifice rigor to work across content texts because you will find contradictions between them. The language does have different meaning before and after the order is submitted and you have to allow for that in the collaboration. It's not that you're not going to have the rigor. It's more that you're postponing it, you're scoping it as separately. This meeting is about the higher level and you need completeness over consistency. DAMIEN: Yeah. I feel like almost you have to sacrifice rigor to be effective in most roles and in that way, sacrifice is even the wrong word. Most of the things that we do as human beings do not allow for the sort of rigor of the things that we do as software engineers and things that computers do. JESSICA: Yeah. DAMIEN: And it's just, the world doesn't work that way. PAUL: Right. Well, and it's the focus in EventStorming on exploration, discovery, and urgent ideas versus rigor is more about not so much exploring and discovery, but about converging on certain things. So when someone says pedant and the other person says pedant, or vice versa, that tends to shut down the conversation because now you are trying to converge on some agreed upon term versus saying, “Well, let's explore a bunch of different ways this could be expressed and temporarily defer trying converge on.” JESSICA: Later in Slack, we'll vote. PAUL: Yes. JESSICA: Okay. So standardize later. PAUL: Yes. Standardize, converge later, and for now, let's kind of hold that at arm's length so that we can uncover and discover different perspectives on this in terms of how the story works and then add regulator when we go to code and then you may discover things in code where there are implicit concepts that you then need to take back to the modeling to try and figure out well, how do we express this? Coming up with some kind of term in the code and being able to go from there. JESSICA: Right. Some sort of potential return because it hasn't happened yet. PAUL: Exactly. So maybe it's a potential, maybe it's some other kind of potential return, like pending return, maybe we don't call it a return at all. JESSICA: Or disliked item because we could – or unsatisfactory item because we could intercept that and try to like, “Hey, how about we send you the screws that we're missing?” PAUL: Right. Yeah, maybe the answer is not a return at all. JESSICA: Yeah. PAUL: But maybe the case is that the customer says they want to return it, but you actually find a way to get them to buy more stuff by sending them something else that they would be happy with. So the idea is we're trying to promote discovery thinking when we are talking about how to understand certain problems and how to solve them rather than closing off options too soon. MANDY: So, Paul, I know you do give these workshops. Is there anything? Where can people find you? How can people learn more? How can people hire you to facilitate a workshop and get in touch with you? PAUL: Okay. Well, in terms of resources, Damien had mentioned at the beginning, I have an eBook up on Leanpub, The EventStorming Handbook, so if people are interested in learning more, they can get that. And then I do workshop facilitation and training through my company, Virtual Genius. They can go to virtualgenius.com and look at what training is available. It's all online these days, so they can participate from anywhere. We have some public workshops coming up in the coming months. And then they can find me, I'm @ThePaulRayner on Twitter, just to differentiate me from all the indefinite articles that are out there. [laughter] MANDY: Sounds good. Well, let's head into reflections. I can start. I just was thinking while we were talking about this episode, about how closely this ties into my background in professional writing, technical writing to be exact, and just how you have this process to lay out exactly what steps need to be taken and to differentiate when people say the same things and thinking about, “Well, they're saying the same things, but the words matter,” and to get pedantic, that can be a good thing, especially when you are writing technical documents and how-tos. I remember still, my first job being a technical writer and looking at people in a machine shop who it was like, first, you do this, then you do this, then you do this and to me, I was like, “This is so boring.” But it makes sense and it matters. So this has been a really good way for me to think about it as a newbie just likening it to technical writing. JESSICA: Yeah. Technical writing has to tell that story. DAMIEN: I'm going to be reflecting on this has been such a great conversation and I feel like I have a lot of familiarity with at least a very similar process. I brought up all my fears that come from them, which is like, what if we don't have the right person in the room? What if there's something we didn't discover? And you said something about how you can do this in 5 minutes and how you can do this in 15 minutes and I realized, “Oh, this process doesn't have to be the 6-hour things that I've participated in and facilitated in. It can also be done more smaller and more iteratively and I can bring this sort of same process and thought process into more of the daily work.” So that's super helpful for me. JESSICA: I want to reflect on a phrase that Paul said and then Damien emphasized, which is shared understanding. It's what we're trying to get to in EventStorming across teams and across functions. I think it's also like what we're constantly trying to get to as humans. We value shared understanding so much because we're trapped in our heads and my experience in my head is never going to be the same as your experience in your head. But at some point, we share the same physical world. So if we can get that visual representation, if we can be talking together about something in that visual world, we can pass ideas back and forth more meaningfully. We can achieve this shared understanding. We can build something together. And that feels so good. I think that that constant building of shared understanding is a lot of what it means to be human and I get really excited when I get to do that at work. PAUL: I think I would just add to that as well is being human, I'm very much aware of limitations in terms of how many ideas I can hold in my head at any one time. I know the times where I've been in the experience that many describe where someone's giving me a list of steps to follow and things like that, inevitably I'm like, “Well, I remember like the first two, maybe three,” and then everything after that is kind of Charlie Brown. What, what, why? [laughter] I don't remember anything they said from that point on. But when I can visualize something, then I can take it in one go. I can see it and we're building it together. So for me, it's a little bit of a mind hack in terms of getting over the limitations of how many things I can keep in my mind at one time. Also, like you said, Jess, getting those things out of my mind and out of other people's minds into a shared space where we can actually collaborate on them together, I think that's really important to be able to do that in a meaningful way. MANDY: Well, thank you so much for coming on the show today, Paul. We really enjoyed this discussion. And if you, as listeners, would like to continue this conversation, please head over to Patreon.com/greaterthancode. We have a Slack channel. You can pledge and donate to sponsor us as little as a dollar and you can come in, hang out, talk with us about these episodes. If not, give me a DM on Twitter and let me know, and I'll let you in anyway because [laughter] that's what we do here at Greater Than Code. PAUL: Because Mandy's awesome. MANDY: [laughs] Thank you, Paul. With that, thank you everyone for listening and we'll see you again next week. Special Guest: Paul Rayner.

Materiały dodatkowe:Składnia języka GherkinCucumberJBehaveSpecFlowBehatThoughtworks GaugeThoughtworks TaikoDodatkowo, sporo ciekawych odnośników do materiałów związanych z Behaviour-Driven Development znajduje się z repozytorium Mateusza, Awesome-BDD

Gherkin:  https://cucumber.io/docs/gherkin/reference/Easy Approach to Requirements Syntax:   https://qracorp.com/easy-approach-to-requirements-syntax-ears-guide/ You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer.  

This week, our heroes talk with Dan North: Viking, elk hunter, coach, consultant, author, and father of Behavior Driven Development. Dan discusses CUPID, a new set of software properties he's been working on. The post 27. CUPID: A Software Love Story with Dan North appeared first on Retro Time.

Wie arbeitet ihr mit als Product Owner richtig mit Akzeptanzkriterien? Wir starten in dieser Folge mit etwas theoretischem Input und einer Definition von Akzeptanzkriterien. Wir besprechen, wie man gute Akzeptanzkriterien findet und wie man sie sinnvoll einsetzen kann. Auch bei der Abgrenzung zur Definition of Done oder der Relevanz beim Schätzen sowie die Frage, ob es eine "richtige" Anzahl von Akzeptanzkriterien gibt diskutieren wir. Bleibt festzuhalten, dass es nicht um's Schreiben der Akzeptanzkriterien geht, sondern um ihre Formulierung und Nutzung. Das Wichtigste scheint zu sein, mit Akzeptanzkriterien Empathie für den Problemkontext herzustellen, damit ein gemeinsames "mentales Modell" über das zu lösende Problem im Team entsteht. Letztlich sind Akzeptanzkriterien für Product Owner eine super hilfreiche Praktik - auch bei der Arbeit mit Stakeholdern. Wir können allen Product Ownern nur empfehlen, sich damit eingehend zu beschäftigen! Dazu soll diese Episode beitragen. Folgende Quellen werden in der Folge genannt: - Gojko Adzic: Specification by Example - How Successful Teams Deliver the Right Software - CCC-Prinzip von Ron Jeffries (https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/) - Behavior Driven Development (https://de.wikipedia.org/wiki/Behavior_Driven_Development) - Beschreibungssprache Gherkin (https://github.com/cucumber/cucumber)

Yine kısa bir aradan sonra çoğumuzun bir kulak aşinalığı olduğu ama uzaktan bakıp "ah keşke" dediği Behavior Driven Development konusu üzerinde sevgili Haluk Baysal ile bol "yani peki şimdi"li bir sohbet ettik. Bakalım BDD mümkün ve sürdürülebilir bir şey miymiş? Üşenmeyip ta Kanadalar'dan katılan Haluk'a yeniden teşekkürler. Sürç-i lisan ettiysek affola...

Contact Mike at: agilecoach@rocketmail.com Define full SAFe framework https://www.scaledagileframework.com/#

Define full SAFe framework https://www.scaledagileframework.com/# Examples Mapping by Matt Wynne https://cucumber.io/blog/bdd/example-mapping-introduction/ INVEST User Stories: https://agileforall.com/new-to-agile-invest-in-good-user-stories/ How to use Three Amigos with BDD: https://automationpanda.com/2017/02/20/the-behavior-driven-three-amigos/

Testing your iOS apps can be tricky. It's even trickier when you need to make sure that your non-technical folks to verify that your applications behave as they should. Azam shares his expertise in testing your applications using Behavior Driven Development techniques and how to write specifications in plain English that can be read and understood by non-technical people and can be executed by computers to verify that the behavior matches up. Panelists Alex Bush Guest Mohammad Azam Sponsors CacheFly Picks Alex Bush: WWDC for macOS Mohammad Azam: Mark of the Beast Follow iPhreaks on Twitter: @iphreaks

Testing your iOS apps can be tricky. It's even trickier when you need to make sure that your non-technical folks to verify that your applications behave as they should. Azam shares his expertise in testing your applications using Behavior Driven Development techniques and how to write specifications in plain English that can be read and understood by non-technical people and can be executed by computers to verify that the behavior matches up. Panelists Alex Bush Guest Mohammad Azam Sponsors CacheFly Picks Alex Bush: WWDC for macOS Mohammad Azam: Mark of the Beast Follow iPhreaks on Twitter: @iphreaks

Want to know the current trends in open source automation, performance, and BDD testing? In this episode, Kevin Dunne, GM of TestProject, Matthias Rapp, GM of SpecFlow, and Ivan Vanderbyl, Head of Product at Flood, share the results from Tricentis’ first-ever State of Open Source Testing Survey. Discover the latest trends and developments across the industry gleaned from over 2,000 responses. Listen up to learn the latest in the Behavior Driven Development, Functional Testing, and Load Testing domains.  Check it out!

Christine Ketterlin Fisher, manager at NAIC, chats with TechWell community manager Owen Gotimer about her career journey from high school history teacher to business and quality team manager and why she believes Behavior Driven Development can help teams build better software. Continue the conversation with Christine (@Chris Fisher) and Owen (@owen) on the TechWell Hub (hub.techwell.com)! Transcript: Coming soon! Music from https://filmmusic.io "Funkorama" by Kevin MacLeod (https://incompetech.com) License: CC BY (http://creativecommons.org/licenses/by/4.0/)

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website.  When all works well with a team, there’s the temptation for us as Scrum Masters to think that the “team gets it”, but even if that is the case, your role, and who you are is part of that system. When you leave things will be different. In this episode, we explore what happens when the Scrum Master leaves, and the previous technical lead takes over. In this story, we will hear the anti-patterns that can easily develop when the critical role of the Scrum Master is taken by someone else. In this episode, we refer to Behavior Driven Development and “The New World Order” retrospective exercise, you can host a similar Agile Retrospective by using The Perfection Game exercise by Jim and Michele McCarthy, authors of the Core Protocols. Featured Book for the Week: Time to Think: Listening to Ignite the Human Mind by Nancy Kline In Time to Think: Listening to Ignite the Human Mind by Nancy Kline, Moana learned that it is critical to focus on improving our own performance so that we can help the teams we work with. In the book, she learned about the importance to focus on the quality of attention she gives to others when working with them.   About Moana Pledger Mo started her career in education and program management before moving into digital delivery. She's pretty sure she was a servant-leader before she had even heard the term. Her passion is to build healthy teams and foster the all-important relationship between business and team, which allows a safe space for the magic to happen. You can link with Moana Pledger on LinkedIn and connect with Moana Pledger on Twitter. 

This month, Matt Wynne and Seb Rose sat down with Richard Lawrence and Paul Rayner to talk about their new book "Behavior-Driven Development with Cucumber". The book incorporates their many combined years of experience teaching BDD to agile teams. Matt and Seb explore what readers can expect from the book as well as digging into their own experiences teaching and coaching teams in adopting BDD and agile practices. Shownotes Pick up a copy of Richard and Paul's "Behavior-Driven Development with Cucumber" on Amazon.com (https://www.amazon.com/Behavior-Driven-Development-Cucumber-Specification-Example/dp/0321772636) or wherever you buy books. Behind Closed Doors - Johanna Rothman and Esther Derby (https://pragprog.com/book/rdbcd/behind-closed-doors) The Goal - Eliyahu M. Goldratt(https://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0884271781) How to split a user story - Richard Lawrence (https://agileforall.com/resources/how-to-split-a-user-story/) High Fidelity - (https://en.wikipedia.org/wiki/High_Fidelity_(film)

In this episode, we learn the basics of Behavior Driven Development from Richard Lawerence. He shares what it means and how we can use it. This is a sample of some of the great content we have from the Agile Online Summit! If you want more become a VIP https://gum.co/aosvip Also, check out Richard Lawerence's book here: bddwithcucumber.com --- Support this podcast: https://anchor.fm/tom-henricksen/support

Chuck talks about Behavior-Driven Development (BDD), a technique to help Product and Development collaborate. He goes into the Cucumber test framework and its Gherkin specification syntax.Support the show (https://www.patreon.com/agilechuckwagon)

When it comes to Quality Assurance, the hot buzz words are "automation" and "moving left." It's true that automated testing beats manual, but throwing a bunch of automated tests on your UI just to increase your test coverage isn't productive.A holistic QA approach means everyone from product to engineering to business stakeholders is on board. In this episode we speak to QA leader David Morgan about building a quality-focused organization from scratch, changing process and culture, and implementing behavior-driven development that empowers stakeholders to speak and share a common language of software quality. See acast.com/privacy for privacy and opt-out information.

On this episode, Seb Rose, co-owner at Cucumber Limited and author of several books on Cucumber, gives us a look at how Behavior-Driven Development works alongside Test-Driven Development to tame legacy code. We walk through his personal version of Dante's rings of corporate hell and discuss why we should start thinking of the relationship between Acceptance, Integration, and Unit tests as an iceberg rather than a pyramid. 

Le Behavior Driven Development, ce n'est pas un outil, c'est une conversation entre 3 amigos: un Développeur, un Product Owner, un Testeur. Cédric Rup nous explique en détail comment le BDD va vous éviter le Scope Creep, vous permettre de mieux comprendre le métier, et être plus efficace au quotidien dans la réalisations de vos User Stories. Special Guest: Cédric Rup.

Pain Driven Development Pain Driven Development, or PDD, is the practice of writing software in such a way that you only "fix" problems when they are causing pain, rather than trying to preempt every possible issue. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript Many of you have probably heard of various "DD" approaches to writing software. There's TDD, or Test Driven Development. There's BDD, for Behavior Driven Development. In this tip, I want to introduce you to another one, PDD: Pain Driven Development. Pain Driven Development Software development is full of principles, patterns, and best practices. It can be tempting, especially when you've recently learned about a new way of doing things, to want to apply it widely to maximize its benefits. Some time ago, when XML was a new thing, for instance, Microsoft went all-in with it. They decided to "XML ALL THE THINGS" and in some places, this was great. And in many cases, not so much. In my own experience, I find this is often the case when I'm learning a new design pattern or trying to fully understand a particular principle. It can be easy, when you're constantly on the lookout for applications of recent knowledge, to find excuses to apply these techniques. One particular set of principles that many object-oriented programmers know are the SOLID principles. I have a course on SOLID on Pluralsight that I encourage you to check out, which covers these principles in depth. One thing that is worth remembering, though, is that you shouldn't, and honestly can't, apply all of the principles to every aspect of your software. You need to pick your battles. You need to actually ship working software. You don't know when you begin a project where extension is going to be necessary, so you can't anticipate every way in which you might support the Open-Closed Principle for every class or method in your program. Build and ship working software, and let feedback and new requirements guide you when it comes to applying iterative design improvements to your code. When you're back in the same method for the Nth time in the last month because yet another requirement has changed how it's supposed to work, that's when you should recognize the pain your current design is causing you. That's where Pain Driven Development comes into play. Refactor your code so that the pain you're experiencing as a result of its current design is abated. Extreme Programming introduced the concept of YAGNI, or You Ain't Gonna Need It. PDD is closely aligned with this concept. YAGNI cautions against building things you might need in the application, and instead favors building only what's required today (but in a responsible manner, so you can revise the design in the future). PDD offers similar guidance, but from a different perspective. The message with PDD is, follow YAGNI and build only what is required today, but recognize when you'll "need it" by the pain the current design causes you as you try to work around/with it. Well-designed code is enjoyable to work with. If you frequently find yourself frustrated with the code you're working with, see if you can identity the source(s) of the pain, and apply refactoring techniques to alleviate the problem. Show Resources and Links Pain Driven Development (PDD) SOLID Principles of OOD Refactoring Fundamentals

Luis Majano talks about “Extreme testing and slaying the dragons of ORM” in this episode of the ColdFusion Alive Podcast, with host Michaela Light. Luis is one of the speakers for the upcoming Into The Box ColdFusion Conference, where he will talk about the theory of Behavior Driven Development, Slaying the ORM Dragons with CBORM and The […] The post 012 Extreme Testing and Slaying the Dragons of ORM with Luis Majano appeared first on TeraTech.

We chat about the open-source Behavior-Driven Development framework called Behat. We get a brief overview of how Behat can help us write more reliable code and also explore some best-practices when writing automated tests.

In this episode, Adam talks to Matt Wynne about Behavior Driven Development with Cucumber. Topics include: What exactly is BDD? Is BDD a technical or non-technical practice? How do you get started with BDD? How do you keep the number of system tests low to keep your test suite fast? What's your strategy for dealing with external services in acceptance tests? What are the advantages of using Cucumber even as a solo developer working on a side project? Sponsors: Rollbar, sign up at https://rollbar.com/fullstackradio to try their Bootstrap Plan free for 90 days Hired, sign up at https://www.hired.com/fullstackradio to double your signing bonus to $2000 if you get a job through Hired Links: Test Driven Laravel, Adam's upcoming video course Matt's Blog Matt's notes from Dan North's Awesome Acceptance Testing talk Cucumber School User Story Mapping Impact Mapping Introducing Example Mapping The Rails Testing Pyramid The Testing Iceberg The Deep Synergy Between Testability and Good Design talk by Michael Feathers The Training Wheels Came Off, Aslak Hellesøy on removing the built-in step definitions in Cucumber-Rails Cucumber Blog Cucumber on GitHub The Cucumber Book

In this episode we're joined by Alexandra Marin to talk about Behavior Driven Development for Xamarin Developers Special Guest: Alexandra Marin.

"Tools should be secondary to what you're trying to achieve with BDD and the value that it brings," says Kate Falanga, Director of QA at Huge, of some people's fascination with BDD tools. Kate's session at Agile Alliance Technical Conference 2016 was a workshop called "Behavior-Driven Development for Non-Coders" and aimed to promote "shift left" testing: starting testing earlier in the development cycle (toward the left, if you're looking at the dev workflow). Part of Kate's workshop centered around acting out a story kickoff session with "a really terrible user story that I wrote." The goal was to focus on communication and for participants to feel how it changed the user story. The story kickoff session or huddle serves to clearly identify the requirements in a user story before any development takes place and as a result the best huddle with have the developer, the tester and the Product Owner. This ensures that any low-hanging fruit (both problems and opportunities) are addressed at the development stage, rather than later when changes are much more expensive. If you're gonna invite someone else into the huddle (or "Three Amigos" as some cheekily call it), Kate says consider a visual UX or design expert. Kate Falanga (Director, Quality Assurance at Huge) has over 14 years of digital experience. At Huge she works with a full time team of quality assurance professionals as well as actively supports projects and project teams with testing mentorship. As part of her role she works alongside other leadership within the company on overall technical strategy. SolutionsIQ's Leslie Morse hosts. About Agile Amped The Agile Amped podcast series engages with industry thought leaders at Agile events across the country to bring valuable content to subscribers anytime, anywhere. To receive real-time updates, subscribe at YouTube, iTunes or SolutionsIQ.com. Subscribe: http://bit.ly/SIQYouTube, http://bit.ly/SIQiTunes, http://www.solutionsiq.com/agile-amped/ Follow: http://bit.ly/SIQTwitter Like: http://bit.ly/SIQFacebook

Dave Rael is a dedicated father and husband and a seasoned software professional. He specializes in building distributed systems and understanding problem domains, especially via Domain-Driven Design and Behavior-Driven Development. Outside work, he’s usually playing with kids, playing basketball, lifting weights, coaching youth sports, and enjoying dirty jokes. He blogs at optimizedprogrammer.com about writing software and getting […] The post Show 6: Interview with Dave Rael appeared first on Lock Me Down.

In this episode, we’re joined by Jeffrey Davidson.  Jeffrey will help us to better understand how to get better at user stories and how behavior driven development (BDD) helps create a shared understanding.  We also discuss how to create the nirvana state of living requirements.   Jeffrey Davidson is the past president of the IIBA Dallas […] The post MBA023: Using Behavior Driven Development for Better User Stories – Interview with Jeffrey Davidson appeared first on Mastering Business Analysis.

Adam and Clay talk about Behavior Driven Development in Swift as well as React Native

In this episode, Adam talks with Shawn McCool about Behavior Driven Development and Domain Driven Design. They talk about how you can use these ideas to better understand your clients' needs and to build software that closely models their business. They also talk about where these ideas don't work so well, and some of the challenges and trade-offs you face when trying to build software this way. Shawn's blog The RSpec Book everzet's Introduction to BDD everzet on Modelling by Example Domain Driven Design Quickly "Domain Driven Design" by Eric Evans "Implementing Domain Driven Design" by Vaughn Vernon Ross Tuck's blog

Další díl jsme zasvětili povídání o Behavior-driven development a světem zkratek BDD, TDD nás provedl Daniel Kolman. Probrali jsme co je to BDD, vztah k TDD. Proč to vzniklo a jaké problémy to má adresovat. K čemu se to hodí/nehodí, jestli to může fungovat v staticky typovaných jazycích, jak testovat legacy kód, knihovny, tooling a hlavně rozdíl mezi Chicagskou a Londýnskou školou. Vaše ohlasy sdílejte na naší fan stránce..

In this episode, Bob and Josh wrap-up their initial pass at what fits into the Agile Starter Kit.  They end with talking through some of the technical aspects of implementing Agile in your workplace, digging into topics like continuous integration, pair programming, designs/specifications, and finally wrap up with metrics. While Bob and Josh try to remain tool/technology agnostic, there are a few key points that they hit that could use a few wikipedia links to help out.  So if you heard these terms in the podcast, but were not exactly sure what they meant, here are your podcast footnotes for episode 38.  If you need more info, please ask in the comments and we'll get you an answer. Behavior Driven Development (http://en.wikipedia.org/wiki/Behavior-driven_development) Minimum Viable Product (http://en.wikipedia.org/wiki/Minimum_viable_product) Continuous Integration  (http://en.wikipedia.org/wiki/Continuous_integration) Cucumber (http://en.wikipedia.org/wiki/Cucumber_(software)) Once again, thanks for listening.  Please review/rate the show on iTunes (https://itunes.apple.com/podcast/meta-cast-podcast-for-software/id356489089) , share this post with your social networks, and post comments and questions on our website. Support this podcast

Live from the SxSW show floor, Clark talks with 2 native hipsters, Brandon Satrom and Sara Summers about Behavior Driven Development or BDD for short.

Steve Ross gives an introduction to behavior driven development using Ruby, Cucumber, and rSpec. This is a practical how-to for developers who have not yet integrated behavior driven development into their workflow.

Testing Acceptance and Behaviour Driven Development (mp3), recorded at CITCON ANZ 2010 at Fronde in Wellington, New Zealand.Theme music is Fireworks by Knoxville, used under license of Creative Commons.

Devchat.tv Master Feed f htt

This episode was originally published on October 9, 2006. A member of the rSpec team talks about Behavior Driven Development. From the offices of Bekk in Oslo, Norway.

This episode was originally published on October 9, 2006. A member of the rSpec team talks about Behavior Driven Development. From the offices of Bekk in Oslo, Norway.

David Celimsky is one of the development powerhouses behind RSpec, one of the first frameworks for Ruby to implement the Behavior Driven Development process. BDD is an interesting process and I like the increased move toward using language that the "user" can understand when describing or systems in executable form. I can now put another face (not Dave Astels as I usually do) to RSpec David. David is great to talk to and I recommend accosting him at conferences to start up a conversation. Enjoy Bob Payne

Dave and I talk about his new book and his new Behavior Driven Development project in Ruby. Look for BDD in a project near you.