Monday, December 31, 2012

Customer Service is listening and empowerment

So this past weekend I was out at a local business buying some stuff.  The local business is a national chain that sells hardware, housewares and etc.  They have a parking lot that is managed by a 3rd party.  I don't really know the ownership of the building and etc and i don't really care, what i do know is that the parking lot is managed by someone else entirely from the business i was going to visit.

So i'm arrived, i park and go to the parking metre to pay for my parking.  the first metre accepts my money happily and does nothing.  now, as an unlikely coincidence the parking metres were made by my company and i know what my putting money in, without the commensurate dropping sound and no screen updates means.  The machine has entered into a jammed state and roughly about $30 of change is going to plug up the chute until no more change can be added.  The only solution is for someone with a key to come out and clear the chute.  I grumble a bit about my lost $2.25, step two steps to the right, plug the other metre and everything is fine.

Now at this point i could call the parking operator, let them know about my lost money and suggest that they have someone from maintenance come out to fix the unit.  But i don't care enough about my money to call and the likelyhood of someone coming out to fix the unit at 6pm on a holiday season saturday are pretty slim.

Instead i head into the store and find someone who works there.  I let them know that the metre outside is jammed, that i understand that it belongs to another company and i don't expect anything from her.  She gruffly tells me that they've called customer service and it will be taken care of in due course.  I say that's great and i'm glad it's being taken care of but maybe she might consider putting a sign up on the metre saying that the machine is out of order.  Another gruff response about it not being theirs and customer service has called them.  I mention that it is currently putting her customers in a place where they are losing their money and maybe a sign would be a good idea.  Her response was that it wasn't their machine and she couldn't do anything about it.

So...there's a couple of things here. One, i was trying to be helpful, polite and understanding and her attitude back was really grating to me.  I get that.  it's holiday season, maybe she was tired and cranky.  Although, 2 weeks before the same person's attitude had also been gruff and annoying to me.  So just in general, dealing with people in a bad mood in customer service is not a good experience for the customer.

But the second is a problem of empowerment.  I understand that the lot isn't controlled by the store but the building is plastered with the retail stores signs, the parking lot is plastered with the retail store signage and the metres are 10 feet from the door to the only store you can access directly from that lot.  Most customers are making a connection between the store and the parking lot.  The parking lot just stole a customer's money.  Whether or not the customer is going to get their money back is one thing, and i realize that most customers are going to want that but even beyond that, knowing that the problem that has impacted their day isn't going to get fixed soon, that's a larger problem.  That retail store employee hadn't even been empowered to put a sign on the device saying out of order.

have you ever used a pop machine at a big store?  most of those are operated by a 3rd party.  when it's out of order, do you as a customer accept that it's ok for you to just lose your money?  no, because the affiliation becomes part of identity for you.  The customer service experience here would have been significantly better if the employee had simply been empowered to put a sign on the metre.  Failing that, escalating the situation should have been able to find someone in the retail management who could put a sign on the machine.  Hell, the experience would have been better if she's simply said, ' i will see what i can do about it sir.'

What did i do in the end, well i went about my shopping.  We told a couple of people not to use that machine on the way in, and a couple more about the machine on the way back out.  Then we got to our car, dumped one of the bags of purchases out in the trunk and went back and put the plastic bag over the head of the metre.  I, as an individual am empowered to help my fellow man even if the employees of the retail store aren't.

Monday, December 24, 2012

most advice is bad advice...

so a buddy posted a link to a blog i don't normally read because he liked the entry.  the entry is about how most advice given is bad advice.  it's a pretty short read, succinct and to the point.  in general advice is crap and you should discard it or sometimes advice is good and you should follow it.  kinda obvious when i distil it down to that level.  but the blog post did accomplish the most important thing about blog posts, in my opinion, it made me think.  (i hope mine does the same for my readers on occasion)

So here's my two cents on the matter (i do miss the cents key on computer keyboards).  You should never wholesale ignore any advice given.  nor should you wholesale follow any.  I believe you should treat advice much the same way as one should treat a tarot card reading or your horoscope.

OK, that's a little hard to accept given what most of us do with such blather.  Rather, you should take from it the same benefit that such 'readings' give to people who listen.  As with any good psychic reading, what should happen is the readee (is that a term?) should listen to the generalizations and begin to talk through ways that they relate to their own life.  As they go through this process of relating they hopefully make a breakthrough or revelation about their problem.  Either they understand it better, see it from a completely different angle or just get a handle on it that they couldn't previously attain.  In theory, this then helps them deal with the issue.  Now because most humans are incapable of growth on demand and because 'readings' aren't the best way to attain higher levels of existence  and people listening to readings aren't the most likely to move forward in such a manner...well you get my point.

However, the process is fascinating none-the-less.  The reason that readings are so successful is that they trick you into thinking that the revelations that you've made yourself were initiated by the 'spirits' or whatever.   Watching people go through this process is amazing.  It takes something that you could talk yourself blue in the face in trying to get them to see to little or no effect and instead leads them into finding it on their own.  It's as if they have invented science their discovery feels so brilliant.

This, my friends, is how you should treat advice.  Don't automatically discount it, don't throw it away out of hand, listen to it.  Think about it.  Find a way for it to relate to your own situation so you can understand that situation better.  That other person doesn't really understand you or what you're dealing with but what they do have is an alternate view if what you're into and an varied life experience from yourself.  It doesn't matter that their advice is most likely wrong, what it is is a kick-off point to your finding a new way of realizing your own situation.

