On Passion, or Be Careful What You Wish For

Recently I was reminded of something that was said several years ago.

The Several Years Ago part: In the middle of a project that was simply not going well, in fact, it was a bit of a train-wreck.  Nah, not a bit.  It was a complete and total train-wreck.  Pick something that would go wrong and it did.  In spades.

Yours truly was QA Lead and was overwhelmed.  A "target rich environment" does not begin to describe what was going on.  Massive effort, huge amounts of overtime to try and control the damage, stop the flooding, stop the bleeding, well, pick a metaphor.

Fact was, the testers were putting in a lot of effort and, frankly not many others were.

So, sitting having an adult beverage, or several, with one of the development managers on the project, he looked at me and said, "Pete, you have a real passion for what you do.  You're better at testing and understand software better than an awful lot of people I've worked with.  You are really passionate about what you do.  That is great.  Be careful though.  If you're too passionate you can burn out."

That struck me as odd, at the time anyway.  How can one be "too passionate"?  Is it possible that one can be too involved? Too close to the work? Too passionate?

After all, we have a lot to do and scads of work and... whoa.  Why is it that some folks are diving in and going full bore and others are, well, sliding by and doing what seems to be the minimum.  Why is it that some people just, well, not as deeply into making the project work as others?

The Reminder part:  So, talking with another tester I know, she was muttering about a project where the developers just did not seem to care, about deadlines, quality of the project, impact on, well, performance reviews, raises, bonuses, and the like.  She looked at me and said "Its like they just don't care!" 

SO,  why is it that some people just, well, are not as deeply into making the project work as others?  I don't know.  Maybe it depends on what is expected, or what the normal approach is for the shop or company or, whatever.  Maybe it depends on the nature of the project leadership.  Are people being managed or controlled, compelled.

