Friday, November 30, 2012

scrum fun 3


So as mentioned in prior entries on my Friday scrum I like to play little games or put challenges to the team to determine the order that we’re going to go proceed through the scrum.  I’m particularly proud of the way that this one came off.

So on Wed’s scrum I told the guys that I was going to give them a hint towards the Friday challenge.  It was a simple hint, ‘Get to know each other.’  Man did that ever fuel their creative juices. They grilled the heck out of me for further information but I was stalwart in my information scroogery.   At Thursday’s scrum they asked me pretty please for another hint.  So I gave them an even more dastardly hint, ‘Remember what you’ve learned.’

On Thursday I received a questionnaire from a team member about hobbies and favourite colour and stuff like that.  I answered the questions and sent them out to the entire team.  And I found out on Friday that across Wed and Thurs the team spent a bunch of emails passing information about each other around.  Even if I ended up sick on Friday and the challenge had never happened, this would still have been great team building.  The team worked together to attempt to beat the challenge and help each other succeed at the same time as building stronger connections with each other. 

So we come to the scrum this morning.  One of the team members asks me before we go in if they are allowed to bring in notes.  My response to that was essentially the same as the one I had to the team member holding a sheet of paper when I got in there and took it away from him.

The challenge had two parts. The first part was that each person around the circle was given 2 seconds to say out to the team the first names of their siblings and/or children.  I stressed that even though they had to be fast that they should be clear in their statements or their team members would have trouble with the next phase.  If they took longer than 2 seconds they would not be considered for the prize at the end of the challenge.  I included this simply because a common theme in our challenges is building up their capabilities to think and respond quickly.  In addition we only have 15 mins for our scrum and the challenges make it quite, um, challenging to get out on time.

For the prize, which I only told them was something small, it was just an entry coupon in the charity draw that we’re working this season.  Each coupon was only .25 cents so it really was a small prize.

We got through the naming sections pretty well, although some could have been faster and I laid out the proper challenge for them.

Each person, on their turn has to first pick another member of the team who had not gone and choose a name from their prior list that had not yet been used in the challenge.  That person would go next.  Then they had to name one name for each other team member that had already gone.  These secondary names could be repeats of prior usage (ie it could be the name was used to pick the last guy).  No one could use their own names.   You may not ask anyone for any further information once the challenge commences – which while I love that my team really likes to try and help each other succeed with their challenges, isn’t

Usually at my scrums I go last.  This doesn’t always hold on challenge day and in fact today I went first.  Specifically because two of my team members are brothers and I wanted to take that selection out of the equation.  I chose one brother and used his brother’s name as my name choice.  It proceeded.  Not everyone succeeded but they had fun trying (I think) and the best part was by the time we got to 4 or 5, people were reciting the other names pretty quickly and getting them right.   The hardest go was the last guy, who had to pick one of my sibling’s names.  And unfortunately one had already been used so he had to pick the only one left.  He didn’t make it. 

There were complaints that siblings and children’s names wasn’t one of the things that they studied but there’s a lesson in that about assumptions being made as well. 

To Paraphrase, ‘the challenges will continue, as evil or greater, until morale improves.’

Tuesday, November 27, 2012

Resolution Testing

A while ago when I started a new job I first encountered the rampant use of the term 'regressing bugs,' or 'bug regression,' or any number of other variants.  This phrase, as you can probably guess, relates to the notion of verifying the resolution of a bug by development.  At my current place people have been saying 'verifying bugs,' or something similar to that.

The use of both of these phrases is a bit of a pet peeve for me, because they are inexact and the words don't actually mean what you want them to.  Regression Testing, of course, is the action of proving that the application works the same as it always did when you make changes in other areas that should not have impacted the area that you're regressing.  Bugs, shouldn't work they way they do, so you can't regress that they still work that way.  And if you're going to verify a bug, to me that means you're going to take the repro steps and make sure that the bug still exists, or that they actually produce the error state.

OK, fine, i'm a self-professed nitpicker.  Honestly, I thought you'd have figured that out about myself by now.

But I don't believe that a problem is worth harping about unless you're willing to help progress the solution.  My team and I, a few years ago, decided that there could be a term for this.  We discussed some options and came up with the term, 'Resolution Testing.'  It seemed to be perfect.  Simple, easy to understand what it means from the words and doesn't seem to mean anything else yet.  So we started using it.

Then we took it a step forward. In investigating the testing terms out there that people were using we had a rather vigorous and amusing conversation about the different forms of primate testing that there are.  ie Monkey Testing and Gorilla Testing.  So when we did come up with the nice formal term for it, it was also unanimously voted that there should be a primate term as well.  All of a sudden my team wasn't even doing Resolution Testing anymore, it was Babooning.  Hey, anything that can make the boring parts of work more enjoyable is good, right?

So there you have it.  When you have to verify the solution to a bug or issue, you're doing resolution testing, or if you like, you're babooning.

Back when i decided this was the term to use, i created a wikipedia article for it but it only lasted 2 days before they took it out for lack of sources.  Well, this article is a step towards creating the next attempted wikipedia page.  Feel free to spread the usage of the term, maybe write an article of your own and there we'll have it...a new term used by one and all.   (why do i want to put a maniacal laugh after this statement?)

Since that time, Resolution Testing, has been used a bit for testing the resolution of our monitor and etc, but i am choosing to ignore this fact.