All that said, it's really hard not to simply ignore people's advice, no matter how well intentioned.

Monday, December 10, 2012

power of innovation

A friend posted an interesting article about how to stay relevant within your own career.  It was an interesting article that got me to thinking about it from a different angle.  I've added me thoughts to that article.

Take a read if you like - http://barbarianprogrammer.blogspot.ca/

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.


Monday, October 29, 2012

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.

Friday, September 21, 2012

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. 



Thursday, August 30, 2012

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.


Thursday, August 16, 2012

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.



Wednesday, August 1, 2012

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

Monday, July 30, 2012

Specifications and Tolerances - relativity strikes again

Over the years i've been noticing a little something about the usage of specs in design and how you should write and interpret the specs for your design.  It's easy to build to a spec (ok, loaded statement but i'll let it stand for the purpose of this article) but what's not easy always is understanding the intent of the spec and the design and building in tolerance for usability.

I think that most of the time we talk about tolerance in engineering as the fudge factor that we allow for in our  designs.  Or to make the nitpickers more happy, it's the variance that we have to plan for we because we can only expend a certain amount of resources achieving the right level of variation.  It's a numbers game filled with trade-off.  There's nothing wrong with that, to me it seems like a perfectly reasonable way for the world to work.  I don't think that people realize, however, just how much personal opinion they put into the tolerances that they choose.

We were in a meeting a little while ago talking about the design of our parking pay stations and we were talking about meeting ADA standards.  (American Disabilities Association).  This included putting our keypad at certain heights, angles and etc so people confined to wheelchairs could use them easily.  We had a design that we were reviewing and one of our VP's said, 'That's not going to cut it, sure it meets the ADA requirements but it's terrible usability for a person over 6'2".  They have to scrunch over to see the keyboard.'

That got me to thinking about such things.  I'd noticed something else myself years ago.  Most of the cars designed in Japan seemed to be technically large enough to fit a person who is over 6' tall but when you actually fit someone in there'd be a problem with headroom and/or legroom and just overall comfort.  But when you put a someone into a similarly sized German car, the tall guy would fit fine.  I don't really know but I've always assumed that they are designing against the similar international standards.

But watching what happened in that meeting i understood a lot better what was really going on. When it came time to approve the design or go through product testing, without someone there that actually pushed the bounds of the tolerance themselves the limitation wouldn't be known.  And without passing that discomfort onto someone with the power to influence decisions, then it likely wouldn't be heard.  In our case the VP made the statement and suddenly it was an important design decision.  Compare the average heights of people in Germany to Japan and suddenly things begin to really make sense.

Over time, Japanese design has tailored itself better for North American sizes and i can fit rather comfortably into most of the cars i get into.  It's too important a lesson to learn if you want to make sales.  I'm sure there's a bunch of science out there about designing for human sizes and if i was a better blogger i might go out and find it for you.  but for now i'm happy enough to have learned my little lesson about tolerance, both internal to human interaction as well as to external.  After all, the chair that's comfortable to a 6' person, likely isn't nearly as comfortable to someone who's only 4'.

Thursday, July 5, 2012

perception...

quicky...listening to "Under the Influence" with Terry O'Reilly yesterday and heard some cool things.

it's all in how you look at things.
QWERTY keyboards weren't invented to slow down typists as the myth indicates that they were.
There were already 'faster' key layouts in existence that artificially slowed people down because they kept resulting in jams.  The QWERTY solution allowed people to go much faster without risks of jams.
So QWERTY, in effect, sped up typists.  Today we look at it as a solution to slow down typists but that's a relative statement that doesn't really capture the truth of the matter, it was an efficiency measure.

Side note - also learned that one of the reasons that the exclamation point of the past was much more rarely used was that into the '70's the only way you could get an exclamation point on a typewriter (there was no key) was to type a period, press the backspace key and then type an apostrophe.

Wednesday, July 4, 2012

It's good to have a Sacrificial Monkey

This post is a bit about presentation capabilities but also about my own personal management style. 


On a personal level i have very little shame.  There simply isn't much that can happen to me, or that i can cause myself that i can't spin or laugh off or otherwise absorb in some manner.  I think this is a skill that derives from my razor (sometimes far too razor-like) wit and fast reaction times.   I do feel shame when i say or do things that inadvertently hurt another person's feelings for sure but you simply can't make fun of me to the point where i will blush up and hide my face.  Rather in fact i excel at the old give-and-take and it's possibly when i'm feeling most alive.  (having said that out loud, that might be a little sad.)


Fast forward from the slightly awkward confession stage of the blog post to the part where i talk about the benefits of having a sacrificial monkey and how, for the sake of this discussion i, myself, was said monkey.    


Recently my company brought in a speaker who gave a seminar about personal financial health.  A talk about debt managment, managing personal risk (ie buy some insurance from me please) and saving for the future.  A topic, if you will, that is at great risk for being slightly traumatic and highly dry and boring.  


When our paid speaker came out you could tell that this is what she does for a living.  She's dynamic, smiley, friendly and filled with personality.  She has lots of little personal anecdotes and stories and tries to make a personal connection to the crowd right from the start.   She has two assistants with her who help by passing out some high-quality (read expensive) info folders and then essentially stand around for the rest of the presentation.  Attached to each folder is a 'hi my name is' sticker and a pen.  First thing i do is pop my name on that sucker and throw it on my chest.  I am the ONLY person on the room to do so.  I notice this but don't really care and certainly don't take my tag off. 


The talk proceeds and as you might expect, even with the dynamic speaker at the front, the dry and yet awkward material has a fairly quiet and potentially non-receptive crowd.  After all, who wants to know that their spending and saving habits are probably killing them slowly.  She would ask the audience for input or responses to questions and there were only a couple of people who would speak up, the rest were quiet as church mice.    


As we went along it was pretty obvious that while it was a respectful audience there wasn't that sort of give and take that can make a presentation really meaningful and help what you learn really sink in.  Then the presenter called me out by name...remember, mine was the only name tag available, and asked me a question about something I'd said a little before.  And then made fun of me.  And then asked me some more questions and made fun of me some more.   The more that she interacted with me as part of her presentation, the more you could see the rest of the audience becoming engaged with the talk. 


I reacted well to the interplay, joked back with her and effectively kept the humour flowing.  In the end, it made for a more enjoyable and powerful discussion.  At the end as I was leaving she apologized for picking on me, saying that it seemed like i was able to handle it all right.   I agreed, laughed it off and went on with my day. 


This interplay helped bring some clarity to something that i've not only observed but used myself in such situations.  It works in meetings as well as presentations.  It's finding someone to be the 'sacrificial monkey.'  Someone willing to be involved in the discussion, willing to be made to look a little silly and to simply be the example.  Seeing someone else in that humourous or distressful situation helps bring the rest of the audience alive.   You can see the same sort of thing at the circus where a clown plays with an audience member or even with magicians who are using volunteers from the audience.  


Whether it be because the audience identifies with the sacrificial monkey, are glad they aren't them or simply revels in the pain of another, it brings their own personal involvement to the situation to a whole new level. 


Of course i can not warn you strongly enough that choosing the wrong sacrificial monkey can end up in tears, harassment complaints or just bad feelings.  Some people don't react well to the spotlight and you have to be able to see their unease and back away. 


In this case i was fine with it.  Certainly i didn't need to be apologized two because i knew the trick of bringing in an audience foil.  I'm not sure if the presenter actively uses the trick on a regular basis but i'm happy that i was there for her, and more importantly the members of my team that were there and able to have a more powerful learning experience.   Being able to use humour, mocking and other tools as part of your management style can give you some pretty powerful tools.  As i evolve as a manager, i hope to be able to document some of these tricks in a way that people can learn to embrace the methods themselves. 


Until then...will you be my sacrificial monkey?



Saturday, June 23, 2012

DDoS - Issue Tracking Style

Sometimes following process bites you in the ass.  Or maybe i mean that sometimes following process just bites.  Doesn't mean it's not still the right thing to do, it's just sometimes hard.  By example...


We use Jira as our issue tracking system at work.  As with most issue tracking systems, if you're not incredibly (arguably impossibly) diligent at upkeep you end up getting a number of cases that languish forevermore in an uncertain state.   It's just the way of things. there's bugs that you're not going to fix...bugs that didn't make any sense...bugs that got fixed through some other issue but never got cross related...bugs that simply aren't applicable any more because that entire system has been deprecated...and...the list goes on.  If you can follow strong process and make sure that every single bug that you get in is cross-referenced properly and categorized well then it minimizes it but i simply don't believe that anyone out there has no issue with growing languished bug lists.  My opinion is that you try hard to have a good categorization scheme, strong workflow built into your process and your bug tracking system and make your best effort.  And then every couple of years you devote some time to clean-up.  


So fast forward to week before last at my company.  One of the Dev managers decided that before we start some fairly major re-design efforts that the backlog of languishing bugs should be sorted and dealt with so that when we start the design we're not only taking into consideration the requirements and issues that currently rest in the forefront of everyone's brains but that we also make sure we're building upon lessons learned in the past.  A very good and honourable intent.  I wasn't aware that she was making this effort...at least until i started to see it's results. 


So, as QA manager i have it set up that any bug that gets updated, entered, closed etc in Jira sends me a notification.  Daily i read all of these updates, generally less than 50 on your average day and it only takes a few seconds per case unless there are issues.  It keeps me in the loop on a lot of things and when i spot issues then the time spent has been invaluable.  It's a good process to follow for me and as i'm still pretty new, an important one.  Jira has a few annoyances along this line in that standard process for closing bugs for some of my team gets me 3 notifications back to back.  But i've learned to recognize these in the first case and just mark the next 2 read and move on.  


Well one day a couple of weeks ago i started noticing quite a lump of cases coming from the Dev manager.  As i was processing them i noticed that they were all old (some of them 4 years or older) and that they fell into three basic categories;

a) 'no longer an issue, closing the bug,'
b) 'probably not an issue, please retest and confirm,'

