‘QSM3’ Category Archives


Starting a Team

by Tony in QSM3

Endless books and articles have been written about how to select the right employee for the job or the team, with principles, guidelines, and checklists galore. Many of these are quite helpful, but they do tend to give the fairy-tale impression that if you choose the right princess and the right frog, they will live happily ever after. Whatever else it does, this model makes managers over-anxious about selecting people for teams, and under-anxious about exercising their control function throughout the life of those teams.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 21


The MOI model

by Tony in QSM3

Managers make two kinds of mistakes concerning the amount of control they exert over internal team affairs: too much or too little. Variable (Pattern 1) managers tend to intervene too little, placating the team.

Routine (Pattern 2) managers tend to overcorrect by intervening too much and blaming the team. For effective steering (as in a Pattern 3 organization) manager’s interventions or non-interventions into team affairs must be done on the basis of what the team is doing, not what the manager is feeling.

When choosing interventions, a good guide is the MOI model. This model says that when a team or individual isn’t functioning well, there may be a missing ingredient. It could be Motivation, Organization, or Information. Your job is to find out which and intervene accordingly.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 20


Reusable Teams

by Tony in QSM3

One of the arguments against reusable software is that it doesn’t come free. We cannot reuse just any old software that’s been slapped together; we must make an additional investment to render it truly reusable. The higher that investment, the more times we must reuse the module to recoup the investment.

A similar argument is often made against using teams for software development and maintenance. Teams do require a startup cost, and in many projects this startup is so long we never recover the cost during the life of the project. This argument, however, is not against the use of teams, but in favour of better management of team formation.

Even if management were poor, the cost of team startup could be recovered by reusing the teams over a series of projects. Unfortunately, only the better software organizations seem to reuse their teams. Given that breaking up successful teams is economic nonsense, why is it so common? Long before the days of software, people understood that the practice of dissolving well-functioning teams ultimately derives from insecure management.

Isn’t it time that your software organization woke up? Just as reusable components are the basic units in hardware and software development, the software team is the basic design unit for software engineering processes. The job of the manager is to create, nurture, and maintain the teams that can be configured and reconfigured into reliable, predictable projects. Without such teams, no software organization can ever emerge from a Variable (Pattern 1) or Routine (Pattern 2) culture.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 19


Temperaments of Teams

by Tony in QSM3

All temperaments find teamwork satisfying, but each for a different reason. The NT Visionaries, for instance, find great satisfaction in the quality that a team can produce. The SJ Organizers especially like the efficiency of well-functioning teams, while the SP Troubleshooters really enjoy the team as a crisis management tool. The NF Catalysts particularly like teams. They appreciate the communication, excitement, and hope generated by teamwork, and they especially like the way the team fosters the growth of its members.¬†Sometimes, it’s critical to reduce the elapsed time to locate the fault behind certain failures. In such cases, the manager can create parallel teams working to locate the same fault.

It’s quite easy to predict the reactions of each temperament to this suggestion. NF Catalysts may resist because they fear that the “losing” teams may be embarrassed. SJ Organizers are concerned with the inefficiency of two or more teams working on the same problem. NT Visionaries sometimes feel that the “best” team ought to be left to do the job alone. SP Troubleshooters, however, seem to relish the idea of making a game out of work.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 18


Informative Feedback

by Tony in QSM3

When it comes to doling out rations of appreciation, some mangers act like the Norwegian husband whose wife, on their tenth anniversary, asked if he loved her. He looked at her with a stern yet puzzled expression and said, “I told you I loved you when I married you, and if I change my mind, I’ll let you know.”

When I talk to managers about appreciating behaviour they want to reinforce, these strong, self-reliant men and women seem to turn into mush. The one ability they retain is the ability to produce rationalizations, such as

  • They should know if they’re doing well
  • They’re paid to do a good job. That’s appreciation enough
  • I’ll tell them at appraisal time (ten months from now)

One source of this fear is shame. As Tagore, the Nobel-prize winning Indian poet said, “Praise shames me, because I secretly crave it.”

Managers who are ashamed to want appreciation for themselves are unlikely to offer it to their own employees. It would help them to know this big secret: All people like to have their work appreciated.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 17


Choice of Expression

by Tony in QSM3

