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.’

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.

scrum fun 2

As i've mentioned in prior posts, i like to shake things up a little bit in our daily scrum on fridays.
This past Friday i gave my newest employee the helm with the following request:

"In descending order the number of colours a person is wearing in their clothing.  Shades do not count, if it's blue, it's just blue.  You may ask each person two questions.  For the purposes of this task shoes count as clothing but accessories do not.  Underwear is in scope."

So the person i gave the task to looked around at what people were wearing and picked someone and proceeded to not ask them anything.  Slightly uncharacteristically for this type of  task i helped out a bit and said, 'you know, a question you might ask is, "how many colours are you wearing?"'  The person took my lead and answered, indicating 7 colours.  So we go their update and then the leader went on to pick another person, not ask how many colours they were wearing and directed them to start.  At this point i injected the rule that each person had to announce their colour count upon being chosen and then give their scrum update.  This next person was wearing 4 colours.

That ended up being the fewest colours i think.  but they were all over the board between 4 and a second 7. It was fun for the team, they bonded and worked together in getting the answers out.

In the end though i got to do something that i haven't really done in the past during one of these scrum exercises.  I was able to say, 'this scrum has a lesson right in it for you.   The results that you've seen here (nowhere near descending) are precisely what you get when you don't gather your requirements and information before you start developing."  This got immediate and vocal feedback because as QA's, it related to their experience with code they've been shipped time-and-time again across their careers.  As always the best lesson is the lesson lived and learned.

As an end note, i wish that i could say that i went into this knowing that we were going to learn this lesson.  Really i wasn't.  I was simply forwarding my quest to get my team to think out of the box, think quickly,  respond to changing circumstances intelligently but with resolve and decisiveness, to team build a little and best of all, have a little fun.   In fact, i can't even claim that this scrum request was my own.  i wasn't feeling so creative so 10 minutes before the scrum i emailed my wife and said, 'this is your one opportunity to guide my scrum today.  you have 9 minutes to provide an idea for determining scrum order,' and she came back with this one.

I will take credit for spotting the message however.

put the 'fun' in 'scrum'

We don't run agile here.  They tried it for a while and have kind of moved away from it.  I'm not entirely certain that they could or could not run it successfully but the fact that the development teams spend a lot of time working on support and maintenance issues mid-project has to be solved before a pure agile implementation could be useful.

What we do do, however, is have daily scrums.  But instead of being segregated agile team based they are functional team based.  So as QA Manager i actually go to 5 scrums every morning.  One for each of the two development groups, for the the CS group, one for the managers group and my own for the QA group.  I find that there is a lot of benefit to me in each of them, each being run a little differently, in learning what's going on in all these groups.  In the end, my group will end up involved in just about everything that they're working on.

My team's scrum is pretty much the standard.  Stand up, speak consecutively in a circle, each person indicating what they did the day before, what they'll do today and indicate any blockers that they have.  Chickens listen rather than speak and for the most part we speak with respect and listen intently.  the speaking order had been standardized long before my arrival and essentially starts with the person to the left of the manager and goes around back to the manager.

After a few weeks of that i decided it was boring and starting shaking the pillars of peoples belief structures and started reversing the order from my left.  I would do this on random days but most often do it on a friday.  it's amazing how easy and yet hard it was for people to accept this.   further shaking things up, i'd look at one person and say the name of another person to start.   For whatever reason, just this little bit of change would bring some joy and laughter into the morning as people wake up to deal with change.

then i stepped things up a level.  now i do a new thing, i set a criteria, set someone in charge of judging the criteria and determine the turn order for the scrum.  some of them are pretty easy and others are a little more complicated.  i have witnessed some pretty interesting times and the benefits of these little deviances have been really quite a bit larger than i'd expected.

I will talk about the benefits in a second but before i do that, i'm going to list off some of the exercises so you can get an idea of my twisted mind.  These are listed in roughly the order that they came out, ie they started gentler and are getting harder.   My team has decided that i throw this kind of exercise at them every friday but in actuality about a third of them are randomly through the week when i'm feeling like it's time.  Sometimes you're only allowed to ask once, sometimes you're not allowed to ask at all.