c) 'still an issue,' additional categorization added. 


So i started to process these cases myself.  And by process i mean read.  A couple, and only a couple of the close ones i grabbed and asked for re-test instead because i wasn't sure and most of the retest ones i assigned to a particular resource.  It was all good.  Fast forward again, this time until i've processed over fifty of the things and i go to find out what's up.  She tells me what she's doing and i think it's a good idea and i resign myself to some extra work for the next few days.  When it hit a 100 or so i realized that although i was seeing about a 25% rate of ones marked for closing i was never actually seeing any bugs being closed.  


So i went and asked the Dev Manager if she was closing any, to which her response was that she wasn't because Dev's don't close bugs, QA should.  Which i think is a great response and really how it should be.  I objected to the use of the term in the bug 'closing the bug,' and she agreed.  We discussed and since i review all bugs, even those that have been closed, and since she had some 750 of them to process for this short period she was going to close them as well and rather than my having to read the email notification and then open the bug and update it she would just do that part.   


This sounded like a good, safe solution to me.  Until she emailed me 15 minutes later saying that she didn't have the rights to close bugs.  


Here's where proper process bit me in the ass.  It's pretty standard to have this process as well.  It's common to only allow QA's to close issues so that you don't have the devs making decisions without knowing the full story.  It's good process.  I don't argue this fact at all.  However, when i went home that friday i still had a queue of about 100 to go through, when i came back in monday, i had 385, the dev manager worked until 8:30 PM on a friday night going through the backlog.  


