Communicating vs. Discussing – Lesson Learned

I was visiting a customer last week and had an “ah-ha” moment thanks to a comment by someone there.
We were talking about communication and the need for regular communication with the entire division regarding the work they are doing towards an agile transformation.  Linda then said the following (or something close to it..), “communication and discussing are NOT the same thing.  We need to make sure we give the staff the time to discuss.”

It was such a simple statement but really hit me hard.  I have always felt I was a good communicator…..I try to send updates to my team every week and share as much information as I have to ensure we are all on the same page.  However, I haven’t always thought about the discussing side and how very important that is.
I can communicate all day long but if I don’t provide the situation and environment for everyone to discuss the information that was just communicated, then I am missing the boat.  I know that I always feel more comfortable with change when I have a chance to ask questions, get clarification, and discuss with others.
So, this is my new goal for the rest of the year…continue to communicate but also ensure there is ample opportunity for discussion.
Thanks Linda!

Advertisements

DON’T RUN! (tips for communicating I learned from my nephew)

I just finished teaching an Agile Testing Class to an awesome testing team in Dallas.  We spent a good amount of time discussing how to communicate effectively with other team members. Specifically, we were talking about how to approach a developer when you need them to implement a solution in a different way that lends itself to easier testability.  I often hear these conversations start with words like, “Don’t put the code…..” or “I can’t complete my tasks if you…..” or “Every time you do that I can’t….” etc.  You get the point…they are very negative statements.  Without meaning to, you are putting up a wall and the person you are talking to is likely to go on the defensive immediately.  Not a great way to foster teamwork.
I have a 4-year-old nephew that, like all other boys his age, absolutely can NOT walk anywhere.  His feet only know how to move at a run.  I have spent several hours of my life saying (or shouting), “Don’t run!!!”  “Stop Running!”  I recently learned a great tip from his pre-school teacher.  Rather then constantly telling him what NOT to do, just remind him of what he can do.  So, I have learned to use the phrase , “Use your walking feet!”  Not only do I sound like a much nicer person when I say that in crowded public places, he responds to it so much better.  He is allowed and encouraged to use his walking feet.  He is just being reminded of good behavior.
I encourage team members to apply this same principle when you are communicating with one another.  Instead of telling a developer what NOT to do, offer up a suggestion of what would work great.  If you aren’t sure what will work, show them what you are trying to do and ask for their help in crafting a solution.  By communicating this way, you are fostering better collaboration and team work instead of putting each other on the defensive.
Oh, and use your walking feet when you go talk to them ☺

Notes from a Recovering Crackberry Addict

I was out to lunch the other day with some friends I hadn’t seen in a long time.  I was really looking forward to catching up and seeing them.  However, by the time the check came, I was half irritated with them both and ready to leave.  Why?  Because the entire lunch was spent with them half listening and checking their Crackberry’s every 2 minutes.   

In the spirit of full disclosure, I must first admit that I WAS one of those people about a year ago.  My Blackberry was strapped to my side 24/7.  It was the last thing I looked at before I went to sleep and the first thing I looked at when I woke up in the morning.  Every time it vibrated to let me know an email came in, I stopped what I was doing to check it out.  I just couldn’t help myself.  I was addicted.  Surely every email that came through (and there was well over 100 a day), needed my immediate attention or something awful was going to happen.  I just knew it. 

When I changed jobs last year, my Blackberry was left behind.  I almost bought a new one but decided on a simple cell phone instead with no text messaging package included.  My last day at work, I handed over my Blackberry and immediately felt 20 pounds lighter.  I was free.   

However, later that night, I swear I began to get nervous and jumpy.  I was out with friends and they all had Blackberry’s they were diligently checking every few minutes and all I had was my little cell phone that only made and received calls.  I started to panic. What if someone had sent me an email?  What if they all knew something I didn’t?  How would I know what was going on?   Maybe I needed to go and trade in my cell phone for a Blackberry or Trio the next day. 

I decided to see if I could stay Crackberry free for 1 month.  If the world fell apart during that time because of an email I didn’t answer immediately, then, I would go back and get fully connected again. As the weeks went by, I slowly started to calm down.  I was shocked to find that the world (and my job) managed to do just fine without me getting emails immediately all day long.  If there truly was an emergency at work, my co-workers knew where to find me or they could actually pick up the phone and call me if needed.  The funny thing is, they never did.  My new cell phone remained quiet. 

