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.

Becoming a Change Artist

Get the Free “Change Your Life!” ebook

Do you want some great actionable tips and advice on how to improve your life from many top personal development experts (including me)?

You can download the free ebook “Change Your Life!: Experts Share Their Top Tips and Strategies for Reaching Your Highest Potential” by clicking the link below and signing up to the mailing list.

Click Here to Get the Ebook

There are many great personal development tips from dozens of authors and course creators. I’m sure you’ll get a lot of value from the free ebook and I’ve included my own best advice as well.

The free ebook is part of the Better You Bundles for Good promotion at the end of July. There will be dozens of courses and ebooks, worth thousands of dollars, all for one low price. If you are serious about becoming your best self, you won’t want to miss this opportunity. The Better You Bundle only lasts for 4 days so make sure you check your emails to be notified of the sale.

The best part is that 25% of the proceeds from the sale are going to support Courageous Kitchen, a charity helping refugees in Bangkok. As little as $100 per month can get a family off the streets in Thailand, so we can make a big impact with this promotion.

Here is the link for the ebook again.

Get the Ebook

Enjoy the book!

Change Artist Challenge #12 Developing Yourself

A book (or a blog) can give you only what the author has to tell. But the learning that comes through self-knowledge has no limit. To learn through your own self-knowledge is to know how to listen, how to observe, and therefore you learn from everything: from music, from what people say and the way they say it, from anger, greed, ambition. - Jiddu Krishnamurti


The biggest benefit from change artistry comes when you start teaching other people to be change artists.

The Challenge
Your challenge is to make up a change artistry challenge of your own, one that will give you practice in an area you need most. Accept your own challenge and offer it to others.

Source

This is the last of the dozen challenges from Becoming a Change Artist. Additional exercises in the book may help you, but from now on, your job is to practice, practice, practice.

Challenge 9: Organizing The Grand Tour

When you stop learning, stop listening, stop looking and asking questions, always new questions, then it's time to die... - Lillian Smith

One of the most important sources of ideas for change is ideas that have already worked in a similar organization. Moreover, one of the most supportive acts you can perform is to ask someone to teach someone else what they do well. When people teach other people about what they are doing, it forces them to become aware of their own processes.

The Challenge
Your challenge is to organize a tour of your work place for other change artists. Have the people in your workplace teach the change artists "what we do well that others might want to imitate."

Experiences
1. I thought this was a silly assignment—until it paid off with a savings of about $40,000 a year in our printing operation. One of the programmers on the tour had never seen an actual high-volume printer in operation. Once she understood the way things worked, she easily changed one of our major applications so that weekly printing was significantly faster.

2. We found that their performance analyzer did things that we never imagined. We felt a bit foolish using the crude tool we had concocted, but I was proud that we didn't defend it in the face of an obviously superior product (change artist training helped with that). With more than a little help from their team, we switched tools—and, as a side benefit, no longer had to maintain our homemade kludge.

3. The effect on my group was fantastic, and that really surprised me. First they grumbled about all the trouble it would be to prepare for the tour, but then they started cleaning house. It was like when my mother comes to visit—I clean the toilets and put away things that have been laying out for months. The group did the same thing with their code and their supporting documentation. I don't know if the visitors got anything out of their visit, but they sure saw a clean operation. And—this is the best thing—it stayed clean. Actually, I do think they got something out of it, because we've been asked to give four more tours to groups where someone wants to clean house.

4. Well, we didn't learn much, and they didn't learn much, except that we do things pretty much the same way. I guess that's confirming. And I learned that they're nice people. Perhaps in the future we'll be able to help each other, and that feels good even if we don't have any specific current benefits to show.

Reference

This post is part of the series, adapted from the book, Becoming a Change Artist.

Trying to Change a Dysfunctional Organization

Today, I'm continuing my problem-solving series with a letter from Rory, asking how to change his organization. Rory's situation should be familiar to anyone who has been literally thrown into "testing" in a dysfunctional organization.

Rory
Your books have already helped me and are continuing to help me, but I have a specific scenario at work right now and I have what I think is a good solution, but I'd really appreciate your take on the matter.

I seem to be very unhappy in Variable or Routine organizations, and I really want to work in a Steering organization, but as I've learned from you they are few and far between.

Jerry
By Variable, Routine, and Steering, Rory is referring to the cultures described in my Quality Software series.

Rory
Therefore, I want to try my hand at changing the organization I work in because a) I'll be happier (I think) and b) I think the company will be better off as well. However, after re- reading Chapter 12 of "Becoming a Technical Leader" I'm very mindful of not inflicting help. I went through an exercise where I documented the situation objectively, and then observed my feelings about it. I will include what I documented below my signature. I wanted to share it with you because I thought you might find it interesting, but I'm also interested in any help you could offer on the matter.

Rory's Exercise
The situation:
- Product Manager mentioned a new scenario to me one day before the product was supposed to be released to production.

Jerry
Strike one. Strike two. And Strike three. Out already.

Rory
- The application is currently in the staging environment where testing is supposed to center around verifying the configuration is correct.

Jerry
Huh?

Rory
- The new scenario revealed a bug.

Jerry
Was anyone surprised by this?

Rory
- The developer in charge of the part that was broken updated the stored procedures to account for this.
- After testing it again there were new errors and the feature did not work at all.

Jerry
Was anyone surprised by this?

Rory
>- After an additional change the new scenario is still not working
>correctly and an old scenario is no longer working correctly.

Jerry
Was anyone surprised by this?

Rory
More context:
- The work for this feature was handed down by a manager. Each programmer was assigned a certain area of the application to code.

Jerry
Meaning the manager had already done design work?

Rory
- I started testing this on my fifth day at the company after the design reviews were completed and I report to a different manager than the programmers.
- The product manager reports to a different manager as well.
- We have never held a retrospective on the feature.
- The feature design is not documented.

Jerry
Was anyone surprised by this?

Rory
How I feel right now:
frustrated, sad, stressed, unhelpful, confused, detached from team, hopeless

How I feel about the feelings:
- I feel a little silly for letting something that is not life or death frustrate me or make me sad.
- I feel weak for not knowing how to change the situation or myself so that I don't feel these things.

Jerry
Don't try to get rid of the feelings. Instead, learn how to use them productively. If after all this, you weren't feeling frustrated, sad, stressed, unhelpful, confused, detached from team, then there would be something wrong with you.