1. Height - tallest to shortest.  (entire team judged this one)
2. Hair length - longest to shortest (judge was necessary)
3. Age - oldest first (female on team was judged youngest regardless of actuality)
4. Longest commute
5. Alphabetical by middle name - only get to ask once. 
6. Difference in age between yourself and siblings added together. Largest to smallest
7. Distance born from Greenwich England, shortest to longest. 

Here are some of the benefits:

1. Team building. 
1. Learning about each other's external to work-lives brings people together. 
2. Helping each other problem solve
3. Bringing them together to help defeat the evil criteria maker. 
4. A lot of laughter happens in the stumbling around the criteria.  Laughing together always brings connections, especially when it's not cruel. 
2. Problem solving
1. Increasing their ability to jump in and solve a problem out of the blue.  You don't know if you're going to be the assignee that day and there's only 15 minutes for the scrum so you have to move fairly fast. 
2. Thinking on your feet - the criteria do not cover all cases on purpose.  the assignee has to  made a judgement on such things as ties and move on.  you don't gain points for randomizing either, you have to state your criteria and stick to it.  (points aren't real, but laughter for criteria is)
3. People are getting used to coming up with ways of achieving the knowledge to settle the criteria quickly. 
3. Ability to react intelligently to weird requests
1. A major skill to have when interviewing, reacting well to the unexpected challenge or question.
2. Everyone is getting quite a bit better at this.  The ability to react quickly is possibly the best benefit i've seen.  
4. Leadership
1. by assigning people the lead in these cases they're all getting a little bit more experience in making decisions. it's really helped some come out of their shell. 
5. Requirements Interpretation
1. There's been a marked improvement in communicating some rather complex criteria.  People are getting better at listening, interpreting, asking questions and moving on. 

It's been an interesting experiment that i am definitely going to continue.  I never anticipated anywhere nearly this level of benefit from such a little exercise but there it is, providing good stuff in many different ways. If only it didn't make people look at me like the weird uncle they are always happy to see cause he's weird and funny. 

Hiring for Diversity

Getting the right mix for your team can be a pretty difficult thing to get right.  Obviously your goal is always to have a team that 'clicks,' that meshes together well, can take communication short cuts and can share the hell out of a vision and deliver deliver deliver.  

There's a trap inherent in that path of thinking though.  It's not as simple as finding a bunch of like minded people that really gel as a group with high levels of camaraderie and etc.  OK, that's actually a way to pretty good results in a lot of ways, or at least it will seem like you're getting good results.  Your team can work together relatively well, perform smoothly and deliver deliver deliver.  What they won't really do, unless they're super-special is innovate.

Think of it like a troop of soldiers.  Once they've spent their 300 hours of training to march together, when they're going down the road together, that's where they remain.  There won't be the misfit who wonders off the road, runs to catch up, wanders ahead and has time to look at other things, kind of like a lost puppy.  Nope, they look really cool, marching in step, making progress, getting where you want them to go.  unfortunately, when they get there they're all still wearing the same clothes and saying the same things that they've been saying for the past 400 years.

Don't take this to mean that you should be going out and hiring a bunch of star performers either.  Plunk that idea into the same analogy.  Now what you have is an unruly bunch of puppies that are tearing off after every little thing that they can find and if, and that's a huge if, you can ever get them to the destination they'll still be an unruly mob with no real delivery.  the only way around this is a truly exceptional leader who can hold things together but that person is likely a super-genious, or in this analogy, has a pocket full of steak.

Here's where the diversity comes in.  Hire cross-spectrum.  Take on a few star performers and some solid but smart performers.  The smart performers are going to keep your troupe moving along to the final destination, keeping the goal in mind as they goal.  they're there to not only get the core work done but to hold onto the vision in the group mind so that your stars can be guided back to it by honest peer pressure.  Maybe not even peer pressure, that feels too directed of an action on the part of the team.  More of a peer gravitation.  the star performer should see what direction the team is going and be motivated to catch up and help it get there.

