Quardev

How we communicate is directly related to the success we enjoy, with our friends and families, in life, and in business. Our communications are a cornerstone. How we communicate is one piece, but what we communicate is paramount. This issue of the Quardev Quarterly is dedicated to this subject of communications and looks at the way we communicate (the tools we use) and how we communicate (with clients and each other).

Thank you for reading the Quardev Quarterly. We hope that some of the viewpoints we've been able to share in this issue will give you more insight to some of the ways we operate and may help you in your daily work life.

Enjoy the newsletter with our compliments and please contact us with questions, comments, or article ideas.

All our best;

-The Quardev Crew!

Download the Quardev Quarterly - Q2 2008 PDF

An Experiment with Appreciative Inquiry

By Jon Bach, Manager for Corporate Intellect, Quardev, Inc.

As Manager for Corporate Intellect here at Quardev and a member of the Executive team, my role is to study how we do things - by way of practice, process, methods, approaches. My job is to examine all of the things we call "services" and find a way to extend what's working.

One of the things I've studied recently is something another colleague here at Quardev was hoping would make communication in our management meetings more productive. Her intention was to find an alternative to a focus-on-the-problems-and-fix-it mentality because continually focusing on what's not working can often lead to lower morale.

Her idea was to try something called Appreciative Inquiry (AI), a process for studying success, for finding value in the things that organizations do *right*. I was reluctant at first, mostly because she had handed me a small book on the subject that looked more like a brochure you'd get at a weekend seminar. Since I'm wary about things that drive more buzzwords into our workday, it sat on my desk for a few weeks before I really paid attention to it.

According to the author of the booklet, Sue Annis Hammond, (titled: The Thin Book of Appreciative Inquiry), Appreciative Inquiry is an "inquiry process [leading to] a series of statements that describe where the organization wants to be, based on the high moments of where they have been."

The process is this:

1. Create a question to explore. (The book gives examples like: "what do you value most about being a member of this team?").
2. Brainstorm answers for a few minutes and decide what the best examples are. An answer from the question above might be: "There's always something interesting to learn."
3. Determine how those examples came to be. In other words, what was it about the examples that caused them to come to light during the brainstorm? For example: "We have online training and a collaborative culture that fosters learning on the job."
4. From those stories, create "provocative propositions" - statements written in the affirmative, like: "We continually learn as we work" or "We devote time to learning more so we keep our expertise current." I was intrigued at this, but knew I had to try my own experiments with it to see if it was something right for us. To begin, I decided to create a small presentation (5 slides) to present to our executive management team to see if AI would be something useful.

I came up with the following process, using AI as a base:

Ask a big question and time-box the ensuing brainstorm. For example, "What have we done to attract, communicate with, support, and retain staff?"

Capture the ideas on a flip chart or whiteboard. For example, for the retention topic: "giving out profit-sharing checks," for communication topic: "use Instant Messaging with remote staff."

Look at the stories that were told and list their inherent values. For example, "innovation; integrity; responsiveness; keeping an element of fun."

Vision: Ask, "what does success look like if we applied those values?" For example: "Clients view us as a trusted partner because of our people," or "We are sought after by all kinds of talented candidates."

Action: Ask, "Now, how do we live these?" For example, "advertise our values on the wall," "keep doing the recognition awards every month."

I'm pleased to report that we've had 5 meetings using this AI-hybrid approach and I don't see any desire to go back to our old style of meeting. All 10 managers seem engaged and focused each time and there's a feeling that we're making progress toward important company issues. I think the time-boxing fostered that, but if a new idea came up for one of the previous steps on the process, I let it come up and captured it.

I think this type of method for solving problems is a success in itself. After all, success is something we've all experienced and AI seems designed to "know" that when we're successful at something, it usually feels good and we want to replicate it - sometimes out of the fun of showing mastery, sometimes out of a desire to win more credibility, autonomy, and respect from colleagues. But it's the study of success that may have more value than the success itself because it's easy to forget the details of successes. We tend to integrate the lessons and move on, forgetting the context and the details of what contributed to that success - AI may do well to bring all of those details back to light.

Ultimately, Appreciative Inquiry seems NOT to be about seeing how you've approached past problems, but to provoke discussions from people who may have different perspectives on why the success occurred. For more details, see http://appreciativeinquiry.case.edu/.

Public Agreements and Organizational Learning

John Forman, Managing Partner, Integral Development Associates

Back in the days of Kaypros and Heathkits, one of my college friends, an engineering student, gave me some insight into troubleshooting the snags on my computer: "Computers are unbelievably stupid," he told me, "they do only and exactly what they are told." My frustration came from the fact that I expected my computer to respond like a person.