As for hopeless, well, there isn't much hope there. There's an enormous amount to do to change an organization that acts like you've described, and you can't do it alone. So, the first step for you is to quietly see if you can recruit a few allies. If you can't, then you should leave and find a better organization.

Rory
- I feel afraid that I may lower my professional integrity in order to increase my happiness which in the long run may make me less happy.
- I feel incompetent for feeling confused.

Jerry
No, in fact, only an incompetent person would fail to feel confused in such a situation.

And just how do you mean, "lower my professional integrity" in order to increase your happiness? In my experience, people who lower their professional integrity soon become terribly unhappy that they did it. So don't!

Rory
A brief summary of what I think bothers me the most:
We aren't working together as a team on this issue, and I feel unrelated to the problem and to the other people working on it.. I believe we're working in an inefficient way which doesn't fulfill my need to become more competent at delivering quality software. My autonomy is compromised, because I feel like the developers are using me to re-test something just to check that the code fix they made worked instead of checking it themselves before taking my time. (I feel guilty for feeling that way.)

Jerry
If it's true, then there's no reason to feel guilty.

You need to be talking with people about your feelings. That's the way to find allies--or to find out there are none to be had.

Rory
I also want to sincerely help the company deliver a great product and spend as little time and money as possible to do it, and I don't see us finding ways to improve.

Jerry
You have to find others who see things that way.

Rory
What I would like to do:
If I were an outside consultant (and I was asked to help) then I would probably schedule a meeting with the actual people involved and hold a retrospective. Then I would go from there.

Jerry
That's too big a chunk from where you are. You need to recruit support, one person at a time. If you're seen to be doing this, and then you're labeled as "subversive" and/or "not a team player," then the place is hopeless.

Rory
However, I was involved in this, and I think that some people would be offended that I'm asking them to come to another meeting.

Jerry
Again, don't try to get everybody. Change happens one person at a time.

Rory
Based on this I think my best option right now is to ask someone who was not involved in the feature and who seems to have a lot of respect and admiration to schedule and facilitate a retrospective for us.

Jerry
A good idea, but it won't happen if you're the only one supporting it. Develop allies!

Hope this helps.

Change Artist Challenge #8: Applying The Principle of Addition

The peculiar vanity of man, who wants to believe and who wants other people to believe that he is seeking after truth, when in fact it is love that he is asking this world to give him. - Albert Camus

Satir's Principle of Addition says that people change behavior by adding new behaviors, rather than getting rid of old ones. The reinforced behaviors are done more often, leaving less and less time for behaviors not reinforced.

The Challenge
Your challenge is to practice giving affirmations for behaviors you wish to increase. This can be in the form of an e-mail note, a card, a phone call, a brief office visit, a comment in the corridor. It must be done, however, directly to the person, not through some third party.
Each and every day, give one affirmation to one person.

Experiences
1. This forced me to pay attention to what people were doing.

2. This was really hard! Something deep inside me got caught in my throat when I started to form an affirmation of someone. It's a good thing I had a support group to help me figure out where that came from. I'm still not very good at it, but I can get the words out.

3. I thought I was already doing this, so it would be a really easy assignment. It turned out that nobody recognized when I was giving an affirmation, because I always cut the corners off it by some little joke, or discount.

4. I'm pretty good at this, in person, so I decided to start sending little cards to people who had done something that helped one of my change projects. Boy, was I surprised at how delighted they were! Something about a card made them really sit up and take notice; maybe it showed that I was thinking of them when they weren't present, and I took that little extra time to do this in a way that wasn't the easiest (e-mail). Maybe that made it seem extra important.

5. I made a list of people I ought to affirm, and made five copies, one for each day. I would check each one off the day's list so I would have a measure of how well I was doing. My goal was to be able to do everybody in one day by the end of the week. There were 14 people on the list, and my scores for the five days were 4, 7, 6, 11, 14. I was very proud of myself, and on Saturday I showed the list to my Will (my husband) and explained the assignment. He read over the list and told me I had forgotten someone. I was devastated: What good was a perfect score if it wasn't the whole list? But I couldn't for the life of me figure out who was left off. On Sunday, in church, I was still thinking about it and not really listening to the sermon. Will leaned over and whispered in my ear: "You." At our church, some of us stay after the service for a discussion of the sermon. God must have been watching over me when He sent the sermon that day because the subject was "Love thy neighbor as thyself." I understood that if I didn't love myself very much, loving my neighbor as myself didn't mean very much. I'd say I had a religious experience because of this exercise.

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.

Change Artist Challenge #7: Being Fully Absent

 Being Fully AbsentWhoever is in a hurry shows that the thing he is about is too big for him. - Lord Chesterfield

During the Great Plague of 1666, Newton was forced to go home for a holiday when schools closed in London. While idling under a tree, he got the basic idea for his Theory of Universal Gravitation.

During the heyday of telephone exploitation (1877), Alexander Graham Bell got married and took a yearlong honeymoon in Europe! While there, he had his grand vision—not for the telephone, but for the telephone system.

So much for not being able to leave a project for vacation! As your powers as a change artist grow, it's easy to get the grandiose idea that the world can't change without you. This challenge is a challenge to that idea. It's also a way to trick you into taking care of yourself.

The Challenge
Your challenge is to take a week away from work, and when you get back, notice what changed without you being there. You must not do anything about your change artist work for a whole week, but notice what thoughts come into your head, or what apples fall on it.
Do you think you can't do this? Then you have a different assignment, suggested by Wayne Bailey: "If you're going on a week-long vacation and feel the project cannot do without you, then take a two-week vacation."

Experiences
1. We took two weeks and went to Hawaii. It was our first vacation in seven years—really since our honeymoon. I'd always dreamed of a Pacific island paradise, and we found it. The first few days, Shanna and I drove all over the Big Island like tourists. It was interesting, but it wasn't the vacation of my dreams. Then we just starting frolicking on the beach, eating, laying about in the shade, eating, really talking to each other, eating, swimming, and eating. After about seven days of this bliss, I woke up early one morning and realized that though I hadn't consciously thought about work at all, I suddenly had a complete vision of how our process improvement program had to be restructured. Shanna was still asleep (it was real early), so I slipped out for a walk on the beach. When I got back about two hours later, I had the entire thing worked out in my mind. I didn't even have to write it down—it was so clear that I knew I couldn't forget it. Then I put it out of my mind and enjoyed the last three days of our vacation in paradise. When I got back to work, I had a new and revitalized organization. More important, I had a new and revitalized marriage.