Here's where the DDoS (denial of service) title of the blog entry comes in.  All last week i tried to find time to process this stack but all i had was this ever-increasing list of notifications to process because she was finding more time that i could.  When you have 400 notification emails most of them with the same sender name beside them, it becomes difficult to see the new updates from other team members.   Each scrum that week i mocked the dev manager for her DDoS attack, and each time she apologized.  I indicated it was ok but that i was still going to mock her for the attack.   It was my method of releasing the annoyance of the task.  


Because, everything else said, it's still an important task.  Two people processing all the cases seems from some standpoints to be silly but in the end, clearing out the backlog is great.  It's going to provide excellent information for the new design work and i'm learning a ton about the system as we go.  And i've caught a dozen or so that i wasn't happy with the action taken and altered it to be a little safer. 


Sometimes process hurts. 
If it's good process though, it always helps. 


When i left this friday i still had 100 in the queue.  But i had started sorting and ensuring i was going through the new ones first every day. And she's through all 750 now, so 100 is all i should have left. 

Thursday, June 14, 2012

Hiring hiring hiring

Hiring is on my mind lately, not the least because i have a couple of spots that i'm looking to fill.  This morning the twitterverse handed me a couple of articles that made me want to talk about hiring a little bit.

The articles in question are "Why you should hire like a rock band."  and "The case for hiring 'under-qualified' employees,"  You can read them as you will but essentially the first talks about hiring for culture and the second talks about hiring for hunger.  Both of these articles struck a similar chord to me, both have the same goal in the end.  You need to hire people that will fit your organization more than you need to hire the skills that your headcount requires.

Rating fit above skill is the hard part for a lot of people to swallow.  This might be in part because it's a lot more nebulous and therefore is more difficult to measure.  It's not even all that easy to adequately assess the technical skills of a candidate but at least you're capable of measuring something and having some idea about their qualifications.  Anyone who objects to this statement hasn't really tried to write a test or set of questions to give a high level of confidence of the actual practical appliable skills of a candidate and then matched them to the results down the road.

It's kind of the holy grail.  A test that shows you that they'll be able to do the work that you put in front of them at the level that you desire.  Either they test well and implement poorly or test poorly but might implement well, but you'll never know cause you didn't hire them based upon the test.

On the other hand, if you start by attempting to match for culture and personality fit with skills secondary (but not unimportant) then you stand a much better chance of getting where you're going.  If you can figure out that a person is someone who wants to achieve, will work hard, will mesh with your team pretty well and is capable of achieving shared vision with your organization then you should be able to train them to whatever level you need them to occupy.  Granted, the closer you can get to the skills you want/need will shorten this amount of time.

The next question might be to ask how you assess this fit.   It's not easy.  When i go into an interview i have a few questions written down, about 20, that i like to get ask.  Not really necessarily because i like to know that they have the right answer to the question but rather how they tackle the question and the process they use to achieve an answer and then what they come up with.  One of my favourites was discussed in an earlier post about usability.   The two-parter asking the candidate both, 'who in their experience owns usability' and 'who should own usability.'  There isn't a correct answer to this question, there's barely even a wrong answer if you can give me reasoning that makes me believe that you can think coherently about things.  But even in the way that you deal with left field questions will help me to figure out if you're going to fit in.  do you have a good attitude about it, tackle it positively, don't fill your answer with too much bullshit etc.  I know there's a lot of science behind interview process but in the end the assessor, or interviewer, has to figure out the fit thing on their own personal level.

Here's one of the good things about bringing in someone to interview who's not really qualified for a job; they don't hold back.  Generally they have nothing to lose, so they really put themselves out there.  there will be some that are too nervous to make that work but that's the thing with someone who's not qualified, if they can't shine in the interview you really don't want them.  In a lot of ways the decision becomes easier because you only care if they really shine.  In tech, sometimes you have to consider people who are fully qualified but have quietness issues or smell weird or whatever because you're hiring for an odd skill set and your price range is fixed.  That doesn't work with the under-qualified.  If they don't impress the pants off you in the interview you know that they're not going to have the go-gettum-ness to learn the skills to do the job.

I've had a lot of success in hiring for fit and ability to learn for Jr positions.  Especially in QA.  QA's a tough one for finding qualified jr's though.  Generally they only stay a Jr for a couple of years and they won't really be looking during their first job for something else until it's time to move up.  So you have a choice, you can hire fresh out of training, and frankly i've never ever been particularly impressed with the candidates i've seen coming out trained for QA or you can hire someone with an obvious aptitude that you can train.  a person who's shown that they want and need to learn things can not only learn the skills they can learn to adapt to your culture faster, easier, better.

And here's the clincher; I'm not just talking about social/work culture.  I'm talking about culture of quality.  You get to take a receptive, clean (so to speak) mind and imbue them with your quality goals and concepts.  it's a very powerful way to help your team grow in quality the way that fits your quality vision.  Top down to the bottom and then bottom back up.  Having people who are ready, willing and able to achieve shared vision with your rapidly is very powerful and can't be discounted.

