I’ve written a chapter in my book on The Relationship Between ATDD and Design Patterns. Essentially, ATDD provides us with quality acceptance criteria in the form of test specifications. We can use these to design our code from a behavior point of view instead of from an implementation point of view.
Doing this makes for more testable code, a quality highly correlated with other code qualities we want – strong cohesion, loose coupling and no redundancy. Design patters provide us with a method for combining these high quality objects together through the Gang of Four’s mantra’s of designing to behavior, using variation and encapsulating variation – in this case variation of type.
In the Agile world where requirements evolve, ATDD and Design Patterns Thinking work together to enable emerging designs from emerging requirements.
In previous posts, I discussed that the first leg of emergent design is TDD, which provides code quality and sustainability. The second leg is design patterns, which provides insights into handling variation. The third leg is ATDD, which provides us a way of discovering and clarifying the value we will get. Continue reading “The Third Leg of Emergent Design: Acceptance Test-Driven Development (ATDD)”
This is almost universally used to teach how to write stories. But notice, it’s a goal, not a method. Goals are good, but in themselves, don’t provide much guidance to get to them (think “buy low sell high”).
A better way to learn to write stories is to take advantage of the discovery & specification phases of Acceptance Test-Driven Development (ATDD). While usually relegated to the 2nd or 3rd round of training we’ve seen light-weight ATDD integrated with initial Scrum training enables teams to write stories right out of the box and eliminates 3 of the major challenges most teams have adopting Scrum:
1) writing small stories
2) having clear requirements
3) understanding why testing cannot lag coding
This is the key to learning Agile- not just learning the end state desired, but using methods that actually help get you there. It is easier to act your way into a new way of thinking than think your way into a new way of acting.
ATDD has the dev team focus on identifying and validating (Testable) Small chunks of Value by “Negotiating” with the PO. Part of ATDD is to decouple (make Independent) the stories. Since these stories are now understood, they are also Estimable.
“Test-first “sounds like it’s about testing, but it’s really about collaboration, shared understanding and better design. Test-first originated with eXtreme Programming (XP) with the focus was on writing tests before code. Fortunately, a natural law of software development is that programs written by first considering their behavior are more flexible and robust than programs written by considering their implementation.
Since then, test-first has expanded to be used between product owners and the team by specifying the requirements in the form of acceptance tests. This is called Acceptance TDD (ATDD)
ATDD requires the collaboration of all parties involved. This collaboration on understanding behavior prior to implementation clarifies what is being required while removing the delay between specification of requirements, their implementation and then their final validation. This both helps ensure the right functionality is built while increasing efficiency.
The benefits of ATDD are
- improved collaboration
- clear acceptance criteria
- prepared for automated testing
- improved developer-tester communication
- reduced time for feedback
- agreement on requirements
- improved code quality
It’s one of the best steps towards building the right thing in the right way.
For more information see:
Benefits of Acceptance Test-Driven Development using Behavior-Driven Development
How to Start with ATDD using BDD
I’ve been having a very interesting twittervation about how to start teams off with Scrum. I believe you best learn by doing. And that it’s more important to get teams actually starting Agile in the workshop than merely learning Scrum which will hopefully lead you to Agile.
So we “teach” Scrum with a 1-day emulation and discussion of it followed by 3 days of ATDD. This first day teaches the essence of Scrum but it illustrates how teams work – mostly their foibles. 🙂
The other three days are on ATDD. Each day isi split by 1/2 day discussing it & then an hour with each team doing it. What we’re really teaching is – collaboration, test-first, feature slicing, and how to use minimum business increments. These directly address the issues we’ve seen most teams have- unclear requirements, stories too large, POs not appreciating the impact of interruptions and a lack of focus on finishing.
The test-first is mostly about discovery & specification but it also informs design (the 1st mantra of design patterns is designing from behavior).
The result is that once a team gets moving they can keep moving. But a course that prepares you for movement may not ever get you started.
I’ve always been bothered by the dismissal of XP as just being “Scrum with tech practices.” But the differences between the two are much greater. First, while XP and Scrum both have related values, the practices of XP are mostly centered around sw development practices (such as paired programming), while Scrum is mostly about non-domain specific team practices. Second, XP includes Acceptance Test-Driven Development (ATDD). ATDD, which is a collaboration between the Product Owner, dev, and tester and which includes neither design nor coding and is therefore, not a technical practice. In other words, Continue reading “XP is not Scrum with tech practices & knowing why this is so is more important than ever before”
Many people think of Acceptance Test-Driven Development (ATDD) as an advanced practice. Others think that using Given When Then (GWT) from Behavior Driven Development (BDD) requires the use of tools. Neither of these are true however. The easiest way to start using ATDD and/or BDD is simply to ask the question “How will I know I’ve done that?” whenever you are given a requirement – even if the requirement appears to be obvious. The reason for this is that it is often the ‘obvious’ requirements that are most misunderstood. Continue reading “When given a requirement ask the question, “How will I know I’ve done that?””
If you are kicking off new teams there are two types of coaches you can bring in. While it’s useful to bring in someone who can actually help with the work, such as a technical or ATDD coach, when it comes to Scrum or Agile coaches it’s usually better to grow your own. There are several reasons for this:
Continue reading “Why you should grow your own Scrum Masters instead of bringing in outside coaches”
Which initial training you chose should therefore be that teams can do this after their initial training. The promoted belief that you should focus on the framework & then learn how to do this later is not just self-serving, it is wrong. While you can take a course and then pay for coaching after the workshop to learn this is not just expensive but wastes the time of your staff and often produces resistance. Continue reading “The #1 challenge for teams after Scrum training is writing small, well-scoped, testable stories”
First, let’s be clear what we mean by Acceptance Test-Driven Development. It does not mean automating testing. It means to collaboratively (Product Owners, devs and testers) working together to go from features to small stories (less than three days) that are well-scoped and have clear acceptance criteria that could be automated if desired.
Most companies delay ATDD because CSM and team level courses for SAFe don’t include it. The trade off is more framework and less actual Agile work. Continue reading “Why it’s so important to learn ATDD upfront”