Yesterday was the beginning of the Australian fiscal year 2009.  I had set up 3 meetings with current customers, 2 of them requested I meet with them, one of them I requested.  3 completely different companies, 3 face to face conversations with 3 different approaches to Program Management.    My  decade of  history as a Test Lead for Microsoft and now the following decade  Managing Director of a Software Testing company, I do get the audiences I want.  I think at first, before they know me its a sense of “awe” for them to Meet someone who worked at Microsoft back in “the day” .. during the high points of the great Database wars between DB4, Borland, Foxpro and Access.  That’s whats on my resume, so I think that’s where the initial intrigue starts.  Or, this is  what I like imagining.  After they meet me, we’ll, I’m just another Test Manager on the rampage.

It is a difficult “face to face” for a PM to sit across the table from me next to his CEO (the guy who funds the software project) or his CFO.  Its the CEO, CIO or  CFO that I speak to usually, its their money that is being wasted on dodgy software development practices.

I have a pet peave of this IT industry, who the HELL said its o.k. to consistently exceed the IT budget by twice its original estimates, consistently? Try pulling that in any other industry and see how long you keep your job.

Who decided that the “end users” and ‘testers” were to show up at the half way point of code complete festivities  and just shovel the crap behind the elephant parading developers  down the street?  I have a Pet peave all right, and on a highly intense day, following a breakdown like I have just had, I really don’t care who gets offended in my toe to toe face off of defect detection verses defect prevention.

They really don’t see it coming.  An IT project Program Manager  is the head of the project, they are wielding millions of dollars of their companies money into the environments, software, tools and people.   Often they seem to get promoted to this podium of superiority because they are very smart, very experienced in the technology, very strong minded and genuinely care very much about the technology, the results and their company they champion.  I can assure you, in my 20 year history, I’ve never met a PM that was promoted because he/she was experienced in software testing.

Testing is a stigmatized industry outside of Microsoft, possibliy even inside Microsoft, but not in the language group that raised me.  The language teams of the 90′s were where I learned how to partner with developers, peers. I guess because we were also developers testing the language of basic, fortan, c++.. testers for these projects were respected as peers of the very developers who created these languages.  I knew no other way to be with a PM, Developer or tester.. Respect, peers, collaboration and excellent planning were my educational years growing up as a tester. We were trusted in our roles as the experts, and nobody ever tried to tell us how to plan, organize and execute our testing.. OH HOW THAT is NOT SO in the real world. OH HOW that infuriates me!

Evidently, the rest of the IT industry was not raised this way around testers.  On these projects outside Microsoft, testers are an ‘after thought’ in planning, and usually not technically  smart like a developer.  Just my observation, nobody would ever say to me. “Well, your just not as smart as me technically.”  I can read PM and Developer body language but I can never seem to read CEO body language, I need more practice at that.

The PM across the table  from me is very relaxed, slouched in a chair.  He just doesn’t see whats coming his way. He is too relaxed for someone who has wasted hundreds of thousands of dollars in building  dodgy technology poorly.  How can they be so unsuspecting of what I’m there for?

And I’m definitely not as smart technically, and I and my team have learned to use that to our advantage on projects.  Here’s what that looks like:

Me:   “I don’t understand the technology design, can you explain it?”.

Developer: <roll eyes, looks at watch and say’s> “blah, blah, blah…blah, blah, blah… its time for lunch”.

Me: “You can’t explain it so I can understand it?  You cannot explain how the business will use this?  You are going to start coding tomorrow on something you cannot explain, diagram or align to the business’s requirement?”

Developer: “aah, well, I’ll think about it over lunch”.

Me: <Smiling> “Great, I’ll be here at the white board with my sandwich waiting”.

Bill Gate’s taught me this technique, although he was sitting at the top of the food chain, I’m sitting at the bottom, but it still works.

