The Agile Word Association Game By David Bulkin

We are about to play word association game.  This is a game, not a test, so the purpose is to provoke thought, not define the exact meaning of each term.

Given the list of the words on the left, find the most appropriate match on the right. Remember that this is a game, so, even though both “ATDD” and “TDD” are listed on the left, you won’t find “Testing” anywhere on the right. If it were that easy, it wouldn’t be fun or informative!

Oh, you thought ATDD / Acceptance Test Driven Development was about testing.

In fact, ATDD is at least as much about specification as it is about testing. With ATDD, Product Owners, Business Analysts, Testers, Developers and other stakeholders use a common language to concretely define examples that specify the expected behavior of a system.

The concrete examples are created before the code, and when specified in a format compatible with one or more testing frameworks, like Fit or Cucumber, they can serve as executable specifications (once the supporting fixtures are coded).

With ATDD, external dependencies are often mocked or stubbed, making it possible to verify that functionality meets the specifications, but not necessarily proving that the system works in an end to end fashion. As such, despite its’ name, ATDD does not replace integration testing, but it sure does make it a whole lot easier to specify expected behavior in a way that can truly be understood by all, hence, ATDD = Specify.

At its’ simplest, your Product Backlog is a prioritized To-Do List with estimates. Your Iteration Backlog is your short term to do list. Doesn’t sound very technical, but that’s what they are.

Traditional project teams focus their status meetings on providing information to the manager, who then makes all of the decisions.  Agile teams answers three questions so that team members can commit to each other and self manage.  The questions are:

1. What did I do since the last stand-up?
2. What will I do before the next standup?
3. What blockers do I have?

You should answer these questions succinctly,  deferring details until the post meetings (which I call the “Daily Sit-Downs”) so that just the information necessary for the team to coordinate, and hence, self manage, is covered.

We all know that the key responsibility of the Product Owner is maximizing the business value of the system that is developed.  But, how much fun would it be if “business value” was on the list?

More importantly, when I think about how the Product Owner maximizes values, I think of at least two key things, conveying the information that the team needs, and making trade-offs decisions.  I emphasize the trade-off decisions in this post, as in my experience, this aspect of the Product Owner role is sometimes not given enough emphasis, so, at least for this post, Product Owner = Trade-offs.

There are many attributes of the ScrumMaster role.  At the core, the ScrumMaster ensures that the process is being followed.  So, I guess I could have said, ScrumMaster = Ensure Process is Followed, but, remember this is a game, not a test, so I want you to think.

 

A textbook definition of sprint (outside the world of agile), as given by Wikipedia is a type of short race in athletics.

When I co-train with Sanjiv Augustine he likes to point out that racing is not an appropriate metaphor for executing with a sustainable pace.  I agree, and I prefer Iteration to Sprint.

TDD, or Test Driven Development, is an approach where a developer, or pair, write a test prior to writing just enough code to pass the test. The tests are automated, and they are constantly run, to ensure that code changes work and that they don’t have unintended consequences.

OK, you may ask, then why do I equate TDD with design?  As with ATDD, TDD much more than testing.

Most hard core devotees of TDD will tell you that the act of writing the test prior to writing the code is an easy and cost effective way to create simple, clean, loosely coupled, highly cohesive, i.e., well designed, code.