2. I decided to spend a week hiking a segment of the Appalachian Trail. I hadn't done any backpacking for a couple of years, so I had to take out all my equipment, replace some of it, and reconsider everything. While doing that, I realized that I needed to do the same thing at work. I was so eager to get started that a little voice inside me said to forget the hike and get back to work. But I resisted. I was able to use the hike—even though it rained most of the time—as a metaphor for the changes I had to make at work. Come to think of it, that was probably because it rained all the time.

3. I stayed home and played solitaire, did jigsaw puzzles, and cleaned the house. I also rearranged my thoughts. Thank you for this assignment.

4. I went to Spain, where I could refresh my school Spanish. I spent a week in Madrid and a week in Barcelona, with a few side trips into the country. Perhaps it was living in another language for two weeks, but I didn't think of work at all. When I came back, I discovered that they had gotten along very well without me, and were eager to show me some of the nifty things they'd accomplished. At first I was depressed, thinking that I wasn't as essential as I had thought. Then I was elated when I realized that I had done a good job of preparing them to keep improving things when I wasn't there. I guess that's really the change artist's job, isn't it.

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.

Change Artist Challenge #6: Being Fully Present

It always seems to me that so few people live—they just seem to exist—and I don't see any reason why we shouldn't LIVE always... - Georgia O'Keeffe

In order to be a successful catalyst for change, you must learn the art of being fully present. To be fully present, you must:
1. Pay full attention to the speaker.
2. Put aside any preconceived ideas of what the speaker is going to say.
3. Interpret descriptively and not judgmentally.
4. Be alert for confusions and ask questions to get clarity.
5. Let the speaker know that he/she has been heard, and what has been communicated.




Here are a number of common hindrances to being fully present:

   • Ignoring: lack of attention (looking elsewhere, fidgeting), boredom, disinterest, pretending to listen

   • Selective listening: hearing only parts

   • Sidetracking: changing the subject (without proper transition); telling your own story; making light of, with inappropriate humor

   • Evaluative listening: agreeing or disagreeing before the explanation is finished

   • Probing: asking too many questions (from your frame of reference) with little sense of the person

   • Interpretative listening: explaining what's going on based on your own motives and behavior

   • Advice giving: offering solutions; focusing too much on content

The Challenge
Your challenge is to pick one habit that keeps you from being fully present, and focus on reshaping that habit in all your interactions.


Experiences
1. I decided to try going through a meeting without telling any jokes. I didn't actually make it all the way, but they seemed to appreciate my joke more, when I finally told it.

2. I didn't really know what to do, as I thought I was a good listener. I got a support person who told me that I should stop reading my mail during meetings. That really surprised me, because I thought myself so good a listener that I could read mail and listen at the same time. Besides, it kept me from interrupting. My supporter told me that even though I might be hearing everything that was said, my reading made it look like I wasn't paying attention, or at least didn't care what was being said.

3. I'd read about not giving solutions during review meetings, but I was strongly opposed to the idea. It just didn't make sense to me. But, since I had to do this assignment, I decided to try doing one review without offering any solutions. I did have two solution to offer, but the author came up with one of them a few minutes later, before I said anything about it. Actually, I guess it was pretty obvious, and if I'd said it, he probably would have thought I considered him stupid. I saved the other until after the meeting, and it was really appreciated. It seemed to be a pretty good review, actually one of the better ones I've ever attended.

4. I have to tell you that I'm known around here for being the person who can get anything out of anybody with my penetrating questions. I decided to try a new tactic. Whenever I found myself thinking of a neat question, I caught myself and asked, instead, "What else do you want to tell me?" I got just as much information as I ever get, so maybe I'm not such a great questioner as I thought. Or maybe I'm greater—I can do it with just one question!

5. I looked at whoever was speaking. Every time. I had been missing a lot, not seeing facial expressions and posture. I think I'll do it again.

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.

A Universal Starting Point for Problem-Solving

By popular request, I'm going to hold my next Change Artist Challenge until next week to give some of my readers a little more time to catch up.

This essay should also be helpful to change artists, who often have to start their work by defining or redefining a problem that's presented to them. It's adapted from Chapter 5 of Exploring Requirements 1: Quality Before Design.

How can we reduce the great variety of potential starting points to a single solid platform for exploring requirements? A possible solution is to regard every design project as an attempt to solve some problem, then reduce each starting point to a common form of problem statement.


A problem can be defined as
a difference between things as perceived
and things as desired.