If you cannot explain it to me, who has no background, no research, no concept of the technology, YOU do not get to build it!  You do NOT get to waste this customers money on a hypothetical, let me code for 3 weeks and I’ll show you hunch!.  Go back to your cave and your dictionaries and learn how to explain in common terms what you are going to build so your tester can understand the technology and the business implications and plan how we are going to test it.

Here I sit with a ” train wreck”  PM on the first day of the fiscal year.  Its an important week in Australia, the budgets are all reset for the year and with all those extra zero’s in the budget comes a whole lot of pompus excitement on how to spend it.  Every development team is at the starting gate with their prancing developers and jockey PM’s busting to get out and start development on the next round of new feature development.

This “Train Wreck” Pm, he’s already messed up his loyal companies budget by 3 months over the schedule. He was raised in the “testers are hired to detect” world.  He has no idea my take on quality is  “prevent”.  He wants me to explain to him the cost value of changing the tools, procedures and approach to testing.  He prefers we use the Microsoft TFS testing scripts instead of the  TFS work item templates my team has attempted to implement.  What a mistake he just made, he attempted to demonstrate he knows more about Test Planning than I do?  I’m thinking, is that what you want your CFO to see?  Ok, let’s go there.  I’m smiling.  I let him ramble on for 5 minutes about his preference for how we do the testing, that he’s open to change but nobody can explain to him the cost value to make the change.  Sitting next to me is the Senior Microsoft Program Manager I’ve worked with on world class projects over the last 6 years, he’s sitting quietly watching this customers PM walk right into the flames and he says nothing, he’s walked this walk and just sits quietly waiting for it.

I explained to train wreck PM, that Agile testing is about rapidly extracting in a query, what exact requirements were implemented, what exact defects were fixed, what risks, clarifications and dialog occurred between the developer, testers business, release team etc.  In 30 seconds, as a tester I should be able to hit a query in TFS and have this list of work items  generated,  and linked to every one of these items is the test case for the target release.  In the next 30 seconds I’ve re-prioritized my test plan, aligned it to the exact changes and integration points in the software and I can get to work testing.

Train Wreck Pm’s confident, superior management podium sitting  idea of Testing is the old school waterfall, stacks of word documents, encyclopedia “fixed order” lists of test cases to execute.  But he tries to disguise it as agile.  “use TFS test management scripts, both manual and automated, you can tick them off as you test”.   That’s a typical response to what a tester does, they tick off test cases as passed or failed.  I’m thinking,  keep talking, your ignorance about testing just amplifies the more he talks.

I replied “would you like ME to explain why we don’t use TFS test managment scripts?”  I said, “if you want to pay for 10 testers to sit here and go through every testcase in a fixed order list, you can fund that. its a FIXED list, it is in one order, not a changable order, and it takes hours to select which test cases are the best test cases to run in a short test pass based on exactly what was changed”.   (looking at the CFO).  If you want to have 2 testers in 30 seconds reprioritiese exactly what test cases, in order of severity and business priority to start with, in the GIVEN time frame, 2 hrs or 2 days.. then implement our templates so we can do what you have been hired us to do.  I actually said “No offense, but step back and let us do what we were hired to do, get out of our way and I will show you what agile testing is”.

It was just after this awkward pause  the Microsoft PM said to this train wreck PM, “I know where you are coming from,  I am a control freak and my first project with them 6 years ago was difficult to understand.. But now, I don’t care how they test, what they test, I only care when their testing is done, Microsoft hires them because they are the experts in testing, not me.”  SLAM  DUNK!  He disarmed the trainwreck PM, outing him as a control freak.  A seed was planted in this meeting  “WHY is the train wreck PM  attempting to argue with an ex- Microsoft Test Manager? What sort of arrogant cocky PM is this who wants to dictate how testing is done?  With no experience to back it?”