In summary, no matter your skill needs, always try to hire for fit but don't discount the under-qualified because longer-term they might be the best choice for the job.


Saturday, June 9, 2012

Hiding in the Corner

So i'm working a new job now, with a new team.  I've been here just over 3 months at this point and while i have a good handle on the culture here, i'm still learning some of the ins and outs. 


This week something happened that demonstrated to me that there are things about the culture that are impacting our ability to be successful and upon noticing these i found myself giving my first lecture to my team.  


Everyone knows that tech folks tend to be a little more socially awkward, on average, than your standard human being.  But that said they do cross a spectrum of personalities and trends for interpersonal communication.  But as is true with any group these personalities come together, combine with the traditions of the organization and form your culture.  The culture of the technology folks at this place trends towards quiet and insular.  My team gets along with each other pretty well on a quiet respectful basis and interacts with the other eng teams similarly.  The other eng teams kind of fit the same description.  It's not that we don't laugh when we're together but it's more that laughing only happens when we're together and not with others at the company. 


This description does not fit the other groups at the company.  As you might expect sales, marketing and client services are a lot more social, interrelate, participate and etc.  That's pretty natural. 


Well fast forward to this past Wednesday where the office admin sent out a couple of emails asking the employees to come in on Thursday wearing red and white or wearing something that says Canada on it.  The CEO became a Canadian Citizen on Wednesday and they wanted to have a little informal surprise celebration in front of his office.  


So the next day i come in, wearing a bright red t-shirt and a white over-shirt.  I enter through the back way so that if the boss is there he'll not see me and start to have suspicions.  I notice that not much of engineering is wearing red or white but i naively assume that at least a couple of my guys would have done something.   I see the first guy and i mock him a bit.  I feel that mockery is a very strong tool for behaviour modification, especially when it's an informal change that you're looking for.   Not too long after that i'm in a meeting room having my morning scrum with my team and not a single member of my team in that room is wearing red or white.  More like, their clothes seem to have been chosen for the opposite because there's not even any random bits of white on anyone's clothes. 


I think about doing a little good natured chiding but then i decide that this simply isn't good enough, that there's a really important point here that they are missing.  So we laugh a bit and then i go into lecture mode. 


There are two reasons why not conforming to work events like this are bad.  We've already talked about how engineering is a little insular in our company.  This is causing some problems.   At least due in part to the fact that the teams in engineering haven't really been building any relationships with the other teams at the company.  This has made it easier for other teams to play the finger pointing blame game rather than the 'let's be a team and figure this out' game.  Relationships are one of the key things that help reduce the blame game.  It's way harder to point finger's when your brain is going, 'Frank's a good guy, he wouldn't do anything on purpose to cause this problem.'   By standing back and not participating in these events it's encouraging the 'us' and 'them' mentality.  There's the people who are cool and interesting and care enough to be involved and the 'weirdos in the corner' who don't. 


The second reason is a little more self serving.  The CEO's office is pretty much in between our two groups.  So i asked the team what they thought he would think when he steps out of his office and looks to the right and sees a sea of white and blue and then looks to the left and sees an ocean of not even remotely red and white?  And better yet, what if he looked to the left and saw a little island of red and white in the blue and grey group and knew that that island was QA.  I'm not saying he'd rain cash down on us or anything but it's really important to stay both in the mind of of your CEO and while in that mind to be thought of positively.


Then my boss showed up not wearing a lick of the right colours...sigh. 
You don't have to play politics to be a good manager but you have to understand relationships, what they do and what they mean.  


I think the team got it. 
Maybe. 

Wednesday, June 6, 2012

How Quality Tools Present Value

So during my lunches i'm studying the Certified Manager of Quality/Organization Excellence Handbook in order to hopefully take my test for my CMQ/OE certification in the future.  I'm still in the pretty early stages and it's going to take a while since i essentially dedicate 1/2 hour per day to it.  Today i was reading about Change Management in the Leadership section and I came to a conclusion that, while it can't be generalized over all Quality Tools, i think holds for a large number of them. 

The generalization is that these tools maximize their value mainly for the participants in the creating of the forms and not so much for after-the-fact consumers of them.   I came to this conclusion while looking at an Interrelationship Digraph.   The interrelationship digraph is a method of representing multiple elements of a process and capturing how they interrelate.  Below is an sample of one that i randomly found via google.


sample interrelationship digraph (random)

The thing is, a picture like this probably has some value to everyone who understands it but the value is going to be on different scales.  When i look at many of the tools that make up quality, like the DFMEA, or a Pareto diagram or this diagram the way to maximize the quality of your graph by far is to be one of the participants that are in the room while you're working together to produce the content.  When you sit in a chair and actively contribute to the analysis that produces the diagram you're not only part of the discussion that draws each of the shapes on the diagram you're likely also coming up with some of the ideas yourself.   There's simply no better way to learn and understand than to be involved in the creation of the idea. 

As with any model, it's the reduction of a large pool of contextual and factual information into a simpler form.  But for a person who reviews the document later, if they were in that room, their brain still retains remnants of that context and can bring it back up.  To a person who wasn't in the room, even if they are highly involved in the subject matter, a diagram like the one viewed above loses a dimension.  I think that's a good way of looking at it, it really does flatten out to the 2 dimension you can capture on the page but for a person with a personal involvement to the creation, there's enough collateral information floating around in their thought processes that it really lifts up off the page to become multi-dimensional. 