An exception here is the prima dona class of star performer.  For me, your general prima dona isn't actually a  star performer.  Because while they can be responsible for some pretty stellar results, they don't consistently perform for you, nor do they bring things forward as a general rule.  They are quite useful in cutting edge industries but most of us aren't working in such a place and don't really need amazing sometimes, we need great all the time.

The other benefit of the diversity is that the differences within your team are what help to drive the innovation.  When you put different people in a room and start to brain storm, the building of the storm of creativity comes because someone says something that triggers something in another persons mind and then true innovation can happen.  if you have over-alignment, then you don't get that spark of difference that helps the entire team create.   it will often be your star that gets sparked but it doesn't have to happen that way, idea generation can happen all around.  in fact, what your star performers do is help bring all of your core performers up a notch.  Now your entire team is producing something of even better quality.

The one caveat here is that fit is still important.  your team still has to be chosen so that a base level they can work together amicably.  You need some shared experience or like mindedness to keep everything moving along forward.  No one likes strife in the workplace.  As for mix - like everything else in life, there's a balance here that you have to find.  In my experience the mix has been about 70/30 core to star.  And indeed there's even room to discuss adding some grunts, juniors or under-achievers but i think that's a discussion for another day.

In the end though, you have to find the ideal mix for your team, maximizing fit where you can and then lead them forward, herding the puppies when necessary but allowing them the room to lift your team out of the doldrums.

Culture of Quality

I think that the biggest single thing that stands in the way of the so-called culture of quality having the impact that it desires is the fact that all-to-often the words are simply lip service.  It's far to easy to say to people that it's really important to have the highest possible levels of quality and yet it's not easy at all to actually back up that commitment.

I think that one of the largest things that have you end up in a place where you say one thing about quality and actually do another is the fact that saying you have a culture of quality is not quite the same thing as trying to make one happen.  I've been in countless releases where the QA time budget gets chopped due to timeline commitments and invariably you end up having a risk/benefit conversations.

A risk/benefit conversation is that conversation where you go in knowing that there is appreciable risk from moving forward with the release but the benefits, not only of the product to be released but to the relationships that it will feed are more appealing. The big problem with this conversation is that generally the way that the risk is mitigated comes around to a statement like this, 'sure we'll go, and if it goes badly or there's bugs, we'll figure out how to spin that so things are still ok.'

Simply put, that's not quality.  I don't disagree that you always have to do a risk analysis and weigh the pro's and cons of your remaining issues pre-launch.  That's obviously the way to go but when it becomes a battle between QA and pretty much the rest of the world to go live then you obviously haven't fostered a culture of quality.  You may, in fact, have empowered your QA to fight against the rest of the company but that's a hard battle to fight and it really doesn't help.

In order to achieve the culture of quality you have to give every participant in product design and delivery the idea that quality is the first and foremost goal of the organization.  That means that 'good enough' when figuring out your requirements is never the right answer.  I don't mean that you have to have feature upon feature or that each feature has to be the best possible feature that it can be.  Those goals simply aren't practical but the goal that is is complete requirements that truly define what the end product will be.  Going back to the well to figure out these complete definitions needs to be the norm.

Developers who write code and throw it over the wall to QA need to be schooled.  Take pride in your work.  Use test driven development, always build unit tests into your code.  Above all else, when you do your design work, think about the environment that your code will live in, how it will interact with other systems and the performance needs that will be met.

QA needs to consider usability where it may have been missed, analyse requirements properly to get the root needs and communicate clearly.  They also need to stick to their guns when quality isn't been met.

For all of these things to be possible, from the top down there has to be support to the concept that quality comes first.  That when things aren't ready they don't ship.  C'levels have to protect themselves from this possibility simply by having the culture supporting quality throughout the process.   You won't ever come to the hard question of 'should we ship' that's been guarded by an empowered gate keeper if everyone along the path has already spent their time and their empowerment producing the highest quality that they can.  (ok...won't ever might be slightly idealistic)

Culture of Quality...it starts with you, and you, and you.

A dorky video about quality management

The Chartered Quality Institute put out a little video explaining what quality management can do for you.

It's kind of dorky and a little trivializing but it's still cute and informative.

The CQI link page