Archive for the ‘communication’ Category

Improvisation: for your Team and Life

It takes strength to stay open

It is easy to create lines for yourself, to box yourself into a corner, to let habits, concave thoughts, patterns, and conditioning keep you rolling along responding to perceived threats or obstacles in a myopic manner. Remember your own brilliance.  Assume the best in others.  Seek to create new possibilities and new perspectives for yourself and for those around you.   Learn from Tina Fey’s Rules of Improvisation as a fun source of day-to-day introspection. Her heuristics along with my personal notes:
  • Agree. Respect what your partner has created. You are listening, receptive, and seek to understand. Even if you do not actually agree with what you think you are hearing, it helps to repeat what you think you have heard, to say it back to the person to make sure you are getting it. If you have trouble with this, learn a little about the Satir Interaction Model.
  • Say yes and.  Don’t be afraid to contribute. It is your responsibility to contribute.   This does not mean to take on more than you have bandwidth for or cannot effectively deliver on.  It does not mean to say yes to something you really are not okay with. You might say “Yes I can do that and this would mean….”.  It means to honor your own voice, to not be afraid to speak up.  It is okay to ask for help.  It is okay to say what you need.  It’s okay to be empathetic, but important to remember there are other ways to see things.
  • Make statements.  with your actions and your voice. This one has been especially important for me.  Early in my first role as a manager, my statements came out more like apologetic questions.  The impact was disastrous for me and harmful for my team. I learned how to turn this around once I realized what I was doing.   Another aspect of this guideline is to recognize if you are the person at the office who says or thinks ‘I felt menaced when Terry raised her voice’, then find a self-empowered way to respond and come up with a solution to move beyond feeling mad or hurt.
  • There are no mistakes.  There are only opportunities.  If you (or a teammate) have a tendency to beat yourself up, do yourself a favor and learn (share) techniques to tame your inner critic.
FullSizeRender (3)

Reminder to get on with it and to not worry too much.

Act as If

A few year’s ago when my previous team was overhauling our software development process, we took Ken Rubin’s Scrum training.  One of the experiential exercises illustrated the benefits of rules 1 and 2.  It was an exercise in communications and teamwork. It turns out that Google Engineers also appreciated Ms. Fey’s shared lessons enough to invite her to SPEAK AT GOOGLE:  [2 minute clip; Full Fireside chat]

A brilliant friend recently told me he felt like an imposter.  I was moved by his vulnerability. I did my best to remind him of all he brings to the table. I confessed I sometimes feel like that, too. That’s a sign that it is a good time to take a walk around the block. Also, when I feel less than confident about something, I change how I am carrying my frame and I GET MOVING.  My first powerful lesson in this was in high school one summer at a band leadership camp at the University of Whitewater-Wisconsin. It went something like this.  Tim Lautzenheiser had us sit up on the edge our seats, spines erect, hearts lifted, big smiles.  Try to think a bad thought.  Chuckles erupted. This was not easily achievable.  Next, he had us cross our arms and legs and sink down into the backs of our chairs.  Now try to smile.  Try to think a happy thought. Again laughter. The body’s posture was in direct opposition to what we were being asked to do.

These days I incorporate tips from Amy Cuddy’s powerful TED talk to get my head on straight, to feel confident before meetings or to prepare for presentations. Educate yourself on body language as part of your “improv training”.  😃

Thanks for the Improv

As I typed today, I realized my boss, who is also a coach and mentor, seems to live, breathe, and evangelize these improv guidelines. I have had the privilege to observe that despite challenges, in every-single-situation he demonstrates an amazing balance of strength and flexibility. He does this with complete

Transparency.

The are the things I value and appreciate the most.  The very things it takes to connect with individuals and to have an autonomous, cohesive, empowered team are also what it takes to connect with your fellow actors to move an audience:

Empathy and Trust.

Rules of Improv Source: Tina Fey, “Bossypants”

All Kids Love Logs!

We learn from logs – application logs, system event logs, API logs, network trace logs.  These are invaluable tools for testers.  To not consult logs or not have access to logs is to miss out on these benefits:

  1. Save time on bug investigation.e.g., Logs can show failure conditions related to data problems or issues with error handling, thereby saving you time trying to figure out what just happened.  Logs can point you to an environmental/operational health condition such as network or server related problems.
  2. Report the bug even when you cannot recreate the issue yourself. You have proof and details, which you can build upon if the bug shows up later.
  3. Strengthen your street cred with Programmers and other Testers.
    • Build bug reports which include exception stack traces, timestamps, request & response object details, which can help with the next bullet point.
    • Reduce the time Programmers spend pinpointing and fixing the bugs you reported.
    • Become a more technical tester.
    • Demonstrate that you have done your homework on the bug.
  4. Learn more about system internals and the software environment.
  5. Gain insight into error frequency and severity.
  6. Identify internal bugs, such as logging issues or security-related problems like un-obfuscated passwords.
  7. Investigate failures for which there is no visible error in the user interface.
  8. Proactively monitor system health. i.e., Investigate errors before they get escalated to you via Support.
  9. Identify on what day a particular error appears to have started, i.e., bugs introduced in a particular build, problems introduced as a result of an environmental change such as a change to server configuration .