In the example i've been using, the interrelationship digraph, in the text of my book, they showed how it was utillyzed to come to a number of conclusions about the best process to use in implementing a suggestion system.  As i read through the conclusions i realized that if you stepped away and tried to use the digraph itself to build your argument for the conclusion that it really didn't support it very well.  It pointed in the right direction, for sure, but it was only skeletal support at best.  However, by taking into account the user stories mentioned in the creation of the digraph, it really supported the conclusions well.  The book provided the context to bring the digraph into the extra dimension for the reader.  

So what am i trying to tell you?  Am i trying to tell you that you shouldn't review the outputs of Quality Tool investigations?  Certainly not.  What i'm trying to instill in people, managers especially, is that the higher the participation you put in utilizing these tools does not only result in a higher value for the output of the tool but it also results in a much higher personal value.   You will never get the value as a consumer of this output as a non-participant as you would for being there and contributing.   Don't sluff off those meetings because they're boring and your team can handle them...by being a member, not only do you bring value to the process but you bring value to yourself. 

Monday, June 4, 2012

Vanilla and Creme - the worldwide conspiracy

How's that for a eye-catching title?


I've been looking for a way in my brain to tie this post to Quality directly so that it fits my blog theme centrally but i'm having trouble finding that connection.  It may be that by the time i have finished writing it that i have found a way to tie the two concepts tightly together but then again i may not be able to.   


However i definitely do have a connection to one of my sub-themes. One of the future articles that i'm going to write is around my thoughts to the question, 'what makes a good software tester.'  This article that you're now  reading is really an exemplary example of the concept of  'down the rabbit hole.'   One of the core attributes to a good tester is being observant enough to spot something while testing, whether functional, integration, regression or whatever, that is just off enough to tweak something in the brain that says, 'that's not quite right.'  And then to be curious enough to spend effort and time digging into whatever is off until you have a documented reproducible bug.   It's a combination of both of these things observant and curious.  Without the two you don't end up with the all important reproducible documented bug.  


What can all of this possibly have to do with Vanilla, Creme and worldwide conspiracy you might add?  Well, as with all rabbit hole excursions, it's a little bit convoluted. 


It kind of starts yesterday when the wife and i went car shopping.  Not that the process of arriving at car shopping was even remotely simple but not really important here.  We had settled on a few things and ended up being a 2011 Kia Soul in the colour Vanilla Shake.  Vanilla shake is a creamy beige colour.  It was a fairly stressful day, giving up my wife's first grown-up car as a trade in and spending a heap of money on a new one.  As a result of this i came up with a little trick to maybe help my wife relate to the new car a little faster.  We have friends that name their cars, we could name ours.   A brilliant idea.  It would help her identify with the car faster as well as bringing the whole car buying concept into the realm of a little approachable at a cognizable level (could that really be a word?).   


