Using a good tool for the wrong thing

When I first met Andreas Schliep, he told me a consulting war story with the punch line, “Well, you can paint that wall with a screwdriver if you like…” There’s no stopping people who are intent to use the wrong tool for a job, or use it in the wrong way. Sometimes it even works. I’ve seen someone successfully, after a fashion, driving wood screws with a hammer.

Now, Karlo Smid complains that Gherkin (given-when-then) is unsuitable for writing Shakespeare’s Hamlet. There’s not much surprise to me in that complaint. I would never attempt to write a five act play in Gherkin. Nor would I try to describe the desired behavior of a system in Elizabethan iambic pentameter.

Gherkin is useful for documenting expected behavior in language close enough to “plain English” (or other language) that non-technical people can agree or disagree that it represents what they want. It’s also precise enough that we can use it to check that the software does what is wanted, at least as far as specified.

Note that people study Shakespeare’s plays in great detail for years to glean the meaning of them. Newcomers to the study of Shakespeare, e.g., high-school students required to read Hamlet, for example, turn to explanatory works, such as CliffsNotes to help them understand the very basics, such as the timeline of what happens. This level of difficulty and ambiguity is not what we want in a document that describes the desired behavior of a software system.

Neither Gherkin nor Elizabethan English is likely a good choice for general discussion about what is desired in a system to be build. When the Three Amigos meet, they should talk in the language they normally use, preferably based on the language the business uses. Because the technical and non-technical people have different, if overlapping languages, there will be some need to check the translation. One way to do this is to offer examples of what is understood. These examples provide a concrete description to accompany the abstract “requirements” and help ensure we have shared understanding. Otherwise it’s far too easy to agree on the words, but not the meaning. The examples test the “shared-ness” of our understanding.

The examples also provide a good basis for later checking that the resulting software behaves according to that shared understanding. That’s why we then translate them into Gherkin, and verify with the business that the Gherkin still says what they mean.

Sadly, in Karlo’s list of “the best sources of communication,” talking with the business people who know what they want the system to do is not mentioned. I wonder how he knows whether or not it meets their desires.

Definition of Ready

Many time, in the middle of developing a user story, the programmer discovers a question about how it’s intended to work. Or the tester, when looking at the functionality that’s been developed, questions if it’s really supposed to work that way. I once worked with a team that too-often found that, when the programmer picked up the card, there were questions that hadn’t been thought out. The team created a new column on the sprint board, “Needs Analysis,” to the left of “Ready for Development,” for these cards that had been planned without being well understood. (Continued)

Avoiding Mini-Waterfalls

A lot of people and organizations, when transitioning from a serial software development lifecycle toward an Agile one, fall into the pattern of mini-waterfalls. They start doing iterations, but each iteration resembles the development lifecycle they already know. The programmers do some design work, then they write the code to implement the design, then unit test the code, and then they pass it to the testers for testing. To many people, this is the only way it can work. Their mental model only admits to this series of phases.

And they run into typical problems. Sometimes the design doesn’t fit the problem well, and patches are needed because there isn’t time to go back to design. The testers get squeezed for time at the end of the iteration, and no one knows how to accommodate the rework when a problem is found. More patches are added, because there isn’t time to redesign. And the next iteration starts the cycle over again.

Sure, doing this in two to four week cycles beats doing it in six to twelve month cycles. But only a little. Most of the time, it starts to fall apart if the team doesn’t learn to work differently.

But it’s inevitable, they say. (Continued)

Podcast: Acceptance Test Driven Development and the 3 Amigos

Also while in Las Vegas for the ADP/West Conference, Bob Payne and I sat in the Agile Philanthropy booth and recorded a podcast on Acceptance Test Driven Development and the 3 Amigos. This is the latest in a series of Tips and Advice podcasts that Bob and I have done.

Avoiding Iteration Zero

Teams new to Agile often realize that they have a lot to do before they get their new development process at full speed. Looking at this big and unknown hill in front of them, many Agile teams choose to do an Iteration Zero (or Sprint Zero) to prepare before they start delivering regular increments of functionality. During this time, they may try to get their ducks in a row with

  • A list of features to be built
  • A release plan or timeline for those features
  • Setting up development infrastructure such as version control or continuous integration servers
  • Studying or practicing skills in new technologies they expect to use
  • … and other management, infrastructure, and technical endeavors.

They try to get all the preliminaries out of the way so they can hit the ground running full speed in Iteration One. In my experience, they’re still not ready to go full speed. These things are rarely as complete as expected after one iteration, and often aren’t quite in tune with the actual needs of the project.  The list of features will likely not be complete, but the attempt to approach completeness will dump in lots of ideas that have been given little thought. Any attempt to project into the future still has no data about how fast things can be accomplished. The infrastructure may or may not be the best for supporting the project, but it is likely that the project will now conform to the infrastructure rather than the other way around. The choice of technologies will be made speculatively rather than driven by the needs of the project. While we may do OK, we’ll have made a lot of decisions with the least amount of information we’ll have in the project lifecycle.

And we’ll have burned an iteration without producing any working software that tests our decisions.

My advice is to borrow an idea from Lean and look at the situation from the output point of view.  Ask yourself, “what would it take to start delivering?” (Continued)

The Reality of Automated Acceptance Testing

Recently, Jim Shore wrote about The Problems With Acceptance Testing.  I like Jim, and respect him a lot.  Because of my respect for his opinions, I found it quite discouraging that he said, “I no longer use [automated acceptance testing] or recommend it.”  Gojko Adzic has posted his response to Jim.  This is mine.

Certainly when something’s not giving you the results you want, it’s time to make a change.  That change can be to drop the practice that’s not working for you.  It can also be changing the way you go about the practice, or changing what you want to accomplish.  Or, instead of changing, maybe the word “refining” is a better fit. (Continued)

A Lingua Franca between the Three (or more) Amigos

There were a couple dozen people who showed up at the Fool, last night, for my presentation on A ”Lingua Franca” to Ensure You Get the Right System.  I’d like to thank them all for coming and for such lively participation.

These are exciting times.  The tools of acceptance testing and behavior-driven development are progressing beyond the domain of the techies.  They are entering the realm where they can help the Whole Team. (Continued)

If you don’t automate acceptance tests?

Amr Elssamadisy reports on InfoQ that automated acceptance tests are “only used by a small minority of the community.”  Is this true?  If you and your team don’t use automated acceptance tests, please let me know how you handle regression tests as the application grows larger.  You can leave a comment here or, if you’d rather not say it in public, email me directly. (Continued)