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.

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)

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)

The Quality Carousel

I just observed yet another conversation on twitter that started with the topic of waste in software development, brought in value as an arbiter between waste and necessity, and then quality as a modulator of value. Surely a practice that increases quality also increases value, and therefore cannot be considered waste.

These discussions seem to spin in circles. They always have, and likely always will. Why? Because they treat quality and value as attributes of what is built, rather than as relationships. I like Jerry Weinberg’s definition in Quality Software Management:Systems Thinking.

“Quality is value to some person.”

This does not bring agreement to the discussions of value and quality. It does bring a different focus to them. Who is the person that matters? I can tell you who that is. (Continued)

Validation and Uncertainty

What an extraordinary conversation I had recently on Twitter. It started with Neil Killick’s statement that we should not consider our stories truly done until validated by actual use. This is a lovely thing, if we can manage it. While I’ve not set such a bold declaration of “done,” I’ve certainly advocated for testing the benefit of what we build in actual use. Deriving user stories from hypothesis of what the users will do, and then measuring actual use against that hypothesis is a very powerful means of producing the right thing—more powerful than any Product Owner or Marketing Manager could otherwise dream up.  (Continued)

Setting Expectations

Karl Scotland wrote an excellent blog post on Estimates as Sensors. In it, he extols the use of estimates to “sense capability and create feedback for yourself.” This is similar to my point in Estimation as Hypothesis.

At the end of this post, it now says “I don’t recommend using them to make promises and give guarantees to others.” Originally, this said something like “I don’t recommend using them to make promises and setting expectations of others.” I asked him what he did use for setting expectations. He had two responses. “I’d say expectations are set from understanding our capability, refined through sensing, and with a confidence range.” and changing the post to reflect his original intent.

There’s more to this business of setting expectations. (Continued)

Short Overview of Estimation

Back in 2008, Bob Payne and I were working with a team learning to practice Agile Software Development. They were doing quite well at a lot of things, but their sprint velocity bounced up and down like a yo-yo. The sawtooth velocity chart indicated, since they were clearly delivering value at a pretty steady pace, that they were not very good at estimating stories. Bob suggested to me that they might do as well, with less effort, by counting the stories instead of estimating them. (Continued)

What does it mean for an estimate to be right?

What does it mean for an estimate to be right? Does that mean that later actuals had the same numerical value? That the project length, or cost, or end date was the same as the estimate? Is it an indication of the “correct length of the project,” whether or not the project is done in that time? Or is there some better definition of “correct estimate” that we can use? (Continued)

The Date Question

A common question heard in companies that produce software, either for in-house use or for sale, is “When will this software be done?” I’ve observed this question being asked when it was not yet decided what the software was to include, nor who was to build it. It’s clear that we have little on which to base an estimate, given this state of affairs. Nevertheless, in many organizations, people will start to anticipate what it will include and who will be available to build it in order to give an answer to this question.

Not everyone is so compliant, though. Some people will say that not only can you not estimate the construction with so little information, but you don’t need to estimate it. They’ll say it’s enough if you can build it in little increments of functionality, and stop when it does enough. (Continued)

Independent Interpretation

Many organizations segregate their programmers and testers in order to achieve independent validation of requirements.  If the system is tested according to an independent interpretation of the requirements than used for implementation, then errors in those interpretations may be detected.

This course of action is obviously prudent when the requirements are handed down to the development organization in the form of a document. (Continued)