The Importance of Real-time Collaboration
I have spoken so many times about the importance of collaborating, and yet I still fall into the same trap that so many others do. How can that happen? Aren’t I supposed to be a pro? Here’s my story. I’m working on a product where we are in four locations. The customer (Cindy) is in Europe, the developer (Dennis) is in South America, a tester (Tammy) is in the U.S. and then there is me doing 2 roles – surrogate product owner and tester – from Canada.
The Problem
Our customer, Cindy, was testing our beta release. She reported the following issue in an email, and included a screen shot of the error.
I registered as a new user and started the flumadiddle data entry process. It broke while I was doing the bletherskate.
I cannot continue with that process, even after I log out and login again.
The skookmachuck is fine and the data that I entered is fine.
The Email Discussion
Tammy, the other tester tried to reproduce the issue, and had some questions.
I just tried flumdiddle, and was able to complete it with no issues, although my user was already registered. Did the server crash while Cindy was taking the assessment, and was already back up before I started my testing?
Cindy the customer replied.
The developers must have the log file, so they can debug the error.
Dennis, the developer added these comments to the email chain.
Yes we received an email with the error description. Here’s what the log file said:
A NoMethodError occurred in zzz#result:
undefined method `-‘ for “10”:String
Did you mean? -@
app/controllers/zzz_controller.rb:204:in `result’
But… let me tell you this is really weird, could you please @Cindy describe to us the steps that you took?
From the log messages, it appears that you entered an “Integer Value” in a String Value for the ZZZ Session Variable. Looking at the code, it doesn’t appear to be possible to do this.
Cindy replied to Dennis’s questions
I just input the data and clicked on the Next button. Just normal happy path use, nothing weird.
I’m still having the same issue. I cannot continue with flumdiddle nor start it over again.
The normal case should be that I can continue or start it over again.
My response to Cindy
One correction – once you finish flumdiddle, the system won’t let you do it again.
Hopefully Dennis can find out what the error is.
The Answer
Interspersed with these email conversations, I had been chatting with the developers during our daily “stand-up” and by chatting via instant messaging (IM). I thought I understood what was going on.
The developers were sure they fixed the issue, so I sent this email to everyone:
- Dennis has explained the problem and checked in the fix. He is doing some more testing and will move the fix to staging today for me to test. If it is ok, then we will put it into production.They are sure they know what caused the issue that Cindy found, but still not sure how it was possible for a user to get that error. I’m guessing maybe Cindy had tried before we had completely set the configuration for testing. ……. (at least I hope that was the reason).
- Cindy still can’t complete the flumdiddle, she still gets a 500 error. Dennis is working to find out why that is. Even the admin can’t look at the data she entered, so something wasn’t stored correctly … or something. Once Dennis knows the cause, then we will determine what to do about it. Perhaps we’ll have to delete Cindy’s account and have her start over, but we won’t do anything that drastic until we know the “why”.
The Confusion
When I sent that email, I was positive I had it right. However, it soon became apparent that the second bullet point wasn’t true at all.
There were a couple of issues from my side … I made assumptions. When Cindy reported the issue in the beginning, she attached the “500 error” screenshot. I didn’t really stop to take in the other comments or think about the implications. For example, she said she could not continue doing what she was doing, after logging out and in again. All I saw was the 500 error and ‘assumed’ she couldn’t even see her account, a scenario which had happened once before. I kept that bias with me throughout our conversations, but didn’t realize it until I asked Cindy to retest to see if she got the 500 error after Dennis implemented the fix.
I sent Cindy an IM to retest to see if she could log in because we couldn’t see her error. Our conversation went back and forth a few times and finally one of her comments stopped me … completely – I realized I had gone down a rabbit hole and assumed something that was not true. The developers had fixed the underlying problem, but I thought Cindy was still having the 500 issue – even though she had never explicitly said it. She wasn’t.
The Course Correction
I finally did what I should have done the day before – I got all 3 of us together on a video call. I had Cindy share her screen and explain her complaints. I realized I had some completely wrong assumptions…. We had the developer explain exactly what happened and how the code worked. Cindy had some very specific ideas about what the problem was, but because she is not technical, didn’t really understand what the developer said the problem was. However, she asked some good questions which led me to ask the question slightly differently so the developer was able to answer, and I had a much better idea of the real problem.
Although Dennis was confident that his fix would prevent the 500 error from reoccurring, nobody but Cindy had seen the error. Cindy wanted Dennis to repeat the exact steps she had done in the flumdiddle process to reproduce the failure. She wanted more confidence that if she repeated her test scenario from scratch, the error would not occur. We agreed that Dennis would test with her exact steps to prove that the flumdiddle process behaves as expected.
The issue that Cindy was most concerned about – not being able to finish the bletherskate process and get the final expected result – the piece I totally missed, had not been addressed. I wrote a story card to go into the next iteration to address that. We, as a team, need to decide if that issue happened again, what could we do to address it – perhaps be able resend the information? Not sure, that is for the next conversation.
In the meantime, Dennis tested the exact scenario that had produced the 500 error for Cindy, giving her confidence to deploy the new feature to production.
Conclusion
My conclusion to this fiasco…. STOP assuming. START video conferencing and collaborating earlier. This whole mess would have been avoided, if we had done that right away instead of trying to work it out through emails – he said, she said, … etc. I knew better, in fact, we all knew better, but that didn’t stop us from doing exactly the wrong thing.
LESSON LEARNED … again! Hopefully for the last time.