While computers are far more sophisticated in their responses now, we still sometimes make that mistake in reverse... we expect people to respond like a well-coded and tested program that does what it is told.

There are times and places when a top down, 'command and control' style of rule-making and enforcement is effective. But with most staff, all customers and even most vendors, there needs to be alternatives. This is especially true when an organization or management team wants the full engagement of hearts, heads, and hands. Increased pressure to do more with less people, reduce error rates and improve productivity can cause many people to fall back on old habits. But those who want to stay viable and thriving in the years ahead will be willing and able to make use of new approaches to communication.

The use of "public agreements" as defined by psychologist Robert Kegan is one important approach to evoking full engagement and increasing capacity through collective learning. While some top down creation and enforcement of rules may be necessary, in most business contexts there is much to be gained by engaging people in learning together about what works best. Public agreements engender an attitude of a 'pulling' rather than 'pushing'. The leader pulls experience, knowledge, insight and engagement from the employees to create a situation where they are pushing for results as much as the leader.

The leader's first task in this approach is to clarify that "Your input is needed and wanted - we all have to look and think together about what works well, what doesn't, and how to improve our way of going about things. Doing this will lessen stress, improve our efficiency, get better results, and make work more fun." Public agreements are different from rules in that everyone is invited to participate in creating and improving them. This is what leads to a genuine experience of 'co-ownership'. Because public agreements (unlike 'rules imposed from on high') are co-created and co-owned, when they are violated it is not only the leader that feels responsible for noticing and addressing the breach. Everyone has a stake, including the person who has not acted in accordance with how they agreed to go about things.

The leader must also make clear that public agreements are 'successive approximations of best practice' - a work in progress vs. rules written in stone. Compliance is expected and respected, but equally so, going forward everyone will be held responsible for bringing attention to work procedures and other public agreements where compliance with one agreement is at cross purposes with another P.A. or an important value or goal of the group.

The first step in creating a public agreement is to find an on-going, recurring problem... one that is unlikely to be solved so much as it will "solve" you, the organization, team or group. For example, we know of one CEO who has made clear his intended priority to support his department heads' decision-making. However, he more than occasionally steps in to make what feel like unilateral decisions. You can see that this is not a problem solvable by a rule.

The second step is to create a draft agreement. In the example above, the CEO and his team agreed to a 36 hour waiting period, during which department heads would provide clear and timely information as to any negative influence his making a unilateral decision would have. Other public agreements could be made around department heads' making decisions that influence other departments or a specific initiative focused on customer service. Any agreement that will produce learning is a good candidate. It will not be cast in stone.

The third step is to follow the fate of the agreement. Where the agreement is working, the team experiences organizational integrity rather than compliance. Where the agreement is not being upheld, the team has the option of refining the agreement in response to what has been learned.

Most organizations have plenty of examples of rules that are written in stone but widely ignored. Often they are ignored or bypassed because complying interferes with other important agreements or results or the reason for the agreement is unclear. These violations may be hidden, or they may be an 'open secret' ignored by managers who sympathize with their employees or who want to 'avoid trouble'. The old leadership style tends to continue enforcing rules (or turn a blind eye to violations) rather than being curious as to why there are widespread or repeated violations.

With the use of a public agreements stance it becomes much easier to update how things are done, to keep everyone aligned, and to create 'institutional integrity'; "we do things this way for good reasons (that I understand) and if there are good reasons to change we will." When a public agreement is repeatedly violated it is examined to determine why and to discover if the violations point to a needed revision. This allows the group to stay aligned on the basis of an actual common sense of importance.

When violations of public agreements are noticed and named the leader models the stance to hold in regard to them - a curious and learning-oriented attitude rather than a punitive or penitential attitude. Because the primary intention is to generate individual and collective learning rather than sanction the violator; errors and breaches become much less risky to talk about. This has the very useful effect of making it much easier to notice and name violations of public agreements than violations of traditional rules and policies. As a result it becomes safe enough that many previously hidden, off the record, underground and "work-around" behaviors can be discussed and dealt with in straightforward and productive way.

STAREAST Preview

For the past 5 years, Quardev's Manager for Corporate Intellect, Jon Bach, has been accepted as a speaker at the annual Software Testing Analysis and Review (STAR) Conference in Orlando, Florida. http://www.sqe.com/stareast

This year, the conference runs from May 5 to May 9 and features 3 presentations from Jon:

1) On Monday, May 5, Jon will deliver a half-day tutorial titled "The Craft of Bug Investigation" which focuses on black-box techniques to uncover more details about underlying faults rather than settling for reporting what might be just surface failures. "I don't think we spend enough time investigating bugs once we find them," he said. "There may be a lot more to the problem than meets the eye, which we all know can be fooled anyway, so there are times it may be worth holding off on that bug report until you perform a few more follow-up tests."