Gotchas:

  1. What you zoom in on within logs may seem more significant than it is so remember to adjust your focus and stay neutral in your bug reporting.
    • What you notice is important, but what you are focused on might not be what you need to see. (Jesse Alford’s reference to AutoFocus in his Lightning Talk, Focusing the Mind’s Eye.  An Optics Analogy at CAST 2013. See Jesse’s talk here.)
  2. System logging bugs – inaccurate log levels, missing logs!
  3. Make sure your software architecture or operational configurations prevent DEBUG logs from getting into your production environment and creating a mess.

*Credits:  For fun – I borrowed ‘All Kids love logs!’  title from Ren and Stimpy.  Here is a tidbit from their quirky show [1 minute: 6 seconds via YouTube].

 

Career Composting


As kids, my brother and I loved to dig into our family’s enormous compost pile of oak and pecan tree leaves, vegetable scraps, and dried horse manure to find worms for Grandpa’s fishing trips.  Our rewards:  his ear-to-ear grin and 10 cents for every worm we found.  As an adult, I sift through a much smaller pile in my backyard and tend a tiny family garden.  Using my hands there goes a long way in clearing my head and often helps me turn over my work experiences.

I love to unearth bugs in software and appreciate help finding bugs in my thinking.  Like composting, growing into new habits take practice and patience. Here is the goodness which surfaced over time in the bins of the greatest personal challenges in my recent software testing history.

I have a voice and I trust myself to use it.

  • Test leadership – I articulate my strategy and my role as a tester.  I narrate 3 stories – status of the product/how I tested it, how good that testing was/why you should be pleased with my testing, Is there anything else you want to know? (Credits and thanks to Paul Holland’s Track Tutorial on End-to-End Agile Testing at CAST 2013 conference). I am not a gatekeeper or Product Owner, so I speak up when someone asks me to “make the call” to launch. I re-iterate my role in support of the business stakeholder team making an informed decision.  I make recommendations based on testing and quality issues.  I adjust the test strategy to explore areas of concern as project scope changes.
  • Management – I am responsible for providing direction and for communicating clearly;  I am not responsible for other people’s happiness. To be of best service, I direct my attention to the former, to the clarity and content of my message.

I will not underestimate the importance of community.

  • The above phrase resonated with me at CAST 2013 closing remarks by Scott Barber and Rob Sabourin.  I am continuously bolstered by the generosity of the software testing community through reading many blogs, my participation in a few sessions with Weekend Testing Americas, online coaching from Anne-Marie Charrett, learning from interactions and resources from online training through the Association for Software Testing, attending conferences.  I use techniques, tools and resources from the all of the aforementioned.
  • Now is the time to begin to give back.  I did a lightning talk at CAST 2013 on Leading Testing: Lessons Learned from Gumby. The positive responses and encouragement from those 4 minutes was part of the nudge I needed to draft my 1st post. I will devote energy to the fledgling meetup group I founded, Gulf Coast Software Testers, and I will eventually follow Claire Moss’s lead on co-branding this group as she has smartly done with Software Testing Club – Atlanta.

I ask for help.

  • I recognize emotional triggers as an invitation to cultivate self-awareness and an opportunity to grow my emotional intelligence (EQ). There is something (within me) that is asking for my attention.  No dillydallying!  I promptly confide in someone I trust to ask for feedback about the situation.
  • If I feel like something is technically over my head or if I get bogged down isolating failure conditions, I step away from my desk to get a 2nd opinion.  When I have been on the same test project for a long time, I reach out to my teammates to discuss testing with a developer, architect, and/or another tester to discover there are areas of the system, other scenarios, or approaches I have not considered.
  • Thank you to these great folks for their contributions, which have inspired me in this area:  Eric Jacobson – blog post, You’re a Tester, Relax;  Anne-Marie Charrett – Article [PDF], Beware the Lotus Eaters: Exploratory Testing; Paul Holland – YouTube video commentary on Skilled Testing.

Catch any worms lately?  What lessons did you learn in 2013 to apply in 2014? I wish you a hardy and prolific new year! 

– A heartfelt thank you to @aclairefication for her effervescent feedback, which helped me refine this post.