So, I am now the worst thing possible…I am a reformed Blackberry user (kinda like a smoker that finally quit).  I get irritated when I see people madly scrolling with their thumb and typing furiously with both thumbs.  (I will say that whoever invented the Blackberry is clearly not a woman…you try typing on that with long nails…it takes some talent!)   I challenge all you Blackberry users out there to actually turn it off for a few hours one day and see what happens.  Or if you are having a nice meal out with friends or family, leave it in the car and really participate in the analog conversation (nothing digital for an entire meal!!).   I can almost guarantee that nothing catastrophic will happen. 

If you are an employer that hands out Blackberry’s to your staff, reconsider it.  What is wrong with the old fashioned pager?  I used to carry one of those years ago for work emergencies.  And, I can honestly say, it only went off in emergencies.  People will think twice before paging you at 9pm at home but there is no reason not to send an email to someone at all hours of the day.  And, if you are like most Blackberry users, you will feel obliged to stop what you are doing and check that email no matter what time of day it is. 

Now, I realize that there are some of you out there that can carry a Blackberry and are not addicted to it.  You can actually use it in moderation.  Well, good for you.  I was not one those people (and neither are most of my friends that carry them).  So, I had to make a complete break and go cold turkey.  And, it was the best thing that ever happened to me.  My husband also agrees J 

Who gets to decide when to ship software?

I recently got in a lengthy debate with some folks over this very topic.  As I quickly found out, most folks have a very strong opinion on this.  And here I thought I was the only oneJ.  It seems as though most folks fall into 3 different camps: 

Camp #1 – The Testers decide 

This “camp” was formed of folks on waterfall and agile teams (which I found interesting).  They felt that the team that tests the software and was most familiar with the quality and test coverage should get the final say on whether or not to ship it. 

Camp #2 – The Project Manager decides 

This “camp” applied to people on more traditional waterfall projects.  They felt that the project manager knew all of the data points with the project and based on that data should be responsible for determining when to release software.  However, this project managers did not have ROI responsibility. 

Camp #3 – The Product Manager (aka: ”the business”) decides 

This “camp” applied to people that were staffed on more agile projects.  On these teams that had a strong product owner presence, they felt that since the product owner was ultimately responsible for the ROI, then they should decide what and when to ship. 

Camp 1 had the most votes followed by camp 2 and then camp 3 had the least amount.  In some ways this surprised me but in other ways, it was what I was expecting. 

I will admit that I used to be a member of Camp #1.  As a matter of fact, I believe at one point I might have actually been the camp founder and directorJ  However, over time, I have moved to Camp #3.  Let me tell you why. 

Testers typically do have the most insight into the quality of the software.  We are intimately familiar with what is working, what isn’t, and what the high risk areas of the application are.  We can tell you the defect trends, defect turn around time, severity break downs, etc.  Because of this, it is easy for us to feel like we should be the decision maker as to whether or not we should put this code into our customer’s hands.  However, often times, there are several things we do NOT know that also play in to the decision of whether to ship code or not.  Perhaps there is a large business deal that will fall through if we don’t ship.  Perhaps the customer (or customers) wanted the new code so badly that they were willing to take the risk of using it with the list of known issues.  Perhaps the business wants it shipped for demo purposes but isn’t planning on having customers use it until it is cleaner.  Perhaps the business is planning a Beta / trial period.  The list can go on and on.  You get my point.   

Here is what I think about the testers’ role in deciding when to ship software.  I think the tester is responsible for delivering all of the metrics around the quality of the code to the business.  Deliver the facts, not your emotion.  Include test coverage, defect count, defect find rate, etc.  Make sure the business has a solid grasp on the current state of the code and any risks associated with shipping this code.  Then, do the hardest thing possible…..trust that the business team will make the right decision based on those facts and any other data points they may have.

Then, I also firmly believe that the business should CLEARLY COMMUNICATE with the delivery team why they made the decision to ship (or not ship) the software.  This is particularly important if they decide to ship software that the testers don’t feel is ready to ship.  The business should let the team know that they understood the risks but made the decision to ship based on the following facts (at this point, they should clearly list out the reasons why they are shipping).

 If you think a bad decision was made and don’t know why, then by all means ask for an explanation!

Should we be called QA Analysts?