I failed to mention the purpose of the meeting was to introduce the Microsoft PM to this customer as consideration to Mentor this train wreck PM on how to manage long term development projects that deliver on time, on budget with quality and the teams go home at 5:00pm every day.  I told the customer, attempting to “course correct” a PM from a testing role is like trying to drive the car from the back seat with the seat belt on.  I’m here to put Microsoft in the drivers seat next to your PM and teach him how to drive this project.

The Microsoft PM said to the CFO,   Prevention testing is like putting the fence across the top of the cliff instead of dealing with “detection” testing ambulances and chaos at the bottom of the cliff afterwards.   The CFO said “Can’t I just get rid of the cliff?”  with a smile.

The other two  customers PM’s that day were lovely.  They hired us because of our reputation and implement the tools, templates and planning we recommend.  On hour discussion with them and we are moving forward.  With the train wreck PM, we’ve been having this debate over a TFS Template now for 3 weeks and still not moving forward.

Going Toe to toe with a PM on project who wants to control testing, bring it on!.  You have no arguments, no history, no experience in testing, no successful results to challenge me with.  Why is that?  Because your CEO or CFO would not have brought me onto your project if it didn’t need to be rescued. If  I’m in the room with you going toe to toe, its because YOUR CEO is tired of losing money and deflecting his customers critisim of the quality.  I suggest you step back, hand over the project keys because I’m here to “course correct” you.  I’m here to move testing and QA to the begining of the iteration at conception.  Prevention of defects begins with the first conversation with the business on “what would you like us to build?”.  To conduct those reviews and meetings without a Test Manager present to process and align how it can then be tested is the very first error in Program Management.  Prevention of defects starts at conception of the idea.

That’s what I’ll call myself here in Diary Of A Tester (DOAT).  Keeps it real when I can type what I want without concerns of what my employees or customers will think.  Oh, they have all heard me go off on these topics over the years, so it wouldn’t be new information to them, but regardless.. nobody wants to be nailed publicly.  Nailed?  I guess that kinda sets the agenda for where my head has been for a few weeks.  The word “nailed” certainly isn’t a word used in a positive stream of consciousness  now is it.  The first cliche that comes to mind is “Nailing someone to the cross!”  persecuting, or “Last nail in my coffin!”, the episode that triggered the breakdown. Let’s start with that one and work backwards through  some of the nails.

I just had another “breakdown”.  That’s my word for it.  I don’t put a description  in front of the word, it makes people imagine and create their own description of what sort of  “breakdown” I had.  Was it nervous? Mental? Physical? Grief? Psychotic? Emotional? Corporate? Financial? all of the above?  I don’t describe it for anyone, I just say “I’ve had a breakdown” and leave it at that.  I guess that is because I don’t really know what all the ingredients are , but I do know I am broken, and I do know I’ve been broken before in exactly the same way.   And now I know what triggered it.

If you can think for a minute about the hierarchy of an IT project, and where the power cells are located throughout the project, you’d most likely would place the software tester at the bottom of the hierarchy of influence. And just above the tester on the road to wisdom is a Test Lead or Manager and everyone else in IT sits above us from positions of great technical,  architectural and management expertise.  I said this recently over lunch to a customers employee  who came in from the field  for a few days to user acceptance test the application we were developing.  This man, who knows his industry inside out, backwards and forwards, up the ying yang and around the bend, this man who’s very lively hood is entrenched for decades of loyalty to his company,  he said back to me, “correction:  we are below even you in the hierarchy”. I choked down the mouthful of my own ” victim hierarchy” lunch I was eating and realized how backwards this all is.

How is it that the person who will one day actually be using the software day in and day out to make them more efficient, productive and effective;  how is it that THEY  hierarchically speaking, have the least decision making influence over everyone else?  After this insight of epiphany proportions, I decided it was time raise my backhand to flip this backwards, back-washed industry on it’s proverbial backside, and usher the user acceptance tester to the top of the hierarchically influential front end of decision making.

