Showing posts with label information. Show all posts
Showing posts with label information. Show all posts

Thursday, May 31, 2018

Can a Boss Take Corrections From Subordinates?

We were asked, "can a boss take corrections from subordinates?"

Certainly, some bosses can, but there are ways you can increase the chances of changing your boss, or at least your boss's mind.

I think that if the subordinate offers “corrections,” the leader is less likely to respond less well than if the offer is for “information.” That principle actually goes both ways. Most people are somewhat reluctant to take “corrections.”

So, if you are asking how you, as the underling, can “correct” your boss, I suggest you learn how to offer (not “give”) information. The boss can then decide whether or not to act on this new information, and how to do it. 

Again, this goes both ways. Leaders do better offering information than correction.


What Did You Say?: The Art of Giving and Receiving Feedback Revised Second Edition

So, study the feedback process and become proficient. That will be your best chance, but be prepared for failure. Some people simply will not change, even if banged on the head with a two-by-four.

If your boss happens to be one of those frozen people, it will be up to you to do the changing.

Maybe change your behavior. 

Maybe change jobs.






Wednesday, July 27, 2016

Common Mistakes in Managing Testing


  1. In my book, Perfect Software and Other Illusions About Testing, I present a list of a dozen common mistakes made when managing testing. 

    Here are the first six items on the list. 







    1. Not honoring testers: If you aren’t going to believe what the testers uncover, either you have the wrong people or you need to get serious about helping them build their credibility. Testing is never just a matter of hiring and hoping.

    2. Over-honoring testers: If you let them make your decisions for you, then you should step down and let them earn the manager’s salary.

    3. Scapegoating testers: Even worse than over-honoring testers is pretending to honor them—manipulating them to give you the answers you want, appearing to act on that “independent” assessment, then blaming them later if that assessment turns out to be damagingly wrong (or taking credit if it turns out to be right).

    4. Not using the information gleaned from testing or other sources: If you’re going to ignore information or go ahead with predetermined plans despite what the tests turn up, don’t bother testing. (Actually, it can’t really be considered information if you don’t use it.)

    5. Making decisions that are emotional, not rational: Not that you can be perfectly rational, but you can at least try to be calm and in control of your emotions when you make decisions.

    6. Not evaluating the quality of test data: Numbers are just numbers. Learn to ask, “What was the process used to obtain this number?” “What does this number mean?”


      The remaining six mistakes can be found in the second chapter of the book.

      Or, you can purchase the book as part of the entire eight-book set of The Tester's Library at a bargain price.



Thursday, June 30, 2016

The Most Important Aspect of Software Testing

On a public forum, the question was, "What are the most important aspects of software testing?"

A number of good answers were given, but all tended to emphasize finding errors. To me, that's a limited view of testing. I would say, instead, that the most important aspect of software testing is to provide information about the state of a software product. That is, not just errors, but what's good and bad about the product. And, by the way, what's just mediocre.

For instance, the speed of the product might not be in error, but could be good, bad, medicre, or perhaps acceptable to some or all possible users. It's the tester's job to document that.

Or, there may be a feature that works okay, but is not so easy to use. Is that an error? Who knows, but in any case, it's a fact that the sponsor of the project will usually want to know about, and providing that information is the tester's job.

One more example: if a tester merely finds and reports errors, small wonder that developers feel that testers are nattering nabobs of negativity. Test reports should describe what's good—what's wonderful—about a product, and testers must never forget that part of their job.


You can read more about important aspects of testing in my book, Perfect Software And Other Illusions About Testing.

Saturday, July 23, 2011

Change Artist Challenge #5: Being The Catalyst

Look abroad thro' Nature's range.
Nature's mighty law is change.
- Robert Burns

Although change artists often work as prime movers, they more often work through understanding natural forces and creating slight perturbations of Nature. In this challenge, you will practice facilitating the change projects of others, using various ways of empowering from the position of catalyst. In chemistry, a catalyst is a substance that added to a reaction accelerates that reaction by its presence, without itself being changed by the reaction.

A human catalyst is someone who rouses the mind or spirits or incites others to activity with a minimum of self-involvement—in other words, by empowering others. For people to be empowered to change their organization, the MOI model tells us that the following ingredients are required:


Motivation
• self-esteem
• a value system and a vision held in common
• a sense of difference between perceived and desired

Organization
• mutuality of support, based on personal uniqueness
• a plan for reducing the perceived-desired difference
• a diversity of resources relevant to the plan


Information
• a systems understanding of what keeps things from changing
• an understanding of empowerment versus powerlessness
• continuing education appropriate to the tasks

Often, only a single ingredient is missing, but the person who doesn't know which one it is can feel completely disempowered. The recipe suggests which ingredient might be missing. A change artist who supplies that missing ingredient can catalyze change with minimal effort.


The Challenge

Your challenge is to facilitate other people's change projects, approximately one per week, for at least two weeks. You should attempt to be a catalyst, for change, not the prime mover for change. To be a catalyst, you should involve yourself

• as effectively as possible

• in the smallest possible way

• without depleting your capacity to catalyze other changes

If possible, use each ingredient of this recipe for empowerment at least once. Keep notes in your journal and be prepared to share learnings with the group you are catalyzing.

Experiences
1. A group in the shipping department asked me to help them run their planning meetings. I said I would do it if they enrolled two people in our facilitation class, and that after taking the class, they would work alongside me. After one meeting, they are now facilitating their own.

2. I led a technical review of the design of a very controversial project, and apparently I did a good job because I got three other invitations to lead difficult reviews. I did lead two of them, but I decided to try being a catalyst on the third. I told them I wouldn't lead the meeting, but I would play shadow to a leader of their choice and we would switch roles if their leader got in trouble. She didn't.

3. One of my groups wasn't using—or even attempting to use—the new configuration control system. Ordinarily, I would have ordered them to use it, with threats of reprisals. I thought about the minimum thing I could do—with no force and no blaming—to get them moving. I decided to call them in for a meeting and give them the problem of how to get them moving. They told me they just didn't have time to switch their partially developed project to the new system. I asked them how much time they would need. They huddled and came up with a two-week extension to their schedule. (I had been afraid they would say two months.) Since they were off the critical path, I said they could have the two weeks, but only if they switched to the new system. They actually did the job in one week, and in the end, they made up four days of that—partly, at least, because of using the better tool. I've now used this consultation method several more times. "What would you need to give me what I need?" turns out to be a great catalyst. I like being a catalyst much more than being a dictator.

Source
These challenges are adapted from my ebook, Becoming a Change Artist, which can be obtained from most of the popular ebook vendors. See my website <http://www.geraldmweinberg.com> for links to all of my books at the major vendors.