[aside - Ok, we've just hit our second blog sub-theme here, management and what makes a good manager.  Knowing people, how they relate, accept, process and deal with change makes a good manager.  A good manager generally has some pretty strong knowledge of change management and some of the tricks that help people transform with less stress.  Which probably also highlights the quality concept of quality wholeness (my just made up term). Or, to really embrace Quality and make it successful in your work life, you need to make it part of your whole life.  The same is not untrue of your other skills. /aside]


So my next step was to start her off with some suggestions. Nothing obviously right came to mind but i thought maybe i could look up some words for vanilla or cream in other languages and one of them might sound cool.   i started off by going into google translator, throwing vanilla and cream in there and picking other languages to look at them.  As i hit the languages i already sort of knew myself like french or Spanish i wasn't so surprised that the words were essentially the same with a little bit different pronunciation or accent.  i started to go wider afoot and learned a limitation of google translate (in this case probably a targeted feature).  If i ask for english to be translated into Russian, the response i get back is in the Cyrillic alphabet.  This held true for pretty much ever non-latin character language.  It held the same for babel fish and microsoft translate. 


But by this point i had already looked at over a dozen languages and for each and every one vanilla and cream were the same.  Things only started to get weird when i asked one of my employees from the middle east what the words were in Farsi - um...same thing.    By this time translating vanilla and cream had taken on a life of its own and the naming thing didn't matter at all (see rabbit hole).  A side question had come up and some very fast research showed me that vanilla had been brought back to europe from Mexico and was named by the Spanish.  This helped resolve the vanilla part of the puzzle.  The Spanish named it from a spanish root and they were the route into the rest of the world for the product.  A standard name for it make sense, but cream?  Cream is used by everyone that milks cows.  How could the word be the same?  What kind of weird conspiracy could be at work here?


I wandered a little farther afield, my Russian employee - same thing.  Things got really weird when i went to the Ethiopian guy working in our CS group.  Same freakin' words.  there were few more options but i sat down and started writing out an email with this entire story to my wife.  i was nearing a tizzy with how completely absurd things were.  It simply made no sense. 
As i was writing my email, however, everything settled out to a much more standard form of normalcy. 


My Russian employee came back to me and said that she had made a mistake.  Cream, as in the product that was the fat off the top of the milk is actually known as splipky (my own spelling) and that creme is their word for whipped cream.  That makes much more sense for the randomized fashion that language transforms in our world.  Apparently whipped cream wasn't much of a product in Russia until French desserts came into the picture, bringing their word with it.  That was good enough for me and the mystery, although i am sure there is more digging to be done.  One of the important skills as you become more senior in testing is to learn the law of diminishing returns with respect to rabbit holes.  This one had been interesting and exciting but work has to be done. 


[aside - i did come up with a few relationships between this story and my core blog themes so that's cool.  not the least of which are the thoughts flowing around through my head of the different paths for quality that these words have taken through our language.  Vanilla has managed to travel through our languages essentially intact but cream is a completely different story.  Language will never ever be a reasonable example of Quality, but maybe what it is an reasonable example of why Quality isn't always the only end goal. Cause language is a cool mystery to play with all in its own.  There's usually a reason for it's insanity, you just have to find it and that is the fun part. /aside]


To end my little story, my email about the rabbit hole had the desired effect and we are talking names and some calming down is occurring.  Ironically enough, while we haven't chosen a name yet, on her own, my wife threw out the concept that while she wasn't sure why, bunny seemed like an oddly apt name for the car.  i'm not, however, driving down it down a rabbit hole. 



Thursday, May 31, 2012

Quality in the music industry? Huh, where?

Back to my history.  When BC Rail was sold to CN i was given the option of being offered a job with CN and moving to Montreal or getting a severance package.  There were a number of things against my going to montreal, for one the IT dept with CN was 600 people, for another i had a new girlfriend here that i really liked, montreal has actual winters and the worst thing was that CN was a hegemony of evil to work for.   It's ok to work for evil and it's ok to work for a hegemony, but never both at the same time.

so i dodged that bullet and took the severance.  turns out it was the very right thing to do at the time.  i mean i had a 8 years into QA at the time, was a lead, did some pretty solid BA work and i was pretty sure i could get another job but i was a little afraid of it all.  But as with most things in IT, to really move up, you generally have to move on.

I took my severance and had a beautiful summer of no pants.  it was planned, i ended work at the start of the May and i told myself i wasn't even allowed to start looking for something else until sept.  and i didn't.  best. summer. ever.  i learned that as long as you plan and do one thing each and every day, your relaxed carefree time will seem like a very real, no wasted, vacation.

when i started looking again i had two decided paths.  I was looking for QA lead or manager work or i was looking for intermediate BA work.   I think at that point my passion was a little more focused on becoming a solid BA.  I felt that i had very solid grounding in the QA world and what i needed was a broader experience base in the BA world.  i had nibbles and interviews in both paradigms and then after a month and a half of job search i took a QA-BA role at a start-up that evolved into a Product Manager role, still responsible for all things QA and BA at the small company.

The start-up company was making a kiosk product that would allow the user to browse the million song music catalogue, start a collection and then burn it to CD as they waited.  there was a goal to do MP3 player loads as well but that was a phase 2 product that never actually got released.

There were a few wonderful evolutionary parts for me at this company:


  • Wiki - it was my first introduction to the usage of a wiki for documentation.  it wasn't the best thing ever for my BA documentation but it was an innovative solution for test cases, plans and results.  I loved the wiki for that.  the ability to organize and maintain this information was quite powerful.  when i went to my next job it was one of my first questions about tools to be used. 
  • Standardization of process and documentation - going into a startup with a clean slate of process and documentation allowed me to rethink all of the process and documents that i'd put in place for BC Rail and give it a fresh shake.   having standardized templates that could from the start encapsulate what i'd learned in my previous roles was superb. 
  • Usability - The difference between the usability expected for a retail facing kiosk product was so different than the usability concerns for the in-house used industrial/transportation products that i had no choice but to really start building a wider perspective of usability and how it fits into the development process.  I felt i really matured in this arena there. 
  • Self-motivation - as start-ups go, we were very loosely monitored and controlled.   i was responsible for my two spheres of influence and had to get the other team members to interact with my spheres productively.   
The biggest thing about the job however is how insane dealing with music labels and their data is.  They have a million draconian rules, a million different data types/structures, hundreds of rules about updates, take-downs, enable dates and etc that are so complicated they have immense amounts of trouble holding to them themselves.  More than anyplace else i learned in this job that complexity is the enemy of quality.  If you need to be complex, then you need to figure out ways to spend the time and effort to maintain quality.  

With the music labels there is simply no way that the amount of complexity that has evolved is even remotely necessary.  It's a track, here's it's price, here's when you can sell it, here's when you can't.  move on.  but no.  the single most amount of time in the company was not spent developing a system that could handle all of this complexity, rather it was negotiating a contract with the labels.  they have hundreds of such contracts, how do they maintain any semblance of tracking or quality when they can't even standardize on how they deliver their core business?

In the end there were endless problems with the content and threat letters on a regular basis as the interpretation of this rule or how this data was handled incorrectly as far as a particular employee of that label was concerned.  Now multiply that by the fact that we had 5 major labels to contend with.  Not partner with, not deal with, contend with. 

My new rule of thumb is anything where the contract takes longer to negotiate than it takes to develop the software, run like hell. 

2.5 years later the funding dried up, we had  product in about 100 locations that were making some money but the profit margins in music are very minuscule and start-up blew up. 

I certainly learned a lot about a lot of things.  I hadn't dealt with the concept of retail before and it helped me think in some pretty different ways.  The team i worked with was intelligent, young, interested and fun.  Above all it was fun.  We worked in an excellent part of town, Granville Island, in a hundred year old dock warehouse.  Lunch every day at the market.  Very casual atmosphere.  Dart breaks twice a day.  Long hours.  Shorts and the dog whenever i wanted.  Start-ups are great in a lot of ways.   There's never even the concept of 'that's not my job' because everything that needs to get done needs to get done by the people available. 

As rebound jobs go...it was a good one. 

Tuesday, May 29, 2012

Quality is a Forever Quest


Need a reason to ALWAYS strive for quality and never give up?  my chair has been mildy uncomfortable since i took this job, i fiddled some but never achieved happiness and just decided the chair couldn't be altered in that way.  i resigned myself to always sort feeling like i was going to slide forwards off the seat, at least until  found a new and better chair. 


today i found that a lever worked differentely than i'd assumed before and in two seconds the amount of comfort possible from this site changed drastically.  


I count these 3 months of relatively unfomfortable seating as my fault. 

Sunday, May 27, 2012

Own your embarassment

So this past week something rather amusing happened to me.

My company has an attachment to this management training consulting type company.  The lead guy for this company, a rather amusing guy who can categorically be called a wingnut, gives seminars on some management topic or another as part of his business.  As part of our attachment, when they sound topical we bring him in to present them to our managers. 


This month he was giving a talk on how to run efficient useful meetings. Well there ain't no one anywhere who can't use some help in that regard and as such we brought him in.  It was a well attended meeting as well, there were over 20 people crammed into our main boardroom. Which had the 10 seats around the boardroom table and then something like 10 or 15 more sitting around against the wall.  They brought in sandwiches and drinks and we worked (in quotes work should be) through lunch and another hour too. 


As we ate our lunch he proceeded to give us a talk about meetings.  His presentations are very heavily injected with anecdotes from his own personal life, about his wife, his daughters and just about everything else.  He's German originally and has a very in-your-face way about him.  He is very much a hoot to watch and listen to.  A couple of us in the group, myself included because that's the type of people that we are like to give him a bit of trouble but he's a good sport and gives it right back. 


There are group exercises where he stops and has us think up some answers to questions about points he's either just made, wants to make again or is about to make.  he is a pretty good presenter/trainer.  Pretty much any answer ever given him is wrong because he has a curious method of answering his own questions in a way that make you think that you've answered a slightly different question than he did but even that leads to information trading. 


So due to the very intelligent fact that i had another meeting in the boardroom just before the seminar i got a seat, not only at the table but at the head of the table.  he's at the other end in front of a screen presenting.  Before we start he kind of makes a joke about how imposing my straight on look at him is but we laugh it off.  


The seminar goes well. i enjoy it, i participate and so do many others.  Especially the group right behind me that includes the CEO and a couple of directors.  So fast forward a bit, to the last 10 minutes of the presentation.  He's wrapping up and giving one of his longer speeches sailing through a bunch of bullets that kind of recap his ideas.  So i've uh been at meetings for 4 hours straight at this point, haven't been out of that chair in 3 hours and have eaten a higher carb lunch than i'm normally allowed.  During his speech my eyes close.  


I'll fully admit it. My eyes closed.  shut. like midnight.  but i wasn't' asleep...yet.  In fact, truth be told, this actually happened twice in the last 15 minutes of the presentation.  Only, he missed it the first time.  And i didn't fall asleep, i drifted a bit.  Second time though...he didn't miss it. 


He saw it.  As soon as his voice stopped my eyes popped open. i could have told you the last two sentences he'd just read but that didn't really matter.  he made eye contact with me and he tried to recover.  Tried really hard to recover.  He failed.  Then he started talking to me, but in a sort of vague esoteric kind of way that didn't give people context. 


"If only you hadn't been directly in front of me...if you'd been off the side i could have made it."
"Going right along doing great and then i see you"
"i couldn't recover...you were one and i couldn't...


Now everyone else on the room except for him and i are completely confused.  They have no clue.  Slowly though, especially when he mimics a person shutting their eyes and sort of slumping over in sleep (that second part never did happen mind you) the crowd figured out what he was talking about.  But they made an assumption.  He kept looking directly at me as he talked but what they saw him to be looking at was the CEO sitting directly behind me.  


The entire room is starting to believe that the CEO had been caught sleeping.  It was very funny for the room, although they weren't super sure how to take it.  the CEO was completely confused though.  he was paying proper attention (probably, how could i tell, he was behind me).  I could find the humour in the room begin to build and decided that i'd best defuse it before the poor CEO had to carry this on him in some way (not to mention permanent damage or mockery, that i was the cause of). 


so i spoke up loud and clear that it was me he was talking to, that my eyes had closed and it derailed him.  and it worked. owning up to the eye closure let him say a couple of more things, let the crowd smile and laugh, at me, and we moved on. 


i don't embarrass easily, i still got what i needed to out of the meeting and everyone had some good laughs.  and in fact, 10 minutes later the HR person who brings him came to my desk and said that he'd asked to be brought in to me to apologize for putting me on the spot like that but she'd assured him that i had such a good sense of humour that it would be fine.   which it was, and i was.  And i love that in 3 months a person i've talked to a dozen times got that right about me. 


The next day, in my scrum with my team i used the little story about what happened as a bonding moment with my team.  One of the things i try to watch with my teams is not to seem to, um, high functioning or unapproachable.  I really prefer a management style of authoritatively approachable.   I like to know more about what's going on than any member of my team, i like to be able to build firm opinions fast enough that there's never any doubt what I think the right course of action is.  But i also like to be approachable so such things can be discussed.  


My relationship with this team is new.  Having this laugh, owning the embarrassment without showing that i believe it degrades from my respect at all, this is part of that.   For the most part it works really well for me.  Have to watch though, you become too much of a clown and the respect goes out the window.  


One positive...i think the only manager at my company who missed the meeting...my manager.