2) On Tuesday, May 6, Jon will deliver a full-day tutorial on Session-Based Test Management -- a way to manage and measure exploratory testing through the use of time-boxed charters that focus testers' exploration. "Twenty years after Cem Kaner coined the term 'exploratory testing', it's still regarded by managers as just 'playing around with the software'," Bach said. "SBTM is not only how I fight that notion, but specifically how I can help managers see the variety of skills and tactics inherent in exploration that unearth some of the most valuable bugs on the project."

3) On Thursday, May 8, Jon will present a 45-minute track talk titled: "Telling Your Exploratory Story" which helps exploratory testers answer the question, "How did it go today?" He'll suggest ways to describe and explain the critical and creative thinking that drives exploratory testing so that others have a better chance of understanding and appreciating the value of exploratory testing.

Tech Talk: Three ways to collaborate... now!

Ross Mortimer and Jon Bach, Quardev, Inc.

Now and then you might catch a movie from the 70's and 80's - especially one of those detective-centered ones where they show a squad room with desks, each with a typewriter and files stacked alongside. You may wonder... how did they get anything done without computers?

On the other hand, you may long for those days when there *was* no CRT - when you actually got a lot MORE work done by NOT having a computer on your desk.

The focus of this edition's Tech Talk is to get the best of both worlds by talking about three communication technologies other than email.

If you're looking for other ways to know what you need to know (and say what you need to say) on your project - and your inbox is overwhelming you anyway - then read on.

Instant Messaging: it's not just for chat rooms

Windows Live Messenger, Google Talk, Skype... these are all real-time messaging applications that are the "walkie-talkies" of project communication. It's often overlooked as a technology because so many of us associate it with being online in a chat room. But that's exactly what a project environment might resemble (and benefit from) - ultra fast communication, which is especially useful if you have a quick question for the program manager or developer. If you're confused as to what app to use, Meebo (www.meebo.com) allows you to manage the top 5 instant message applications through one easy-to-use interface.

Why Web when you can Wiki?

A wiki is a Web page you can freely edit. Imagine going to your favorite hobby site and being frustrated at a broken link on the page that points to an old file. Wouldn't it be cool to just delete it and replace it with another one right then and there? Wikis allow you to do just that, as well as post all kinds of content that might be useful to other people on the project - another form of "real-time" communication.

There's a short, excellent, fun, easy-to-understand video presentation produced by the cool folks at CommonCraft that can be seen on YouTube at http://www.youtube.com/watch?v=-dnL00TdmLY. To get started with your own wiki, go to www.wetpaint.com, www.pbwiki.com, or www.wikispaces.com

Write it together, right now

We're going to guess that you usually create a document and send it out to review, or receive a document that's wants your revision. But what if you could save time by doing both of those at once? Known as "collaborative editors," there are applications like Microsoft Office Live and Google Docs and Spreadsheets that aid in the creation of document that have a higher likelihood of having the right information right off the bat.

