Never take words for granted

Since this summer, I’ve been chasing an illusive error source in one of our systems. It’s nothing crucial, but sometimes the error pops up and it’s really annoying. It bugs my tester spirit that I haven’t understood why this occurs.

When I first found the error, I was told that it was because of duplicates in a list. “We have duplicates of value X in table Y.” But I couldn’t understand this. Duplicates are common in this table and not all of the rows with the duplicates have the error. Instead, the error was sometimes somewhere else.

Just today I realized that we just used a word very differently. I interpreted the statement as that multiple rows had the same value in the column. For example:

Value  Text
1           A
1           B
2           C
3           D
4           D

I would say that there are duplicates in the column “Value”. But that was not was the business people meant by duplicates in this case. What they referred to was that multiple rows could refer to the same physical entity. That is, that Value 3 and 4 could refer to the same entity (Text D). So, the error was someone completely different in the system.

A successful meeting

I took over another project the other day. The project hasn’t started and the problem was that we were waiting for some technical specification from a supplier. I was told that we’d been waiting for a month to get some information, but we still hadn’t gotten it. The business people are really eager to get going, so, you know…

I talked to the guy who’d been in contact with the supplier and asked him which information we needed. It turned out that we needed a specification for a certain function (X) so he could ask the operations team how much time this would take. It turned out that he hadn’t talked to the supplier, but a lot of e-mails had been sent between him and the supplier. He’s no technician and neither am I. I can admit to that I really didn’t understand what X was. So I asked if our techies had spoken to their techies. The answer was no. So, I called the supplier and asked if they had a techie to spare during an hour telephone conference. I sent all the e-mail conversations to our operations and then turned up on the meeting.

We discussed first and I asked what X was all about. And then the guys said that they thought it was something I actually know what it is but since I hadn’t seen this in other systems, I was puzzled that it had stopped the project. I asked if X was a requirement in our solutions. It wasn’t. Then we called the supplier and asked if the previous e-mails had been about X. It had. We then asked who had asked forX in the first place. Then it turned out to be that the supplier had asked if we wanted X. And there had been a huge misunderstanding that X, which we don’t want, was mandatory.

The meeting was over in five minutes.

Something are not suitable to discuss in e-mails and sometimes it’s better to leave the techie stuff to the techies.

Frustration over having to explain ALL the details

Have you’ve ever been in a situation where you think you’ve written a requirement or something like that and thought that no one can misunderstand or misinterpret what you’ve written and been completely wrong. It’s amazing how one word can be interpreted by different people. And when it comes to sentences. And many sentences. So, what happens when you’ve been in such a situation? Well, you try to be more clear the next time. And there is a good risk that you add more words. And the risk for misunderstanding just rise even more. Perhaps that will take gigantic proportions, like in this example from a technical manual, where the writer obviously have been misunderstood by a mechanical contractor in the past. You can just feel the frustration from the writer. "If he won’t tell the difference between a long and a short pipe now, I don’t know what I’ll do"

To sprint or not to sprint, that is the question

The problem with scrum and agile lingua is that it’s so often misunderstood. Being a runner myself, ‘having a sprint’ is something completely different than what you want in a scrum sprint. When I sprint, I run like hell until I reach the goal and there should not be any energy left to just start a new  sprint. Mike Cohn told a similar story with a team which used Sprint as a term for when you just coded like hell just to meet a deadline. Not the sustainable pace, in other words.

Reading Seth Godin’s blog post Sprint!, I can see that his concept of a sprint is more in the line of the runner’s sprint rather than the rugby and scrum sprint.

So, is ‘sprint’ a good word to use? Does it not cause a lot of confusion? Especially if you also use words like iteration. I’ve found that I’ve stopped using the word at my new position. Not deliberately, but I’ve realized that I will be misunderstood if I use that word. Worth reflecting on when introducing scrum in a new organization.