Migrating the blog: Scott Bain

Thank you for joining us on this journey!

You may know that Net Objectives has joined with Disciplined Agile and is now part of the Project Management Institute. Here is the press release: https://www.pmi.org/about/press-media/press-releases/project-management-institute-announces-acquisition-of-flex-from-net-objectives

As part of this migration, Scott is now blogging on ProjectManagement.com. Here are the addresses of his blog:

We invite you to join in following him on that site.

On 30 September, the Net Objectives Thoughts blog will be officially closed.

If you have any questions, please contact Scott at scott.bain@pmi.org

The Relationship Between Acceptance Test-Driven Development and Design Patterns

This is an excerpt from Introducing FLEX – FLow for Enterprise Transformation: Going Beyond Lean and Agile (online book). If you are looking for an alternative to SAFe, this is it. To those who’d like to study along with me as I publish this on linkedin, please ask to join the True North Consortium Linkedin Group where I will be happy to answer any questions or, even more importantly, discuss things you disagree with in the book.

If you want to learn more about FLEX you can watch a webinar on FLEX, take an online course at the Net Objectives University or take a live course in Orange County, CA May 6-8, 2019, or in Seattle in June (both led by Al Shalloway). If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway

Abstract

This chapter discusses 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.

Continue reading “The Relationship Between Acceptance Test-Driven Development and Design Patterns”

The Relationship Between Acceptance Test-Driven Development and Design Patterns

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.

In the Agile world where requirements evolve, ATDD and Design Patterns Thinking work together to enable emerging designs from emerging requirements.

The Third Leg of Emergent Design: Acceptance Test-Driven Development (ATDD)

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)”

INVEST is a goal, not a guide

I–Independent
N–Negotiable
V–Valuable
E–Estimable
S–Small
T–Testable

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.

Examining Test-First

“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

Why Learning How to Decompose Stories with Acceptance Test-Driven Development (ATDD) Is not Just Decomposition

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.

XP is not Scrum with tech practices & knowing why this is so is more important than ever before

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”

When given a requirement ask the question, “How will I know I’ve done that?”

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?””

Why you should grow your own Scrum Masters instead of bringing in outside coaches

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”