While what is often called craftsmanship is something that seems hard to find.these days, in some places (maybe many places, I don't know) I remember hearing many people speak passionately about being, well, passionate - as a tester, as a developer, or as whatever it is that each one of us is.

I got to thinking some more Friday night and generally over the weekend about this.

When looking for places where everyone is passionate about their work, what does that look like?  How do you know when you find it?  I used to think I knew.  I've worked at places where the majority of people were very passionate about what they did.  They wrapped much of their view of their self-worth into their work - so if the project was a success, their efforts were "worth it."

Then, I started wondering what a project that was a success looked like.  I suspect it rather depends on the software development group's target audience.  Are the people who will be using the results of your work all working for the company you are working for?  If so, "market" is a hard concept - unless the results of their work, with the new system, improves so much that the company as a whole performs better because of the many long hours and weekends in the office and ... yeah, you get it.

If the company makes software that will be bought by other companies for use in their business, the combination of sales, licenses, recurring/renewal of contracts around the software and the like will be one measure of how your efforts contributed to a successful project.  Likewise, the customer-companies being able to conduct their business better, more efficiently, is another measure of the success of the project.

And so, what about the other signs?  What about the places where people are not passionate about their work.  What do they look like?

That's easier to find examples...

People use "process" as an excuse to not do something.  "I'd love to do this, but I can't do X until D, F and L are in place.  That is what the process is."  (Whether its true or not does not seem to matter.)

People lock into rituals and stay there.  Arrive 5 minutes after the "start time"; start laptop/desk-top computer; get coffee; drink coffee, eat breakfast; sign on to network; get more coffee; sign on to email (personal)... etc., leave 10 minutes before official "stop time" to "avoid the rush".  Use the, "well, I work a lot of extra hours from home and over the weekend" reasoning.  (Oh, laptop is still in the dock on the desk as they are heading home.)


The appearance of work counts more than actually doing work.  Lots of reports being filed, status reports, progress reports, papers being shuffled up to leads and supervisors and managers and, of course, process management.  This is different than using process as an excuse to not do something.  This is taking the literal process and ignoring the intent.

Heroic Behavior is rewarded  more than steady solid work.  Now, I'm not down on heroes.  I've been in that role, and was recently called a hero as well.  I mean the false-heroes, the ones who dawdle and obfuscate and put things off and delay, and miss interim deadlines and miss delivery deadlines - partly by using the first three behaviors - and then work massive hours the last week of a project to pull things together and deliver something - and let everyone know how hard they worked. to "make this happen."

I bet you can come up with a bunch of other examples.  I stopped there simply because, well, I did.


Now, What to Do?  If you find yourself working at a shop or department or company that you find described above - where it seems you are the only one who cares - what do you do about it?  Ask yourself, "Has it always been this way?"  Maybe something changed recently, or not so recently.  Maybe the change has been gradual.

Sometimes, it takes you being the one to be burned by this behavior to notice it.  Sometimes it has been going on with some people and not others and it is your turn to work with these people and - what a mess.

You can say "Maybe they learned their lesson from this and the next time will be better."

Don't bet on it.  There is likely some other reward system in play that they value more than the rewards workmanship, craftsmanship and passion for doing good quality work can provide.  Ironically, they may get rewarded from their supervisors for being heroes (even though they created the situation that needed heroes) or "preserving the process" or, whatever.

So, back to what to do.

Your choices are limited.


You can try to "change the culture."  This is easier in small companies than in large Borg-like companies that grow by assimilating small companies into the Collective.  I know people who have tried to do this.  Some were successful; those dealing with the Borg Collective were less so.

You can try to "change the environment."  Here I include "process" as well as the nature and flow of the work and communication.  You can ask questions and field inquiries and take part in improvement task forces and, and, and... don't let the project slip.  I know people who have tried this - myself included.  It may work, you may feel more engaged and more aligned with improving the company.  At some point you may look back ans wonder what has been accomplished.

You can stop resisting - Accept it for what it is.  Turn off independent thought and go with the flow.  Collect the paycheck, take the "motivational development" courses and continue to collect the paycheck.

You nuclear option - Leave.  Go somewhere else.  That is what I did with the company in the first part of this post.  I packed it in.  I do not regret it.  My other options seemed so improbable.  I tried them - the engage thing, the culture change thing.  I could not bring myself to stop resisting.

Please, never select to stop resisting.  Never conform that much.  We are testers.  We can not be good testers if we stop questioning.  That is what is required of that option.

Improving Test Processes, Part IV, or The TPI Secret of Secrets

So far, I rambled about Improving Processes.  In Part I, I wrote about how we may recognize there's a problem, but may not be sure what the problem is.  In Part II, I wrote about the problem of introspection and how hard it can be to see outside ourselves and look at how we really are.  In Part III, I wrote about Don Quixote and the unattainable goal of  Process when the Charter and Mission are in disarray. 

The simple fact is, each of these things play a part in that which makes up Test Process Improvement. 

Now for the secret.  TPI is not the point.  TPI is not the goal. 

In the end, TPI doesn't really matter except as a means to the REAL goal. 

The REAL goal is this:  Better Value from your Testing Effort.

The thing is, most humans don't think in a clear fashion.  I know I don't think in a way that can be described as linear in any way, shape or form.  That is particularly true when I'm working on a problem.  If I DID I would long ago have stopped looking into something I was testing because it did not feel right, even though there was nothing on the surface to indicate there was a problem.  When I have one of those feelings, I sometimes will go over what I have for notes, look at the logs from the applications (not the nicely formatted versions, but the raw logs) or poke around in the database.  Sometimes its nothing.  Sometimes, I sit back and think "Well, look at that.  Where did that come from?"  (Actually, I sometimes say that out loud.)

That is the pay-off for me as a tester.  I found something with a strong likelihood of causing grief for the users/customers which will in turn cause grief for my company. 

I don't know how to describe that in a linear fashion.  I wish I did, I'd probably be able to make a pile of money from it and live comfortably for the rest of my life from the earnings.  The fact is, its too organic - organic in the sense that Jerry Weinberg used the term the first time I encountered it in this context (Becoming a Technical Leader) not in the Chemistry organic/carbon-based context. 

The Test Script (and its companion, the formal Test Process Document) is not the Test.  The Test is the part that is done by the M1-A1 Human Brain.  Using that most powerful tool is the key to gaining value from testing - or improving the value you are currently getting. 

You can have the best Process in the World of Software.  You can have the best Charter and Mission statements.  You can have the best tools money can buy.

Without encouraging your people to think when they are working, and rewarding them when they do it creatively and do it well, none of those other things matter.

Improving Processes, Part III, or, Why Don Quixote's Quest May Have Ended Better Than Yours Will

A few weeks ago, while looking for some other information, I stumbled across the power point slides of a conference session on Test Process Improvement that I decided was "not a good fit" for me.  Yeah, I walked out... about 10 minutes into it. 

The premise was "If you don't have a Process, you need one.  If you don't have a Process, you have Chaos and Chaos is bad."  Following the obligatory introduction, and some seven minutes of what appeared to be gratuitous assertions, I said, "Enough" and walked out.

Having a Process is not a silver bullet.  Simply having a Process will not magically fix your Chaotic environment.  If you are trying to impose Process on the organization wearing your "Tester" white hat or the plate mail of the Quality Paladin, good luck.  Most places where I've seen Chaos rule, its because someone with a lot of scrambled eggs on their hat likes it that way.  (I wonder how many metaphors I can pull into one paragraph?  Better quit there.)

However, if you have a Process and no one follows it, the question should be why not?  My previous blog posts (Part II and Part I of this thread) talked about how the "problem" might not be the real problem and how you need to seriously look at what you are doing before you can fix what might need fixing.

When you look long and hard and honestly at what you and your group is doing, when you find the places where what is done varies from what The Process says, you must determine why this difference exists. 

I suspect that it will boil down to a matter of relevance.  The official Process has no relevance to the reality of what actually is needed in those situations.  If it is a one-off, then there may be something that can be tweaked.  If it is a regular occurrence, then the value of The Process comes into question.  If it doesn't work, why pretend it does?  Why bother having it at all?

Granted, The Process may have been relevant at one time and things may have changed since it was introduced.  However, nothing is permanent.  Change is inevitable.  Even The Process may need to be updated from time to time. 

When you do, look to the Purpose your team is to fulfill.  Why do you exist?  What is your Charter?  What is your Mission?  Do you have a Mission?  I'll bet you do, even if you don't know what it is.

To start, look to what Management expects.  If a boss-type is telling you that the Test Process needs improvement, try talking with them.  Discuss with them what they believe needs to be improved or where the gaps are.  This may become the basis of the group's Charter. 

The Quest that you are expected to follow.

What are they seeing as "broken" that needs to be fixed?

If the gist is "there are too many defects being found by customers" ask if there are specific examples.  Anecdotal evidence can paint a compelling story, yet without specific examples, you may never be able to find hard facts  Is this a hunch or are there specific examples?  Are these defects, as in they should have been found in testing? 

Maybe these are aspects of the application that the customers expected to behave differently than they received?  If they are, why is that?  How can that be?  How can the expectations be so different than what you believed it would  be?  After all!  The Design and Requirements, that you based the tests on, matched perfectly!

Let us ask Dulcinea how these things can be so different than what they appear to be?

Improving Processes, Part II

O would some power the giftie gie us
to see ourselves as others see us.

 - Robert Burns, To a Louse

Right. So if you need that translated, Rabbie was saying this, in English: 

O would some power the gift to give us
to see ourselves as others see us.

There are a couple of things that are just hard to do for most people.  One, is to change our perspective and see what others see in us.  The really hard part is similar to that: to look at ourselves honestly, and see what we really are like. 

Any time that self examination comes into play, most folks will avoid it as much as possible.  We can tell wee little fibs and stories and justify actions by many interesting machinations.  Yet when we strip those aside, what are we left with?

That is the really hard part in any form of process improvement.  When we look at ourselves, as individuals or as a group, the challenge is to set aside what we wish we were doing or like to think we do, and focus on our true actions.

If our real processes and the official process don't match, we need to ask ourselves, "Why not?" 

Indeed, to see ourselves as we really are, or as others see us, can be an event that we don't want to face.  Without doing that, we can never improve.

Improving Processes and Other Stuff, Part 1

I've been teaching a lot of pipe band drumming workshops lately.  Well, "a lot" compared to the last two years anyway.  They can be hard, but generally are great fun.  By the time I realize how tired I am, I'm half way home - close enough where a cup of Tim Horton's coffee will get me home (yes, there are some in Michigan.)

So, this last session was a mix of absolute beginners and those that were a step or two beyond that.  They all play in the same band, or aspire to anyway, and so have a common bond between them.  Part of the intention of the workshop organizers is to not only teach the beginners, but teach the more advanced players how to teach. 

That actually is easier than it sounds, at least with drumming.  I get to present an idea, work on some exercises, see who is getting it and who isn't.  If it is a physical thing, there are other exercises to try.  If it is a mental thing or thought process thing, then I present the same basic idea another way - changing the context sometimes makes it easier. 

This last session we were working on triplets.  Cool things, those triplets.  They are also bread-and-butter stuff for pipe band drumming. The kind of thing where if you don't get them, your future as a pipe band drummer is quite limited.  One guy was having a bit of a hard time with them than the other students.  Mind you, these students ranged in age from 8 years to the mid-30's or so.  This particular fellow was doing alright, but was having an issue with getting his head around the idea of "three notes where normally there are two."

I handed out a bunch of candy/sweets to the other participants and asked this fellow to play the bit he was having a problem with.  Perfect.  So I asked him to do it again.  Perfect.  Third time was still perfect.  Hmmm... it does not look like its the actual "hard bit" thats the issue.  So I had him play the exercise from the beginning.  Trainwreck!  Had him slow things down and do it again - same thing.  The second time I noticed something in what he was doing.  As he got closer to the "hard part" his grip tensed up (he gripped his sticks harder) his muscles in his forearms tensed visibly - both bad things for drummers.  Try as he might, the sticks simply were not going to do what he wanted them to do.  When he jumped right into it, things worked fine.

If the first step to solving a problem is recognizing you have a problem, how do you know what the problem is?  In this poor fellow's case, he knew he had a problem and simply could not see what it was.  It wasn't the problem he thought he was having - it some something else entirely.  When he stayed relaxed throughout the line of the exercise, he played it flawlessly.  Problem solved.  But what was the problem? 

When it comes to process improvement for nearly anything, I try and apply the same approach:  There may be a problem, lets see what the symptoms are and see if we can isolate the problem - instead of whacking the symptoms or results of the problem. 

When looking at Test Process Improvement in particular, the problem that gets described is usually a symptom or list of symptoms - not the actual problem.  We can stomp on symptoms one at a time, without really addressing the crux if the problem.  That will continue to churn and bubble and fester until something else breaks. 

The "problems" presented usually are presented in a handfull of ways:

• Testing is taking too long;
• Testing costs too much;
• Too many defects are being found by customers.

Of course, there are other variations, but what I have seen have usually falls into one (or more) of those complaints.

When I was younger and not as diplomatic as I am today, my reaction to each of those points generally ran something like "Compared to what?"  Now, in my more mellow state and place of being, I only think that.  Sometimes loudly, but what comes out of the mouth runs something like, "Can you explain what you mean by 'too long' so I can understand better what you expect?  An awful lot of the time our original estimates on test effort or duration are based on the understanding of what the project will entail at the time the estimates are made.  As the project develops, we learn more and that will impact both the revised effort estimates and the actual duration.  What we are doing is based on the instructions given to us and the mandates for what critical processes must be validated.  Perhaps this needs to be reconsidered."

So, I guess that's a long-winded version of "Compared to what?" but it tends to go over a bit better. 

What I do wonder, however, when a boss-type says something like those statements, is "Are those symptoms or problems?"  Are we running over timelines and cost estimates because of other things than lousy estimates?  Are "due dates" being missed because of testing?  Are there a flurry of defects keeping customers from using the new release? 

Is there something else going on and these are perceptions of problems, rarther than symptoms of problems?