There is also CoWord (http://cooffice.ntu.edu.sg/coword/) a free application that creates this capability for your existing version of Microsoft Word.

All of these applications have one spirit behind them: to enable you to establish, cultivate, and take advantage of a "brain trust." Because the success of a software project is often about how to use resources (and how to use them NOW), you may find a new way of working outside of email that actually cuts down on the amount of stuff in your inbox.

Value-driven Consulting: Buzzword or Guideword

Jon Bach, Manager, Corporate Intellect, Quardev, Inc.

I haven't been a consultant long enough to know any consultant jokes, so I did what a consultant might do and went online to find some.

After reading several that were downright humorless, I got the feeling that everyone thinks the same about consultants:

1. They charge too much.
2. They don't know how to execute tasks they tell you to do.
3. They write reports that are too long.
4. They use buzzwords like "synergy" and "improvement opportunities" when simple words will suffice.
5. They tell you things you already know.
6. They abandon you after they get their money.
7. They're generally unethical.

I don't get it. I've had no formal training in how to be a consultant, but it seems to me that the practice of consulting needs to come from a desire to provide value, which, for me, turns out to antithetical to the consulting jokes.

Here's my strategy:

1. Charge a fair price.
2. Have some ideas about how to execute what you recommend.
3. Write reports that tell the story you need to tell.
4. Write simply.
5. Tell them what you found out and call them "findings."
6. Talk about what you hope to do next or how you see yourself being involved.
7. Discuss your code of ethics.

I do confess to doing something consultants do in almost every joke you will read about them - I use buzzwords sometimes.

Here's one you've already heard me use: "value-driven". To me, it's just a way of saying, "guided by the notion of what's important with respect to your values."

I use this because my first order of business with a potential client is to communicate - asking questions about their values, such as:

1. "What's important to you?"
2. "What does success look like?"
3. "What's the worst that could happen?"
4. "What would you like to do less of?"
5. "What would you like to do more of?"
6. "What do you wish were different?"
7. "What problems are you trying to solve?"
8. "What's working?"
9. "What would you start doing, stop doing or keep doing?"

As I get answers to these questions, I look for patterns that take the form of how values are communicated - things like innovation, leadership, fun, heroism, maturity, and integrity. I do this because that was an effective way for Quardev to come up with its values - we (the executive management team) became our own consultants and spent a day answering these kinds of questions.

We settled on 6 values that currently define our corporate culture, and values we want to preserve, whether we're 5 people or 500 people. The magic thing about that is if we ever hire an outside consultant to come in and help us with a problem, this may be a good starting point for discussions about why we are where we are. But hopefully, the consultant would ask: "how did you come up with these values and what happened along the way where you might have lost perspective?"

This is the approach I take on software projects. I like to speak to the very top tier of management, and I also like to spend time with testers side-by-side on the keyboard to see how testing actually gets done. Somewhere between the tester's communication of mouse clicks and keystrokes to the CPU and the CEO's communication of the company vision statement lies the problem - and it's usually one of pathology.

For example, if the company values "heroism," I watch to see if they value heroism in a pathological way which can be just as bad as valuing "maturity."

My brother once wrote an article titled "Enough About Process, We Need Heroes." When I started as a tester, this was a paper that influenced my approach to testing. I considered myself to have heroic tendencies, and the paper validated the value of that. I felt like a hero and it was the call to heroism that most spoke to me when becoming a tester. Years later, after trying to be heroic on many software projects - staying late, working smarter, anticipating needs, looking more deeply for problems than the established path - I began to burn out. Out of that fatigue came a paper idea: "Enough About Heroes, We Need Process." After all, process would cure the need for heroes to exhaust themselves!

These days, experience has made me come toward the center between heroism and process. Sometimes you want heroism, sometimes you want process. As I consult now, I'm on the lookout for too much heroism or too much process and what balance of each might be right for the company who's asked me to help with their problems.

An important book that helped me feel prepared (and at the same time, validated me despite my inexperience at the time I read it) is Jerry Weinberg's "Secrets of Consulting". It's refreshing, honest, and full of his style of consulting which flies in the face of convention (for example, he offers a money back guarantee for his work). What that book taught me most was that you can be of great value just by listening or getting people to talk about how they're going to solve their problem. It's important for me to find resources like these -- resources in books, but also in people. Robert Sabourin is a fellow software testing consultant who believes in finding what the client values and working from the top (executive) as well as from the bottom (the entry level intern helping test for the summer).

Rob set the example for me a few years ago when he called Quardev looking for a test lab that could meet requirements for one of his clients. Some were technical requirements, but he also had "soft" requirements that he called "values." For example, in our first few minutes on the phone, Rob's value-driven questions were his way of communicating what was important to him:

What was our approach to the work?

What kind of people did we have and how were they hired?

Were we the kind of lab to admit that we had limitations?

Could we work weekends?

Were we committed to helping him run meaningful exploratory tests as well as scripted tests he created? What kind of reports could we give and could we be ready to adapt if needed?

All of these were value-driven, but they were also value-seeking - to increase the likelihood that we could work together not only on this project, but perhaps follow-on projects, too.

I forget where I learned it, but an indicator of values between two companies who have never worked together can be exposed through a simple communication strategy during the pitch meeting. While other salespeople are polishing their PowerPoint presentations in the reception area, you be the one that simply takes out a sheet of paper during the pitch and ask: "Can we work right now on one of the problems you're having?"

No matter the technique, I want you to bear in mind that even if you do not know the approach or strategy or techniques or advice at the time you are asked to consult (or at the time you are interviewing consultants), it is the way you probe for values - thoughtfulness, enthusiasm, and an earnest interest in the work - that may lead you to find the best fit, sooner.

Calendar of Events - Quarter 2 2008

April 10, 2008

SPIN Seminar: Do We Really Need All This Testing?

Session-Based Exploratory Testing at Oregon's QA SIG

May 5-9, 2008

STAREAST 2008

May 14, 2008

QA SIG: Secrets of a Buccaneer Tester with James Bach

For more information about any of these events please see our Web site: www.Quardev.com/events

Quardev is looking for Great People

We are always looking for great people to join our team.

At Quardev you will work hard, you will enjoy a great working environment and benefits, and you will be building a solid, interesting, and flexible career where you can learn and grow.

If a career with Quardev sounds interesting, or sounds like it may be a fit for someone you know, check out our Careers page or contact us today via Quardev contact page.

We'd love to meet you!