I was armed with my machete of reason to hack away and debate those who opposed my epiphenomenon.  However; there was no resistance.  I know, your thinking “what, what?”, as I was at the time.  Can you guess what is worse than no resistance?  Yeah,  “indifference”.  Oh that just made me want to turn my machete on myself.   At least “give a damn” and agree or disagree, but to ignore?

The pathway to the top on the hierarchy was clear, indifference means they don’t see what’s coming.  I fly under the radar of resistance, I circle around the project in a new confidence of ownership like an eagle and on my back rides the voice of the end user.  Together we land on the developers shoulder who implemented the glitch in the system in the first place. Together my user and I demonstrate a leadership that is balanced with communication. We talk to the guy together and explain the value of changing the application to be just as my user wants it to be.  They are “my users” now, “my peoples”, “my hood”. It  feels like that at the top of the hierarchy.  We circle above the IT project hierarchy as if we are their spirits whispering in their ears of easier usability, faster access to menu’s and help bubbles that actually help.  Nobody resisted, everyone listened and the relationship grew to a momentum of collaboration unlike any I’ve ever experienced.

So why and how did I crack up? The relationships with the end users, the program manager, the developers and team all around was synergy in motion.  Euphoric almost.  The joy of our success lead to longer days, and a decision making process that included the end users voice as loud as the program managers.  The harmony lead us right up to the go live date in unison,exhausted but aligned.   Then, as a Test Lead does, I attempt to stop all changes before we bring the customers back online, a few days before to re-test and verify we indeed have integrity and stability throughout the application.

The momentum of the team just rolled over me like a boulder on a path down the hillside. The unison of the “team” was now one giant hierarchy boulder and they could not even see me standing in their path in front of them saying “stop”.   The relationships are wonderful, the communication as a “team” was legendary but a single voice was now too quiet to hear.    Exhausted from my loyalty of endless testing days, fractured from the boulder rolling right over me, I broke.  It felt like a stab in the heart from the very people I championed.  Betrayal is what the action looks like with dirt on my face, blurring my perspective  after they roll past continuing down the path, changing the application the night before “go live”.

What surprises and shocks me even now is that I have been boulder-ed a hundred times before on other projects, and they didn’t break me.  The trigger for this break down is in fact the loyalty, the great relationships and communication, the ‘care factor’ of a successful project.  My role as a test lead  is to step out and slow down the team as they approach “go live”, “stop and stabilize” is my motto before bringing customers back on to the new application.  I helped create this mass of teamwork I couldn’t stop, it was my boulder out of control rampaging with change towards go live date, I could not reconcile it, could not process it, I was too exhausted and broken to be there for “go live”.

I helped create this boulder that broke me, I can’t even be a victim about it now.  I wouldn’t want to go back to the old school waterfall development  approach either.  So I’m in the middle of a  breakdown that I can’t reconcile as a tester.

Imagine how it feels to have great project relationships with your team, amazing communication with the customer, a successful on time, on budget with quality delivery and all of that was the trigger for a breakdown.  It  feels a fraction psychotic and arrogant of me as well, but there it is.

I just had an insight as I typed this last sentence.  I can’t really call the project a success can I.  Just because the customers are happy  and it’s on time with quality doesn’t mean to me that it was successful.  It cannot be a success if  I’m in the middle of a breakdown. Also, I can’t say “great communication” can I.  Over ruling  is not great communication.. so there’s my “ah ha!”  There’s where I dropped the ball, great communication is not just collaboration, it’s respect for each person in their role, regardless of the hierarchy.

I really loved the recipe of this project, however next time I’ll change the ingredients to:

• 8 hr work days
• 8 hr sleep each night
• Victim / Betrayal makes the project bitter so swap this  ingredient for accountability
  
• Fold it all nicely together in a teamwork bowl of collaboration with soft peaks of respect for each role  and then bake at an even temperature for 8 weeks.

In hindsight, if I had prepared it this way, I just may not have had the breakdown.