[For a full discussion of problem definition, see Donald C. Gause and Gerald M. Weinberg, Are Your Lights On? How to Know What the Problem Really Is.

Figure 5-1. A problem is best defined as a difference between things as perceived and things as desired.

This definition can serve as a template measuring each idea for starting a development project. If the idea doesn't fit this definition, we can work with the originator to universalize the idea until it does.

Universalizing a Variety of Starting Points
Let's see how this universalization process can be used to reduce six different starting points to a common form of problem definition.

Solution idea
Perhaps the most common starting point is thinking of a solution without stating the problem the solution is supposed to solve. In other words, the idea doesn't say what is perceived (and by whom) and what is desired, so it doesn't fit our definition of a problem. Here are a few examples we've experienced.

1. A marketing manager told a systems analyst, "We need sharper carbon copies of our sales productivity report." Rather than immediately begin a search for a way to produce sharper carbons, the analyst asked, "What problem will sharper carbons solve for you?" The manager explained that the carbons didn't make very good photocopies, so the salespeople had trouble reading them. "So," the analyst confirmed, "you need one clear copy for each salesperson, and you're now making multiple copies of the report we give you?" Eventually, through such give and take, the problem was redefined as a need to provide timely and clear comparative information to a sales force of four hundred—something readily accomplished by slightly modifying an existing on-line query system. The final design didn't have sharper carbons. It didn't have carbons at all. Not even paper.

2. In another case, a university dean said, "We need a way to attract more students." The dean never said why they needed more students, and each faculty member hearing the statement formed a different idea. Some thought "more students" meant getting more outstanding students. Some thought "more students" meant being able to support more teaching assistants in certain departments. Still others thought "more students" meant the dean wanting to fill the vacant dormitory space.

After arguing for months about the best way to get more students, the faculty finally learned what the dean really wanted: to create the impression in the state legislature that the school was doing a higher quality job by increasing the rejection rate of applicants, so the university appropriation would increase. Once this goal was understood, the faculty approached a solution in several ways, none of which involved an increase in student enrollment.

Technology idea
Sometimes we don't have a problem in mind, at all, but literally have a solution in hand: a solution looking for a problem. When tearing off those perforated strips on computer paper, have you ever felt there ought to be something useful to do with them? The perforated strips are the solution, and the problem is "What can we use them for?" After thirty years of searching, Jerry bought Honey, a German Shepherd puppy, and suddenly he discovered the problem his solution was looking for. Computer paper edges, crumpled up, make perfect litter for puppy nests!

When a new technology comes along, it's often a solution looking for a problem. The Post-It™ note developed by 3M is a conspicuous example. The semi-stickiness was originally just a failed attempt to produce an entirely different kind of adhesive. Instead of simply discarding it as another failed project, the 3M people thought of problems for which such semi-adhesive properties would provide a solution. They created Post-It™ notes, but the solution-to-problem process didn't stop there. As soon as Post-It™ notes appeared in offices, thousands of people began seeing problems they would solve.

Some of the high-technology companies we work with are dominated by this kind of solution-to-problem starting point. In effect, their problem takes the form of the following perception and desire:


Perception: We own a unique bit of technology, but others don't want to give us money for it. For example, a chalk company buys rights to a new vein of chalk that has exceptional purity and strength. To most people, however, chalk is just chalk.

Desire: Others will pay us a great deal of money for the use of this technology in some form. For instance, if the company can create the idea of Superchalk in the public mind, the unique purity and strength become an asset of increased value.

Such a problem statement allows the technology to become a kernel around which many designs can be built. Without it, technology firms often make the mistake of believing that "technology sells itself." Although this slogan may be true in certain cases, usually it's an after-the-fact conclusion. Want to turn a solution into a problem requiring it? Ordinarily, you'll need an enormous amount of requirements and design work. For example, how will you make teachers believe they can't really teach well without Superchalk?

Simile
Many product development cycles start with a variety of metaphorical thinking—a simile, or comparison, as when someone says, "Build something like this." Although the customer may emphasize "this," the job of the requirements process is to define "like."

For instance, Maureen, the leader of a software project, told her team she wanted a new user interface "like a puppy." "First of all," she elaborated, "people see a puppy and are immediately attracted to it. They want to pet it, to play with it. And they aren't afraid of the puppy, because even though it might nip them, or even pee on them, puppy bites aren't serious injuries, and puppy pee never killed anyone. Also, you can't really hurt a puppy by playing with it."

Although the team couldn't yet build a system with this requirement, playing with the simile did inspire them to ask probing questions. "How about housebreaking and obedience training for the puppy?" a teammate asked.

Maureen thought a bit, and said, "Yes, the interface should be trainable, to obey your commands, so it becomes your own personal dog."

"Okay," asked someone else, "will it grow up to be a dog, or remain a puppy?"

"That's easy," said Maureen. "It will stay a puppy if you want it to be a puppy, but if you prefer, it will grow up to be a real working dog doing exactly what you say."

"What kind of working dog?"

"A watchdog, for one thing. It should warn you of dangerous things that might happen when you're not paying attention."

Someone else got into the spirit by asking, "What about a sheepdog? It could round up the 'sheep' for you, and put them safely in the pen. And guard them from anyone stealing any."

By this time everyone was involved, and the requirements process was running like a greyhound, though not necessarily in a straight line, as when someone asked, "How about fur? Should it be a longhair or a shorthair?" Nobody could figure out what fur meant for an interface, though the question did lead to an extensive discussion of touch screens and other interface hardware they had never previously used. Eventually this tangent was clipped by someone observing, "Our tail is starting to wag the dog."

The simile is excellent as an idea-generation tool, but eventually the requirements group has to groom their ideas into prize-winning form, which requires some idea-reduction tools. You know when the simile has become a bit dog-eared when you can no longer make fruitful connections between it and your product. It's important, though, to keep it going a bit past the point where it becomes ridiculous, just to be sure you've generated enough ideas.

Norm
Many people do not consider themselves metaphorical thinkers, believing they think more concretely. In the requirements process, they would more likely say, "Here is a chair. Design a better chair." or "Here is ordinary chalk. Design a superchalk." In fact, the norm is also a metaphor, seeming literally "close" to the thing desired. The great danger of using a norm is the constriction on our thinking once we identify what would almost satisfy the customer.

Another great danger is making one big leap in logic to the end result. Instead, starting with a norm and working by increments tends to protect us from the colossal blunder. The Wright brothers, for instance, were bicycle builders, and they used many of the norms from bicycle construction to create their success at Kitty Hawk.

A third danger is starting with the wrong norm, which could prevent us from making a great leap forward when one is possible. Orville and Wilber Wright did use a rail to launch their plane, but they didn't become the first heavier-than-air fliers by putting wings on a locomotive (Figure 5-2).

Figure 5-2. Don't let the norm dictate the form. If the Wright brothers had been train builders, they might have specified a plane that looked like this hybrid, which might have been on the right track, but would have had a hard time getting off the ground.

Mockup
Suppose we agree to use a chair for a norm. Unfortunately, your mental picture of a chair may be very different from mine. A mockup is a way to protect against this ambiguity by providing an actual scale model of a product. Moreover, we can benefit by using the mockup to demonstrate, study, or test the product long before the product is actually built.
A mockup serves as a norm, when no norm exists, or when none is available. As such, it has all the advantages and disadvantages of a norm. It also has the advantage and disadvantage of being a fantasy product. When we use a mockup, we aren't restricted to what exists, but on the other hand, we can easily mock up a product that could never actually be built.

In printing, and in computing, for example, the mockup is often in the form of a layout of printed matter, or material on a screen. The customer and users can point to the layout and say, "Yes, that's what I want," or "No, what's this doing here?" What we are actually testing with the mockup is the customers' emotional responses—their desires. In effect, a mockup says, "This is what we think the product's face will look like. Let's see how you react to this!"

Name
Many ideas for design projects simply begin with a name: Create Superchalk. Build me a table, chair, pencil, clock, elevator, steering wheel, speedometer, or bicycle. Although the name provides a quick and common connection for all participants to grasp, names also come with a large baggage of connotations. As we've seen, each word is worth a thousand pictures, and each connotation of a name may introduce implicit assumptions.

For instance, Jerry spent thirty years searching unsuccessfully for a use for computer paper edges largely because the name itself narrowed his thinking unnecessarily. Our colleague Jim Wessel observed that his four-year-old daughter isn't so limited. She cuts these strips into smaller pieces and calls them "tickets." We would do well to emulate the four-year-olds who have little trouble making up names for objects lacking conventional ones.

 Further Reading










The Exploring Requirements books can be obtained from a variety of retailers. Go to my website and chose your favorite source of books or eBooks.

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.

Change Artist Challenge #4: changing a relationship

Your fourth challenge will be to undertake changing a relationship. The purpose is to apply some of your learnings about congruence and conflict.

The Challenge
Choose one relationship you have with another person that's not all you would like it to be. It could be a good friend with whom there's one thing that annoys you but you've suppressed it, or something you like that you'd like more of. It could be a work associate with whom you're not on the terms you'd like to be. Again, don't start by tackling the most difficult relationship you have. If you finish changing one relationship, you are free to do another, and another..., so don't worry that it's too small.

As before, find an interested change artist, or associate, or some willing person, meet with the person and explain the change you want to make. Seek assistance in planning how to go about changing this relationship—assistance with ideas, in checking your ideas, and possibly in practicing in a role play. Then carry out your plan with the actual person.

This challenge will especially give you a chance to confront the difficulties you have in the presence of strong (or potentially strong) emotions in others. After all, you won't know in advance how the other person will respond to your attempt to change the relationship. They might cry, or go into Chaos, or get involved in a conflict with you over it, or become incongruent in a variety of ways. How will you handle yourself in those situations? Will you fail to take a risk because you anticipate one of these reactions?

Experiences

1. I decided to get to know my boss better as a person, and not just as a "boss." I asked her to lunch. She was a bit taken aback, but once we agreed it would be Dutch treat, she was okay with it. We found out that we both have a passion for softball, but play in different leagues. That gave us a lot to talk about, and since then I've given her the benefit of the doubt when she comes out with some edict I don't understand.

2. I'm responsible for upgrading all the Mac software for my department, and one of the users has been a pain in the derriere for me ever since I got this job. I decided to sit down with him and ask him how he felt about the service he'd been getting. He said that people seemed to avoid him when he had problems, and he was pleased that I'd take the time to sit down with him. I was able to show him a few things that prevented trouble, and cured some things he hadn't even bothered to complain about. He's still a pain, but just in the neck, and I can deal with it. At least it's a little higher up. (smiles)

3. I have an employee who drinks excessively. I had been avoiding the topic because I didn't really know what to do. I paid a visit to our employee assistance program, and they gave me some booklets and some coaching. Next time he came in to work drunk, I knew what to do, and didn't pretend it wasn't happening. He had to confront the impact he's having on his job, and he's now working with employee assistance. He may not solve his drinking problem, but if not, I can handle it.

4. I did this a little backward. I decided to change a relationship back to what it was before. Grace and I worked together for a couple of years, and were very good friends. Then I took a transfer to a different project and moved to another building. I guess I was feeling guilty, like I deserted her—which isn't the way a good friend should behave—so I avoided seeing her or even calling her. I decided just to go over and pay her a visit, like we used to do when we were in neighboring cubes. She wondered where I'd been, and we're back to being great friends. All "her" feelings about me "leaving" were in my imagination.

5. I'd been playing golf with our hardware salesman for a couple of years—him taking me to his country club almost every Saturday. I never felt good about it, like it was somewhat unethical. So I told him that I couldn't play with him anymore unless I paid my way. He objected, saying it wasn't costing him anything, since his company was paying for it. I told him that was the point. He said okay. Now we still play golf, but I feel a lot better about it.

6. I'd been locked in a struggle with Harmon for almost a year over which CASE tool we should use in the organization. I decided to approach him from the point of view that our conflict was only helping those reprobates who didn't want to use any CASE tool. We made a pact that we would join forces to get some CASE tool going, somewhere. We actually flipped a coin to see who would help whom. I lost, so I swallowed my pride and helped him sell his team on using the tool he liked. Once we joined forces, they were a pushover. He was going to help me sell my team on the tool I liked, but by this time I like his tool just as well—actually a little better.

Reference

Remember, these challenges are taken from my book, Becoming a Change Artist.

I've wanted to put up a cover picture, but nothing I've tried seems to work with Blogger.

Change Artist Challenge #3: Changing Nothing is Doing Something

Of course I am idle, but I am not idle by nature; I simply haven't yet discovered what I can do here...  - Sophie Tolstoy

The purpose of the next challenge is to find out what's driving you to change things, and what happens if you don't respond to that drive in the usual way.

The Challenge

Next time you're part of a team or group effort, sit back, listen, and observe. Your job is not trying to change anything. (You're not trying to prevent change. If the others want to change something, just let it happen. Otherwise, you'd be trying to change what they're attempting to do.)