I have been thinking a lot about titles lately and just how much I detest them 🙂  I do love the fact that my current title (QA Architect) is something most people have never heard of so it prompts them to ask me what I really do.  It gives me a chance to explain to folks what I actually do at work, not what they will assume I do based on my title!  Common titles can be very misleading to what people actually do.  The title of QA Analyst or QA Engineer is a perfect example.  I am going to pick on this because I had this title for a long time.  (The same goes for QA Manager).  There are several reasons why I hate these titles.  Here are the top 3 reasons why:

1.   If someone on your team has the title of QA Analyst, they typically bear the responsibility of the end quality of your product.  People start to say things like, “The QA folks will test it…don’t spend too much time testing your code.”  Or, “QA will catch it if there are bugs.”  Since when did the end quality of the product rest solely on the QA staff?  Everyone on your team should be responsible for quality, not just the folks testing the software.

2.   QA Analyst of what exactly?  It sure is vague.  Everyone just assumes it means the quality assurance analyst or engineer of the application you are building.  Why are there people with the word “quality” in their title only on the development side?  What about the quality of the entire development process, the quality of the designs, the quality of the sales team, quality of support?  By putting a “QA” title in development only it seems like we are really missing the boat by not looking at quality across the organization in all roles.

3.   When you tell someone that you are a QA person, you have just stuck a huge label on yourself.  It may be a good label or a bad label depending on who you are talking to.  Some QA folks focus solely on testing.  Some QA folks are really focused on SDLC only.  By telling someone that you do “QA”, you may not be telling them what you really do at all.   

Here is what I would love to see.  I would like to see people that focus on testing called “Testers.”  Nothing more, nothing less.  If the main purpose of your job is to test the application to ensure that it is working as it should, then just call yourself a tester.  People that develop code are just called developers, not “Quality Developers”.  Let’s call a spade a spade here.  If you test, then just say you are tester.  You should not be ashamed of that! 

Then, ideally, you WOULD have someone in your organization that is overseeing quality.  However, this person would be looking at quality across the board.  They would be analyzing processes, etc from the sales team all the way through development and then to the team that supports the customers.   Depending on the size of your company, this could be a whole team of folks.  Make sure these people know what they are doing and have been in the trenches actually “doing it” before.  Also, make sure these folks are trained on the Lean Principles of software development  to get the biggest bang for your buck.

What is your current title?  Do you think it reflects what you really do?

TISQA 2007 Conference Review

I spent the day yesterday at the TISQA conference in Chapel Hill, NC.  It is a one day local conference that the TISQA group puts on every year. 

The opening key note was from Jon Bach.  As usual, it was a great talk.  I love listening to him talk about exploratory testing.  I always learn something new.  The afternoon keynote was a talk by Rex Black called “Testing in an Outsourced World.”  As usual, Rex was an awesome presenter.  While I disagree with some of his views on managing outsourced testing, I got some great ideas from him around how to manage cultural differences in that situation. 

I only got to listen to one other presenter (TR Buskirk) since I was presenting in the afternoon.  It was a fun talk that highlighted some of the challenges that QA groups face in all companies.

This was the first testing only conference I have been to in several years.  It was an eye-opener for me.  The conference was run extremely well as usual and the TISQA group did a great job scheduling, etc.  The main thing that stuck out for me was the atmosphere difference from this conference to others I have attended in the last few years.  My personal opinion is that the atmosphere was different because it was a group of testers, not a mix of developers, testers, product folks, etc.  It definitely didn’t feel like an “agile-friendly” environment.  That said, it was still a good experience and I hope that at the end of the day, at least one person there may think about approaching testing differently.

Taking Ownership of Quality with Outsourcing

I have recently had the opportunity to speak to some QA folks at different companies.  During our conversations, the topic of quality and QA practices came up with regards to outsourcing.  I have never personally worked on a project that involved development from outsourced companies so I have never had to deal with this first hand.  However, it is a topic that I found very interesting and it got me thinking about it.  So, I started doing some research and investigating on this issue.

Most of what I am discovering is that QA seems to function one of 3 ways with outsourced development.  For these examples, I will refer to the outsourced company as the Child and the company that is paying them and ultimately owns the code as the Parent.  Here are the re-occurring scenarios I have come across:

1.  Child is responsible for QA.  This includes creating the test scripts (manual mostly, may have a few GUI automated scripts), running them, and ensuring that the code is working.  Child gets to use whatever QA practices they currently operate under.  They deliver code to Parent and Parent trusts that Child did their job well enough and distributes the code.

