Ovidiu Mățan: People know you as the father of BDD. How did all of this start out?
Dan North: I was working as a developer at ThoughtWorks, a global software consultancy, back in 2003. We were advocating an XP-like delivery model, using practices like iterations, user stories, pair-programming, continuous integration, test-driven development, etc. The big sticking point seemed to be TDD - the developers thought that writing tests was the work of lowly testers. The testers didn't like the idea of programmers writing tests either - maybe because they didn't think the programmers knew how to write tests, maybe because they were afraid they would be out of a job!
Dan North - părintele BDD
From my own experience I knew TDD was a design practice more than a testing one. I wrote an article in 2003 (my first published tech article!) for the Java Developers' Journal called TestDriven Development is not about Testing, now lost to the mists of time. I tried introducing TDD to the developers without using the word "test". Instead I talked about examples, behavior, and writing model clients. The developers were much more receptive to TDD when I stopped talking about testing. That's how BDD started.
Your early years as a software consultant were at ThoughtWorks. What did you learn there regarding the way of working?
Dan North: I was over ten years into my career when I joined ThoughtWorks so it wasn't really early years! They were doing things very differently from anywhere else I had worked, and very much in line with my values. I had the amazing privilege of working with some of the very best people in software development at the time. It felt like they were way ahead of the game: pioneering agile methods in large organizations; advocating and contributing to open source projects long before GitHub or even git existed; actively supporting and promoting diversity; growing rapidly in size while keeping hierarchy to a minimum.
I learned - and developed - a lot of agile techniques while I was at ThoughtWorks, but the main areas of growth for me were in coaching teams, understanding how organisations work, and in release engineering and the methods that were going to become Continuous Delivery. ThoughtWorks was fantastic at encouraging its people to write and speak at conferences. As ThoughtWorks' Chief Scientist, Martin Fowler in particular, , took a personal interest in coaching people like me with no experience of speaking at conferences, and sharing his platform with us.
Transforming TDD (Test Driven Development) into (BDD) Behaviour Driven Development was a smart move with a lot of consequences that made it better than TDD. Can you describe what was added?
Dan North: It definitely made it different from TDD, but not necessarily better. It opened this style of example-guided design to a new audience, and made it easier for me personally to explain and teach this style of working. I wrote an article called BDD is like TDD if... which describes what I think are the essential differences. The comments are interesting - there are a number of well-known agile folk joining in the conversation.
How do BDD and Agile Scrum work together? How do these paradigms position themselves?
Dan North: Scrum is essentially a work management method for software delivery. It doesn't much care how the work gets done so long as the team delivers at the end of the sprint. Scrum's ceremonies are designed to track work, remove obstacles, showcase progress, so BDD can be a great fit for actually getting the work done.
The team can use backlog grooming as an opportunity to articulate acceptance criteria and scenarios for each feature. Within a sprint the team can use these scenarios, and lower-level examples, to guide the design of the application and to ensure it meets the acceptance criteria.
Current pandemic times made everyone move online. What is your personal technical opinion regarding new opportunities but also limitations?
Dan North: One phrase that resonates with me is "suddenly distributed". Most people didn't choose to start working at home, they had it forced upon them. They didn't have time to prepare for it; many don't have suitable equipment, connectivity, or a distraction-free working environment; they are juggling home and work concerns at the same time. It is a lot to ask!
Once it is safe for people to return to work, I think we will see a mix of home and office working rather than either/or. Some people like to be around others, some prefer their own company, for some it depends on what they are doing. Our industry is famously neurodiverse, so it doesn't make sense to talk about how "typical people" work. We all need to take care of our emotional and mental wellbeing - and each others' - and think about how best to collaborate whilst respecting boundaries of privacy and non-work time.
I'm impressed with how well some of the distributed collaboration product companies have stepped up. Video conferencing apps like Zoom and MS Teams, distributed whiteboards like Miro and Mural, have all seen huge surges in popularity. Zoom famously was a security nightmare earlier in the year, MS Teams didn't work for large groups, etc. Of course they still all have some way to go, but you can see the level of investment and the impact it is having. Remote working will never replace in-person collaboration, but it is a great complement in a lot of cases, and the up-sides of not having to commute, being available for your family, etc. are significant.
What's next after BDD?
Dan North: BDD is a way for an individual team to deliver software successfully. For the last few years I've been looking at how groups of teams deliver a programme of work, or how to structure a whole organization around effectively and sustainably delivering value to customers. BDD is still an important method for collaboration at the team level, so the next question is how to keep that agility and collaboration as you scale to hundreds or even thousands of people across a whole organization. My recent work has been looking at guiding digital product companies towards "autonomy with alignment", through a combination of organization design, leadership, modern product management, lean delivery methods, and agile engineering practices. It is an exciting adventure!
by Daniel Butean , Alex Ghiran , Călin Manea