Take particular notice of your urges to change things, and what happens when you don't do anything about those urges.

Experiences

Here are a few experiences of other change artists who accepted this challenge to do nothing at all.

1. Wow! I couldn't do it! I lasted almost three whole minutes. I resisted the temptation to open the window, or to ask someone to do it. I resisted the temptation to move the flipchart so everyone could see it. I resisted the temptation to move over one seat to make room for a latecomer.

But when Jack stood up and grabbed the marker pen (AGAIN), I couldn't resist suggesting that someone else should take a turn. It was out of my mouth before I knew it! But I just HAD to say it!

2. (The same woman as the previous experience.) After my first miserable failure, I decided to try again, the next day. I got through the mechanics a lot more easily—the window and the flipchart and the chairs—and with somewhat more difficulty, I let Jack grab the pen again. I was on a roll, and I managed to keep it up for almost fifteen minutes. When I finally did say something about the direction the meeting was taking (I just didn't notice what I was doing), the other people reacted as if I was the President of the United States. They gave me their full attention, let me finish everything I had to say, and then did exactly what I proposed.

I think there's a clue there for me. (duh) I'm working on it, and I'm going to try this again.

3. I didn't think this would be very hard for me. I would just sit in the meeting and do what I usually do—keep my mouth shut and observe. I was doing a good job of this when all of a sudden I realized that I was changing things in my mind about once every thirty seconds. Then I said nothing about any of them, and I found myself getting angry that nobody else was doing anything about them.

Aha. Were they doing exactly what I was doing?

4. (The same man as the previous experience.) Armed with my new insight, I worked out a plan for the next meeting. I sat in my usual way, quietly fanning my smoldering anger and frustration. When I got to the proper amount of emotional heat—not so much that I wouldn't be able to control it—I said a sentence that I had written down and practiced: "Is there anything about this meeting anyone would like changed?"

The reaction was instantaneous, and the changes poured out. The rest of the meeting went very differently from our usual meetings, though I didn't say another thing.

5. This was a pretty boring exercise for me, so I had to do something to occupy my mind. I decided to try to observe emotional reactions, because I had always thought our meetings were rather flat and unemotional, but our consultant told me they weren't. I noticed lots of things that I never saw before. For instance, two of our folks were really suffering—I didn't know from what, so I asked them about it after the meeting.

Was that a violation of the assignment? If it was, I don't care, because I learned some things I had never even suspected before, and the quality of my relationships with two members of the team have gone up several notches.

The Meta-Challenge

Here's a challenge about the challenge:

When you take this challenge, I'd love to read about what happened and what you learned. Hundreds of readers would like this, too. Besides, it will probably do you much good to sit down for a few minutes and recall your experience. Good writing practice, too.
     For more about Becoming a Change Artist, you can read the book and try the entire sequence of exercises. 

Change Artist Challenge #2: Making One Small Change

     I report a conversation with a colleague who was complaining that he had the same damn stuff in his lunch sack day after day.


     "So who makes your lunch?" I asked.

     "I do," says he.
     When I heard his response, I thought, "This is about the smallest, least difficult, safest, change I can imagine. As such, it makes a perfect test for beginning change artists, a way of "measuring" how difficult it will be for them to change anything.
     So, your next challenge will be to undertake a change project of your own, but to seek support in making this change. The purpose is to launch your career as a change artist by experiencing some of the theoretical learnings in the "real world," but in as small and safe a way as possible.

The Challenge
     Choose one small thing about yourself you want to change. Novice Change Artists tend to be too eager for their own good. If you want to eat a whole elephant, start with single bite. If you finish one change, you are free to do another, and another—so don't worry that it's too small.
     Find an interested change artist, or associate, or some willing person, meet with them and explain the change you want to make, and contract with that person for the kind of support you think you need to accomplish your change. Check with your supporter periodically to update him/her on your progress.

Experiences
     Let's examine a few instructive experiences of other change artists accepting this challenge to make one small change.

1. When I have a hot idea in a meeting, instead of blurting it out, I write a little note to myself and wait a couple of minutes. I noticed that about 60% of the time, somebody else comes up with essentially the same idea. Then, when I support the innovator, the idea has a very great chance of being adopted.
     I've increased the number of my ideas that get adopted, but I'm not getting credit for them. At least not directly. But several people have told me that I've really become a leader in meetings. This was a surprise, because I thought they would consider me a leader when I had the most ideas—and they didn't. My supporter explained that I seemed more "statesmanlike," more calm and more respectful of others.

2. I take a break every hour when I'm alone, or when I'm in meetings. This was really hard to do. I didn't want to interrupt anyone, but my supporter gave me some good suggestions about how to "test the waters" before doing it in a meeting.
     To my surprise, most people welcomed the breaks, most of the time. I learned that people (including me) often don't say what they want, and this has transferred to the practice of polling groups more often to find out how they feel about what's going on in meetings.

3. I posted hours when I would be uninterruptible, and hours when I would always be available for interruptions. At first, people didn't respect these hours, as they didn't believe I would really do it. I couldn't say no to anyone, so my supporter actually came into my office from 4 to 5 one day (the busiest time) and coached me on how to dispatch people to the posted schedule. This worked pretty well for me, but it was a strain for some of them. I then realized that 4 to 5 would be a good time for drop-in time, so I changed the schedule.
        After two more schedule adjustments, the thing seems to be working. I've learned that it's impossible to plan anything perfectly if it involves other people—you have to try it out, then be prepared to adjust a couple of times.

4. I keep my wallet in a different pocket. The first time I reached for my wallet, I was in an absolute panic—I was sure I lost it.
     My supporter pointed out to me that this may be the way people feel when I change things in the system and don't tell them—even if I do tell them, because they have the habit of finding things in certain places.

5. I made a healthier lunch for myself. I learned that I don't like "healthy" food. My supporter told me that I'm too healthy anyway, and the kind of lunch I made was rather fanatic. I guess she's right.
     It made me aware that I'm a perfectionist, but that it's not in the nature of human beings to be perfect. If I eat a pickle now and then, or a cookie, the world won't come to an end. Also, of course, if my teammates make a mistake in their code from time to time, or don't design something perfectly, we'll survive.

Meta-Challenge
     Here's a challenge about the challenge:
     When you accept this challenge, I'd love to read about what happened and what you learned. Hundreds of readers would like this, too. Besides, it will probably do you much good to sit down for a few minutes and recall your experience. Good writing practice, too.
     For more about Becoming a Change Artist, you can read the book and try the entire sequence of exercises.

Change Artist Challenge #1

In an earlier post, I said that in order to be more effective introducing new techniques and technology, we needed to become practitioners of the art of change, as described in the seventh volume of my Quality Software ebooks: Becoming a Change Artist. In that book, I present a series of challenges taken from our change artistry workshops. In this and subsequent posts, I plan to present each of these challenges, roughly one every week. If you take each challenge, I guarantee you will substantially increase your change artistry.

Your first challenge will be to undertake a change project of your own, of a very specific nature. The purpose is to have you experience the Satir Change Model and some of its emotional consequences.

Challenge #1
Your challenge is to go to work tomorrow in a different way.

Experiences
The first experience of this assignment is what goes on in your head and heart when you first read it. Here are a few typical examples:

1. I immediately experienced panic (Chaos). What if I was late to work? I've already found the optimal way to work, because I've been driving it for four years. Suddenly, I understood exactly how it felt being in the Late Status Quo, and I knew that I would have more consideration for the people whose work I was trying to change.

2. My first thought was "impossible!" I simply could not think of a single alternative to the well-developed route I took to work. After all, there was only one bridge across the river. What was I supposed to do, swim? I decided I simply wasn't going to do it, which allowed me to relax. Then I realized that the assignment said 'in a different way,' not 'by a different route.' I hadn't even understood the foreign element, and I had rejected it.

Now consider some of the comments after doing the assignment:

3. I decided to go to work wearing a tie, which I've never done before. The reaction of other people was totally unexpected, both the number of people and their intensity. I learned how easy it is to be a foreign element, and that you can't change just one thing.

4. I went to work with a different attitude—more positive. The whole day was entirely different. It's a much better place to work than it was last week.

5. In driving by a different route, I got lost and discovered a part of the city I'd never seen before. I was late to work, but it was fun. I decided to go a different way each day, and I've been doing it now for six months. I like it.

6. I always go to work in a different way every day, so I wasn't going to do the assignment. Then I realized that a different way for me would be to go the same way. So I drove the same way every day for a week and learned a couple of things. First of all, the same way isn't the same way, if I pay attention. Second, I'm not the same every day. Some days I can't tolerate waiting for the light at 35th Street, but other days I welcome the time to reflect about things. I used this learning to reintroduce a proposal that had been rejected last month. This time they loved it.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Your next opportunity to participate in some change artist training is our Problem Solving Leadership Workshop (PSL). It takes place in Albuquerque, New Mexico, USA
August 28-September 2, 2011

After that, your next opportunity will be the 11th Annual Amplifying Your Effectiveness Conference (AYE) in Cary, North Carolina, USA
Sunday, October 30 – Thursday November 3, 2011
http://www.ayeconference.com

Beyond Agile Programming

After being in the computing business now for more than half a century, one thing worries me more than almost anything else: our lack of a sense of history. In order to contribute my bit to addressing that problem, I've posted this essay—one that's sure to infuriate many of my readers, including some of my best friends. So first let me tell you how it came about.

While reformatting my book, Rethinking Systems Analysis and Design for e-booking, I noticed a few places that might have needed updating to present realities. The version I was using was more than 20 years old, from just after the peak of excitement about "structured programming." In particular, there was a whole section entitled, "Beyond Structured Programming." As I contemplated updating that section, it dawned on me that I could almost update completely by substituting the name of any more recent "movement" (or fad) for the word "structured.

 I also knew how smart most of my readers are, so I figured they would see the same possibility without my updating a thing. Instead of changing the book, I decided to update the section and publish it on this blog. Why? Because I think it shows an important pattern—a script where only the names have changed over at least five decades. So, here is the section with "agile" substituted for "structured," just as "structured" had been substituted for some other fad a generation earlier.

The Restructured Essay
Before I proceed further with the task of rethinking systems analysis and design, I'd like to express myself on the subject of another great "rethinking" in programming—the agile programming revolution. Although this essay was written a generation ago (now two generation), and the agile programming "revolution" is now an exhausted fad (for most programmers), most of what this essay says still applies—though to the next rethinking fad, and the next, and the next. I believe it will still apply long after I'm no longer writing new editions. Why? Because our industry seems to require a new fad every decade to keep itself from being bored. So, just apply the lessons to whatever fad happens to be dominating the computer press at the time you're reading this.

Before anyone becomes overly enthusiastic about what the rest of this book says, I want to take stock of what this great agile rethinking has done. I don't claim to be starting a new revolution of the magnitude most of the fads claim, so I'd like people to realize how slow and how small the agile programming movement has been, in case they think this book is going to make much difference.

My own personal stock-taking on the subject of agile programming is based on visits to some forty installations on two continents over the past ten years, plus a few hundred formal and informal discussions with programmers, analysts, managers, and users during the same period. Because of the conditions under which these visits and interviews took place, I would estimate the sample is quite heavily biased toward the more progressive organizations. By "progressive," I mean those organizations more likely to:
• Send staff to courses
• Hire outside consultants, other than in panic mode
• Encourage staff to belong to professional organizations, and to attend their meetings.
Consequently, my stock-taking is likely to be rather optimistic about the scope and quality of the effects of agile programming.

The first conclusion I can draw from my data is this:
Much less has been done than the press would have you believe.
I interpret the word "press" very loosely, including such sources as:
• Enthusiastic upper management
• The trade press
• The vendors and their advertising agencies
• The universities, their public relations staffs, and their journals
• The consulting trade.
Although this may be the most controversial of my observations, it is the most easily verified. All you need do is ask for examples of agile programming—not anecdotes, but actual examples of agile behavior and agile-produced code. If you're given any examples at all, you can peruse them for evidence of following the "rules" of agile programming. Generally, you will find:

a. Five percent can he considered thoroughly agile.

b. Twenty percent can be considered to follow agile practices sufficiently to represent an improvement over the average code of 1990.

c. Fifty percent will show some evidence of some attempt to follow some "agile rules," but without understanding and with little, if any, success.

d. Twenty-five percent will show no evidence of influence by any ideas about programming (not just agile) from the past twenty years.

Please remember: these percentages apply to the code and behavior you will actually see in response to your request. If you ask software organizations at random for "agile examples," about two-thirds will manage to avoid giving you anything. We can merely speculate what they do, and what their code contains.

My second conclusion:
There are rather many conceptions of what agile programming ought to look like, all of which are reasonably equivalent if followed consistently.
The operative clause in this observation seems to be "if followed consistently." Some of these conceptions are marketed in books and/or training courses. Some are purely local to a single installation, or even to one team in an installation. Most are mixtures of some "patented" method and local adaptations.

My third observation:
Methods representing thoughtful adaptations of "patented" and "local" ideas on agile programming are far more likely to be followed consistently.
In other words, programmers seem disinclined to follow an agile methodology when it is either:
1. Blind following of "universal rules"
2. Blind devotion to the concept: anything "not invented here" must be worthless.

My fourth observation:
I have other observations to make, but now I must pause and relate the effect these observations have on many readers, perhaps including you. I recall a story about a little boy who was playing in the schoolyard rather late one evening. A teacher who had been working late noticed the boy and asked if he knew what time it was.
"I'm not sure," the boy said, "but I know it isn't six o'clock yet."
"And how do you know that?" the teacher asked.
"Because I'm supposed to be home at six, and I'm not home."
When I make my first three observations about agile programming, I have a similar reaction—something like this:
"These can't be right, because if they were right, why would there be so much attention to agile programming?"

In spite of its naive tone, the question deserves answering. The answer can serve as my fourth observation:

Agile programming has received so much attention for the following reasons:
• The need is very great for some help in programming.
• To people who don't understand programming at all, it seems chaotic, so the term "agile" sounds awfully promising.

• The approach actually works, when it is successfully applied, so there are many people willing to give testimonials, even though their percentages among all programmers may not be great.

• The computer business has always been driven by marketing forces, and marketing forces are paid to be optimistic, and not to distinguish between an idea and its practical realization.

In other words, the phrase "agile programming" is similar to the phrase"our latest computer," because each phrase can be used interchangeably in statements such as these:

• "If you are having problems in information processing, you can solve them by installing our latest computer."

• "Our latest computer is more cost effective and easier to use."

• "Your people will love our latest computer, although you won't need so many people once our latest computer has been installed."

• Conversion? No problem! With our latest computer, you'll start to realize savings in a few weeks, at most."

So actually, the whole agile programming pitch was pre-adapted for the ease of professionals, who have always believed "problems" had "solutions" which could be mechanically applied.

My final observation is related to all of the others:
Those installations and individuals who have successfully realized the promised benefits of agile programming tend to be the ones who don't buy the typical hardware or software pitch, but who listen to the pitch and extract what they decide they need for solving their problems. They do their own thinking, which includes using the thoughts of others, if they're applicable. By and large, they were the most successful problem solvers before agile programming, and are now even more successful.

There's yet another lesson in all this that's much bigger than agile programming or any new hardware or software or process:

Our profession contains few, if any, easy solutions. Success in problem solving comes to those who don't put much faith in the latest "magic," but who are willing to try ideas out for themselves, even when those ideas are presented in a carnival of public relations blather.
Based on this lesson, I'd like to propose a new "programming religion," a religion based on the following articles of faith:

• There's no consistent substitute for a thorough understanding of your problem, though sometimes people get lucky.

• There's no solution applicable to every problem, and what may be the best approach in one circumstance may be precisely the worst in another.

• There are many useful approaches applicable to more than one problem, so it pays to become familiar with what has worked before.

• The trick to problem solving is not just "know-how," but "know-when"—which lets you adapt the solution method to the problem, and not vice versa.

• No matter how much you know how or know when, some problems won't yield to present knowledge, and some aspects of the problem nobody currently understands, so humility is always in order.

I realize writing a book is not the most humble thing a person can do, but it's what I do best, and how I earn my living. I'd be embarrassed if anyone took this book too seriously. We don't need another "movement" just now, unless it is something analogous to a bowel movement—something to flush our system clean of waste material we've accumulated over the years.

Where to read the original
If you want to check on my historical work, you can find the original essay (and many others) in Rethinking Systems Analysis and Design, which is an ebook on Smashwords (where you can probably see it in the free sample) and Kindle and Barnes and Noble.


Problem-Solving Leadership Workshop
Reminder: The second (and last) PSL Workshop for 2011 will take place in Albuquerque, New Mexico, USA, August 28-September 2, 2011. Only a few places left for participants, so for more information, see <http://www.estherderby.com/workshops/problem-solving-leadership-pslhttp://www.estherderby.com/workshops/problem-solving-leadership-psl>

The Assumption of Fixed Requirements

Note 1: This post is extracted from Chapter 9 of my book, CHANGE: Planned and Unplanned.

Note 2: This book was written for project leaders in high-tech industries, but writers are also project leaders, and writing certainly requires great skill and precision. For writers, requirements may originate from publishers, agents, and for-hire customers—any of whom can cause unending grief by changing those requirements for a writer who has assumed they were fixed.

Until recently, the computing industry seems to have avoided the subject of requirements the way a debutante might avoid the subject of indigestion. We knew such things existed, but if we didn't think about them, perhaps they would simply take care of themselves.

Many of the classic early papers in software engineering were based on the position:

This is how we would design and build software (if we had unchanging requirements.)

[For writers: each of us has her/his own process for writing, but for many of us, that process is also based on having unchanging requirements. If someone changes our task, we may be thrown off our game, and into write-stopping turmoil.]

For instance, many of the early papers on structured programming were based on the Eight Queens Problem, a problem of fixed definition with no input whatsoever. Many papers on recursive programming were based on the Towers of Hanoi problem, another problem of fixed definition with no input whatsoever. The more recent Cleanroom methodology has the same basis: "The starting point for Cleanroom development is a document that states the user requirements." The following quotation from Parnas and Clemens shows how deeply this assumption runs, even in the most sophisticated process designers.

Usually, a requirements document is produced before coding starts and is never used again. However, that has not been the case for [the software requirements for the A-7E Aircraft]. The currently operational version of the software, which satisfies the requirements document, is still undergoing revision. The organization that has to test the software uses our document extensively to choose the tests that they do. When new changes are needed, the requirements document is used in describing what must be changed and what cannot be changed. Here we see that a document produced at the start of the ideal process is still in use many years after the software went into service. The clear message is that if documentation is produced with care, it will be useful for a long time. Conversely, if it is going to be extensively used, it is worth doing right.

Parnas and Clemens describe the benefits of returning after design to create a requirements document as if it had been present from the beginning.

In the light of all this literature, it's easy to understand why so many software engineering managers have made the mistake of believing they should have unchanging requirements before starting any project. This model or belief is what I call the Assumption of Fixed Requirements, an assumption that is a misreading of these classical works. These classics were not addressing the entire process of software engineering, but only selected parts of that process. What they are teaching us is how to translate requirements into code, once we have reliable requirements.

Translating requirements into code is an essential part of software engineering, and it is the part that has received the most research attention over the past decades. Because of that attention, however, it is no longer the most difficult part of the process. Many organizations know how to do this part quite well, but the quality of their products does not adequately reflect their coding prowess.

In recent internal studies of serious quality problems, three different clients of mine arrived at quite similar conclusions. They divided the sources of the most serious problems into a number of categories, including coding and gathering requirements. In all cases, coding contributed least of all categories to quality problems, and my clients would perhaps do better to work on the less glamorous job of improving their logistics processes. Perhaps these rather advanced organizations are not typical of all software engineering organizations. They still have a lot to learn about coding and especially design, but in each case, the majority of their serious problems stem from requirements.

Software engineers and their customers perceive quality differently, and this table accounts in large part for that discrepancy in perception. Over the past decades, engineers have seen coding faults drop dramatically as a result of their quality improvement efforts. The customers, however, have not seen a comparable decrease in the number of requirements problems, and so do not perceive the same increase in quality as the engineers, who are paying attention to their own priorities—which don't happen to coincide with their customers' priorities. The engineers need to learn that they will never become an Anticipating organization by getting better and better at coding—even though that was the improvement process that brought them as far as they've come.