2.  Parent develops the test cases the Child needs to run (manual scripts).  Child develops code and then executes test cases from Parent (may use manual or GUI automated tests).  Child reports on the statistics of the test cases to Parent.  Parent then distributes code.

3.  Child builds and tests code.  Child reports on QA metrics to Parent.  Parent then has their own QA staff re-run all test cases on delivered code to ensure that the code is functioning correctly.  Parent also does exploratory testing if time permits.

I personally am not comfortable with any of these options and would not sleep well at night if I was on a project in any of these scenarios.  Why?  Because in all of these scenarios, no one is really owning quality. 

Scenario 1 is flat out irresponsible.  Parent owns the outsourced code and owns the quality of it and is doing nothing to ensure that quality is being met.  Parent has no visibility into what Child is doing and Child is not educating Parent. 

In Scenario 2, Parent probably feels like they are owning quality.  By creating the test plans, they feel like they are controlling the quality.  They get a report that lists out the stats of the passing test cases and they feel good.  I argue that Parent is not really owning the quality in this option either.  As we all know, a lot can be lost in interpretation.  I can write out a manual test case that 2 different people can run differently based on their interpretation of it.  One may pass and the other may fail.  This has been proven time and time again with detailed requirement documents where what the analyst wrote is not what the developer coded due to interpretation differences.  This scenario also leaves a huge gap with negative testing and exploratory testing. 

Scenario 3 is the most interesting.  Awhile ago, I likely would have thought this was the best way to go – not so much any more.  I guarantee that Parent really feels like they own the quality here.  They are providing the test cases to Child and then making sure Child didn’t mis-interpret them (or the Child didn’t run them)  by running them again before delivering to production.  If we keep our view of quality to just mean that the code is doing what we asked for it to do, then yes, Parent is taking ownership of the quality. 

But what about quality of the entire SDLC in this scenario??  Parent is spending money for Child to execute tests and then spending even more money to have the Parent QA team re-run those same tests.  That is a very low-quality cost solution.   By re-running manual test cases multiple times by multiple teams, this is also a very low-quality time solution.

QA Professionals should expand their view of quality to include more then just the code in the application they are testing.  Quality needs to include everything that happens to get that application into your customer’s hands.  It should obviously include how the application performs (both functionality and performance) but it should also include the process around that delivery.  We should be looking for ways to cut cost and time such that we help deliver a high performing application in a low cost, speedy timeframe.  This is hard for QA folks – we are control freaks 🙂  We like to dot every I and cross every T.  We want to test, re-test, and re-test again and again to ensure that we didn’t miss anything.  When our co-worker says they tested that scenario and it is working, we want to test it for ourselves to ensure that it really is working J  However, if doing so adds a large cost to the delivery of the software (either time or staff related), it is our job and we should feel obligated to look for ways to reduce that time and cost without hurting the functional quality of the application.

So, with all that said, here is the scenario I would want to be in on an outsourced project.  First and foremost, I don’t see any reason why both Parent and Child shouldn’t work together to ensure joint ownership of quality.  I don’t ever want to be in a situation where Parent throws requirements to Child and then waits 1, 3, 6 months for Child to build them.  Instead, why not have Parent and Child work together?  In an ideal situation, I would want to have Child work in an iterative fashion where they can deliver code AND automated tests to Parent every few weeks.  It may not be easy to find a company that is willing to do this but I think it would be worth the investment to train them how.  That way, Parent not only gets working code every few weeks but also gets automated tests that they can set up and run at will.  This also provides the opportunity for regular feedback between the teams.  You can even take this one step further and have Parent write the requirements as executable requirements and deliver those to Child.  It is then Child’s job to deliver code to make those executable requirements pass.  In this scenario, Parent is certainly driving quality but Child definitely has quality responsibility as well.  Both companies are contributing to the ownership of quality (from and application and process perspective). 

Yes, I know…this is agile developmentJ  This why I love agile practices and principles.  They really focus on quality from every perspective and push it all the way up-stream to the very start of your project.  It is a quality dream come true! 

There are some out-sourcing companies out there today that follow good agile development practices and I hope this number continues to grow.  I also hope that if I am ever on a project that outsources pieces of development, that it will be to a company that is willing to work this way.  As a QA professional, I certainly feel that it is my responsibility to push for this and do everything I can to sell this to the folks that make the ultimate decision.