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.

Hmmm… What does that mean?

On numerous occasions I’ve observed long-time members of the Agile community complain about misinterpretations of what Agile means, and how it performed. Frequently this is precipitated by yet another blog post about how terrible Agile is, and how it damaged the life of the blogger. Sometimes it’s triggered by a new pronouncement of THE way to practice Agile software development, often in ways that are hardly recognizable as Agile. Or THE way to practice software development is declared post-Agile as if Agile is now obsolete and ready to be tossed in the trash bin. (Continued)

Estimating in Comparison to Past Experience

The simplest method of estimation is to compare the anticipated work to past experience. And we all have experience that we can use. The big question is how relevant is that experience. A secondary question is how clearly do we remember that experience.

We always have experience, of course. We weren’t born developing systems. We’ve tried things, and learned things, from childhood onwards along a path that’s lead us to today’s situation. In all the things we’ve done, there’s something that we can compare with the work we’re facing. (Continued)

I’m late, I’m late!

Even when you’ve done something many times before, sometimes you forget something or make a mistake.

This morning I was on my way to visit a client and realized I’d forgotten something. It seemed to me important enough to do something about it, so I went back home and got it. The unanticipated delay threw my schedule into disarray. I wasn’t going to arrive by the time I wanted. I was frustrated and unhappy with myself.

I see similar things happen all the time in software development projects. Something throws off the schedule. People get unhappy. (Continued)

Framing the Question

“I need this project done by date D and within cost budget C. Now calculate an estimate on the project.”

A friend of mine used this example to illustrate anchoring bias in estimation. Note, however, that he doesn’t make the question explicit. Further conversation revealed that he had in mind that the date and cost should be the output of the estimation. With that assumption, that statement preceding the request will definitely anchor the answer, and realizing that this bias is likely will call into question whatever estimate is given.

Given the stated need, however, I would reframe the call for an estimate from “When will this project be done and how much will it cost” to “What is the likelihood that the project can be done within these constraints?” (Continued)

Visual Management Tools

Sometimes we intentionally make our work more visible so that we can more easily see what’s going on. We do this so that, as a group, we get a better picture of the whole of the group’s effort. At it’s best, this is more than a dashboard that displays information. Instead, it’s a tool that’s used by the people doing the work in the process of doing that work. (Continued)

Agile for Humans podcast

Ryan Ripley has posted the second Agile for Humans podcast where he, Amitai Schlair, and I discuss the life of a consultant, how to make retrospectives valuable, and the place of managers in an Agile organization.

No Time to Learn

The number one problem I see at clients is that there is no time to learn. Without time to reflect on how things are working, we don’t notice the things that we’re accustomed to not working very well. Without time to research what others are doing, we can’t make informed choices about things we might want to try. Without time to try experiments, we can’t find out if a different approach will work better for us, or not. Without time to try multiple experiments, we can’t evaluate what works for us over a broad range of situations rather than latching onto the first idea that appears to work at all.

To a large degree, Agile software development IS learning. We try things mindfully, watch the results we get, reflect on why we get those results, and adjust. We do that at multiple levels of granularity, from choosing what products to develop to writing code that works reliably.

It takes time, but it pays off over time. To keep doing the same things in the same way suggests that we know everything there is to know about it, and there are no improvements left to make. That we are already at top speed. That we can only do worse than we are right now. I find that highly unlikely.

There is always more to learn. There are ways to learn better ways to learn.

Mocking External Services

Should your tests mock outside services or not? I keep seeing discussions on this topic. On the one hand, it lets your tests be in control of the testing context. Otherwise it may be very difficult to create a reliable automated test.

  • The external service might return different results at different times.
  • The external service might be slow to respond.
  • Using the external service might require running the test in a particular environment.
  • It may be impossible to generate certain error conditions with the real service.
  • There may be side-effects of using the real service.

On the other hand, our mock of the external service might differ from it in important ways.

  • Our mock service might have a slightly different interface than the real one.
  • Our mock service might accept slightly different parameters than the real one.
  • Our mock service might return slightly different results than the real one.
  • The real service might change behavior, and we won’t notice until we deploy to production.

This leaves us in a quandary. What to do? (Continued)

Changing Behavior by Asking the Right Questions

My article, Agile Adoption: Changing Behavior by Asking the Right Questions, has been published over on (free registration required). It talks about when managers want change, but don’t want to squeeze the Agile out by force.