Culture makes language, then language makes culture. When you arrive at your destination but your bags don’t, the baggage handler shapes the context by asking “Did you lose your luggage?” This presupposition may have been originated by the airlines and taught quite intentionally in the handler’s training, but by now it’s completely unconscious. You can see that it is unconscious by replying, “No, you lost my luggage,” and observing the confused look of someone whose cultural assumptions have been violated. If repeated a few times, it also brings you a much better chance of effective handling of your problem.

The same influence is seen is software engineering cultures.

Organizations that use “bug language” develop and maintain software in a different way than those that use “fault language.” When someone says “I was late because there was a bug in my program,” you could change the frame a tiny bit by replying, “Oh, when did you put the mistake in the program?” Merely changing the language may not cause people to take responsibility for their creations, but it certainly helps. Once you reach a certain threshold, social pressure starts to act on those who continue to evade responsibility by using bug language.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 16


Irrelevant Management

by Tony in QSM3

Busy management is bad management. To engage others, you have to be available, and availability is cited by new managers as one of the three most important characteristics in a mentor. The other two characteristics are setting high standards, and orchestrating developmental experiences, both of which also require a lot of engaging. Irrelevant managers keep busy doing irrelevant or unimportant things, or things they should be having others do.

If done well, management is a tough job, which is why they pay is premium. However, there will always be those managers who want to get paid for the hard parts of management work without actually doing them. Offering feedback is one of those hard parts. Under a performance appraisal system, placating or irrelevant managers can think, “Well, I won’t bring that up right now. I’ll save it for the performance appraisal in December.” Over the months, feedback accumulates to be dumped on people when it is too large and too late to do anything by create resentment and opposition. Managers appear to be doing management work, but they are simply creating trouble.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 15


Curing the Addiction to Blaming

by Tony in QSM3

You cannot possibly prohibit blaming one hundred percent. People blame when their self-esteem is low, and there’s no way you can ensure that self-esteem is always high for everybody in the organization. However, managers can create conditions in which blaming cannot thrive, even should it spout.

The key to a non-blaming organization is openness. Like the repulsive creatures that live under rocks, blaming thrives in the dark. The first requirement for a blame-proof environment is an open-door policy all the way to the top. Openness only at the top is not sufficient, but must be part of a general openness policy. Openness is the enemy of error, and blame is the enemy of openness.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 14


Curing the Addiction to Placating

by Tony in QSM3

Placating occurs when self-esteem is low. Raising self-esteem – through management style, training, and affirming feedback – can help to block placating, but in itself cannot prevent it. For instance, IS customers often have high self-esteem, but not in the context of computers. Feeling technically incompetent, they must humble themselves to the sole source of technical help.

To understand their situation, picture yourself stranded in a remote hotel, and suppose that each meal offers a menu with only one selection. Having no other choice if you don’t want to go hungry, you eat what the chef has prepared. If the chef is rude to you, you are polite to him. If he is rigid, you are accommodating. If he demands a high price, you bite your tongue and pay. This no-choice restaurant more or less describes the situation of the captive customer or an in-house software organization.

There is no particular reason for a restaurant with a captive clientèle to maintain its excellence, which leads to the following principle: To prohibit placating, give customers alternative sources of services.

Although this principle is the foundation of American capitalism, it seems to unhinge the mightiest managers of internal IS organizations. They certainly agree with the principle, but always for the other guy. The know (extending the dining metaphor) that if the customer ever has an alternative she may try to retaliate for the rude chef. In the IS world, when the customer finally decides to retaliate, she pronounces the dreaded word outsourcing. Outsourcing is to IS managers what a silver crucifix is to Count Dracula. But contrary to the internal manager’s trepidations, outsourcing may be the best thing that ever happened.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 13


Curing the Addiction to Incongruence

by Tony in QSM3

In the nineteenth century, heroin was put into use as a cure for morphine addiction. It was successful at ending morphine addiction so long as heroin was available because heroin was more powerful. Of course, the morphine addiction then became a heroin addiction, which wasn’t much progress. This replacement dynamic is being repeated in the twentieth century with the use of methadone. And, oh yes, morphine itself was thought to be a cure for opium addiction.

In the software world, FORTAN was put forth as a cure for the addiction to assembly language. COBOL was designed to eliminate the dependence on programmers, since executives would be able to write their own code. Spreadsheets were going to replace COBOL, but now many executives spend more time fiddling with their spreadsheets than doing executive-type work.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 12