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.

Readers Pay, but Kindle Doesn't Pay Authors

One good reason many international readers should buy my books through Smashwords—save lots of money.

Amplify’d from davidgaughran.wordpress.com

Amazon Hold Back The Growth Of E-Books Around The World

Posted on July 11, 2011 by davidgaughran

Writers often wonder why the growth of e-books is so much slower in the rest of the world.

There are a number of reasons for that, but one big factor is the $2 surcharge that Amazon levies on all e-books in most international countries.

This charge is levied by Amazon, and kept by Amazon, and has nothing to do with taxes.

This charge is applied whether the user downloads e-books through their Kindle or not, and whether the user even owns a Kindle or not. Read more at davidgaughran.wordpress.com

 

See this Amp at http://amplify.com/u/a17p1k

The future of book publishing

Kris slices up yet another repetition of a stupid old prediction.



Masterful writing and thinking, as usual from Kris. If you're interested in the writing/reading business, you should follow her blog. Absolutely.

Amplify’d from kriswrites.com

The Business Rusch: Slush Pile Truths

Kristine Kathryn Rusch

Why am I calling Felten’s piece ridiculous?  Aside from the fact that he says the same thing writers from places like NPR to The Daily Beast have been saying for two years, he shows no understanding of the book business whatsoever.  If he actually gave the subject some thought and did a little research, then perhaps he would have come to a different conclusion.

His premise is pretty simple: without book publishers, readers won’t be able to find the good stuff in the middle of all the crap.

Jeez, dude.  Those arguments were old one hundred years ago when reading ceased to be the right of the rich and well educated, and trickled down to the masses. Anyone ever wonder why we ended up with a divide between “high-brow literature” and “low-brow crap”? It was because the cognoscenti no longer controlled what people read, therefore the cognoscenti lost a great deal of their power, so the cognoscenti had to make up words to distinguish between the “approved” books and that stinky genre stuff. Read more at kriswrites.com

 

See this Amp at http://amplify.com/u/a171n4

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

If you're a writer, or hope to be, please read this article:



http://www.redhammer.info/news/agent-publisher/ http://amplify.com/u/a14tub

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.

Writers Are Losing the Fight Again

Dean Wesley Smith has written another scathing post about "agents" trying to scam writers in "the new world of publishing." Please read it: http://www.deanwesleysmith.com/?p=4096&cpage=2#comment-9194



It's a terrific post, which it has in common with all Dean's posts, but this time he made one little mistake, so I had to write a comment on his blog.

But there are so many comments (as there should be, and you should read them all), you might miss mine, so I'm repeating it here.


Dean,

I’ve been thinking about this whole scheme and decided it’s not a scam at all. It’s actually a terrific idea, with only one slight flaw.

All that it needs to make it a fair deal is to make it symmetrical. In particular, the agents have the right idea about expenses. This is a business, and it’s quite right that the partners in such a deal should be reimbursed for their expenses before any royalties are distributed.

So, I’m looking for an agent who will write a contract with me where s/he gets expenses and so do I. Let’s see, what are my expenses?

Well, there’s toner for my printer.

And several reams of paper.

And the printer itself.

And the computer.

And the software.

And my office, and its furnishings.

Let’s see. What have I forgotten. Oh yes, there’s about 20 years of schooling so I could learn how to write. Let’s figure conservatively about $50,000 per year. It’s probably a lot more, but we don’t want to take advantage of the poor agent, so we just have $50,000 times 20, which seems to come to $1,000,000 before I could write a word.

Now of course, my schooling was a long time ago, so if I hadn’t spent that money learning how to write, I could have put it into US Treasury bonds and easily earned, say, 6% on the average. And I finished my schooling roughly 50 years ago, which means the $1,000,000 would have doubled roughly 4 times since then, making $16,000,000 today.

Don’t you just love this calculating “expenses”? (That's an important part of the new agent scam contract.)

The way I figure is I’d happily sign with an agent who’d give me $16,000,000 up front to cover my expenses.

Or, since I’ve published roughly 100 books, I’d be willing to take $160,000 up front from any agent wanting to contract with me to handle a book of mine.

So, agents, if you’re reading this, better hurry and get your cash in hand and contact me before all those other agents beat you to the punch.

Yes, Dean, I’m sorry, but you’re just going to have to write a retraction saying what a good deal these new agent ideas are for writers. Agents, please insist on it.

Oh, and by the way, here are two of my most recent eBooks, which you can sample at http://www.smashwords.com/profile/view/JerryWeinberg?ref=JerryWeinberg and purchase them there, or at Amazon or Barnes and Noble.

Project Mercury

I was one of the workers on Project Mercury. My job was to design and implement the space tracking network, and particularly the multiprogrammed operating system that ran the entire network. Many readers have asked me about Mercury, so here's a little something courtesy of SPACE.com:


Source SPACE.com: All about our solar system, outer space and exploration

"Smashwords vs. Kindle?" Are Your Lights On?

Yesterday, Don Gause and I posted out book on problem definition, Are Your Lights On?—a book many have called a "classic."

Today, I ran across a perfect example of why the lessons in the book are so useful. On one of the writers' forums in which I participate, a reader posted a query entitled Smashwords vs. Kindle? Here it is:



Gemma, a writer, asks:

Can someone tell me what the benefits or advantages of publishing on Smashwords might be when Amazon, the number five most visited site in the USA, (according to Alexa.com) provides such a successful solution and so much higher traffic? To compare, Smashwords ranks 2,751 in terms of daily traffic. Amazon's "query popularity" is 86 out of 100, versus only 38 out of 100 for Smashwords. Amazon visitors spend an average of eight minutes on the site and view 8.8 pages while Smashwords visitors spend six minutes on the site and view 6 pages.

Still, I have found the folks on this list to be a savvy bunch, so I suspect there must be some hidden advantages or benefits of which I am unaware. Can anyone who has published on Smashwords help me out by sharing some benefits? I am about ready to put up some titles on Amazon and had decided to stick exclusively to that platform and to B & N, but maybe I am cutting off potential sales by not posting on Smashwords.

Perhaps someone else has the answer already:

One of the things Are Your Lights On? teaches is to use all the information you have. In this case, I had an earlier answer from another author, "Linda."

Linda offered this answer:

Yes, Amazon offers worldwide traffic, but Smashwords offers retail eBook outlets that we do not get at Amazon.  My books are directly at Amazon Kindle.  And then I have also added a number of my books and my husband's at Smashwords to take advantage of the retail outlets they distribute to.  At Smashwords I opt out of Amazon, and will continue to do so.  But Smashwords has not only their direct website, but the books are sent to the ebook retailers-- Kobo, Nook, Diesel, IPad, etc.  I love being able to check daily on my Kindle sales and be paid monthly by Kindle.  Royalty payments and sales via the Smashword's distributors are slower, depending on the retailer.

So the advantage is having more retail distribution (and hopefully sales) by putting your books at Smashwords, in addition to having them at Amazon Kindle.

Even good answers may not be complete.

Are Your Lights On? teaches:

"If you can't think of at least three things that might be wrong with your understanding of the problem, you don't understand the problem."

Well, I really liked Linda's answer, but applying the Rule of Three, thought about how it could be improved.


Jerry adds to Linda's answer:


First of all, listen to Linda. She and her husband use exactly the same strategy Dani and I use. [Note from AYLO: Answers don't just have to be right, they have to be convincing. Supporting Linda's excellent answer is the first job a consultant has to do to be effective in this case.]

So, my first answer to Gemma is this: You've done your research, and done it well, but the data you've gotten happens to be irrelevant to this problem. The traffic each site receives doesn't really matter. What matters is selling books. Suppose Site A receives 1000 hits/day, and the average stay is 10 clicks, and they sell one book per day. Site B receives 10 hits per day, and the average stay is 1 click, and they sell two books per day. Which is better for you, the writer, A or B?
The answer is "none of the above." Why, because you don't have to choose. You can put your book on both A and B's sites, and sell three books.

On to the details:

Once you have the right problem definition, the solution is often trivial, as above. Since I can't verify my assumptions about Gemma's problem definition, I can add some other facts to support various definitions, such as,

1. A book sold at Smashwords gets a higher royalty than the same book sold at Kindle. For each $7 of Kindle royalty, the same sales on Smashwords earn $8.

2. Smashwords, as Linda says, distributes to many retail outlets that would be a pain to reach individually, and perhaps not worth the small sales they generate. Through SW, I reach them with zero extra effort.

3. In addition to extra retailers, I reach readers who don't use Kindle. As Linda says, SW formats automatically for just about every eReader known to humanity, again, at zero extra effort.

4. I don't know how many SW sales I would have through Amazon if SW weren't available, but I do know that through SW, I earn about 2/3 of what I earn through Kindle, so instead of, say, $1,000 through Kindle, I earn about $1,666 through the combined offering. (plus another $100 or so through Barnes and Noble, which you should also use.)

5. SW has a "coupon" feature that Amazon doesn't offer. That allows me to offer special price deals for a day, a week, a month, or whatever period of time I wish, for whatever price I wish. Very useful for marketing, and for reviewers. On Kindle/Amazon, a price change takes about three days to start, and three days to remove, and is seen by the whole world. On SW, the change takes place instantly, and can be removed instantly. I can offer it to one person, or 10, or 100, or to the entire internet world. My choice.

6. And, if you offer a book on SW, you can pull the book(s) any time you want. So, if it turns out you don't like something about SW, you're out of the deal instantly, whenever you want--not cost, no fuss. It's totally under your control.


Bottom Line

Yes, the book-selling business can be complicated, but this one's probably a no-brainer when you have all the facts—if I have the right problem definition. In a real consulting situation, I'd be able to talk with Gemma and verify that I understand her problem. Since I don't have access to her, I'm guessing that her implicit problem definition is wrong from the start.

Gemma, I think it's not "Smashwords vs. Kindle," but "Smashwords and Kindle" (and Barnes and Noble, and any other sites you wish, as long as they don't restrict your publishing elsewhere).

Perhaps the definition would have been better stated: "How can I achieve the best sales results for my eBook?"

P.S.

You can sample Jerry's books on Smashwords, including Are Your Lights On?, then buy them there or at any other site you might prefer. See and sample all my books on Smashwords (more going up all the time).

It Flies! Da Vinci's Dream Comes True

URL:  http://www.npr.org/blogs/krulwich/2011/04/11/135300971/...

by Robert Krulwich



This is not a trick. There are no invisible strings, no post production video fixes. What we have here is a graceful, flapping, unfeathery machine that looks and flies like a seagull. It was built by a team of engineers at a company called Festo in Germany, which specializes in factory automation, and for years now they've been doing what Leonardo dreamed of when he sat on those hills near Florence sketching birds: they copy from nature's designs.



Watch the movie! See the artificial bird fly! - Jerry

See this Amp at http://amplify.com/u/bywp6

How Fast is Fast Writing?

See my guest post on Ellis Vidler's blog: "How Fast is Fast Writing?" http://ow.ly/4ycjq

Learned Helplessness

My e-pal, L.M. May has written the most striking, useful blog post I've seen in a long time. L.M. says: "The following essay is about fiction writing and learned helplessness, ..." but L.M. "used to work in the software industry as a software tester," and so writes this essay with much the same qualifications I have—and combines the two main foci of this blog: writing and software creation. So, if you're a writer, or a software professional (or both), this essay is for you.

What is "learned helplessness," and what does it have to do with writing and software making? I'll leave the writing part to L.M., but I'd like to cover the software side briefly, before I send you off to read the essay, at:

http://lmmay.com/2011/04/03/fiction-writers-and-learned-helplessness/

L.M. quotes the Wikipedia definition, "Learned helplessness…means a condition of a human being or an animal in which it has learned to behave helplessly, even when the opportunity is restored for it to help itself by avoiding an unpleasant or harmful circumstance to which it has been subjected."

The essay was inspired by the reactions of some writers to the enormous technology-induced changes taking place in the publishing industry. (See, for example, my posts of Feb 27 and Feb 28, on this blog.) These writers had learned that the only real way to publish their books was the traditional way, as books printed on paper by a few large publishing companies. Mostly, they had put their entire business of writing in the hands of agents who dealt with these companies for them. Now, with e-publishing, they have an avenue for bypassing all those "helpers" (and their fat fees), but some of them, many of them, have learned to be helpless, and violently oppose the idea of standing on their own two feet as adults.

How does this relate to software professionals? If you really don't understand, I'm not sure I can explain it to you. To put it briefly and bluntly, have you ever allowed the "grown-ups" (the salespeople, the managers, the customers) to override your professional judgment because you felt helpless?

Did you ever agree to build some code in two months when you knew it would take at least five—and then silently take the blame when you made it in four?

Did you ever allow unqualified people to override your technical decisions, thinking you couldn't do anything about it?

Have you agreed to undertake testing software that was (to you) obviously unready for testing (or even patently untestable)?

Even if you've never experienced such events, have you ever watched others trapped by them, and not known how to help them?

If you know about such matters in your work, read L.M.'s essay about the psychology of learned helplessness, then come back here and be a voice in the conversation that follows.


And why here? LM explains:
"I keep my comments section off due to family and work commitments, but Dean Wesley Smith and Gerald M. Weinberg offered their blogs as sites where people could discuss this essay amongst themselves.  I will be checking in as often as I can to both their websites over the next few days to answer any questions."

I think we should divide the labor, with the writers' comments going to Dean's site (http://www.deanwesleysmith.com/) and the software people laying out their thoughts here. But you can choose where to hang out—both places, if you wish—and we'll see what comes of our sharing.

And, BTW, as you dig into this subject, you may want to try my ebook, Managing Yourself and Others, or at Amazon or Barnes & Noble.

Managing Yourself

This is why I wrote the book, "Managing Yourself and Others."



<https://www.smashwords.com/books/view/39685?ref=JerryWeinberg>



Mostly, it's about congruence!

Amplify’d from techcrunch.com

What’s The Most Difficult CEO Skill? Managing Your Own Psychology.

By far the most difficult skill for me to learn as CEO was the ability to manage my own psychology. Organizational design, process design, metrics, hiring and firing were all relatively straightforward skills to master compared to keeping my mind in check. Over the years, I’ve spoken to hundreds of CEOs all with the same experience. Nonetheless, very few people talk about it, and I have never read anything on the topic. It’s like the fight club of management: The first rule of the CEO psychological meltdown is don’t talk about the psychological meltdown.

At risk of violating the sacred rule, I will attempt to describe the condition and prescribe some techniques that helped me. In the end, this is the most personal and important battle that any CEO will face. Read more at techcrunch.com

 

See this Amp at http://amplify.com/u/bxclo

Knowing What to Leave Alone

I adapted this blog post from my new eBook, Becoming a Change Artist This little case example followed a number of other examples, as a kind of corrective to some peoples' ideas about how a change artist operates.


I don't want to give the impression that change artists are rushing around an organization inflicting help on everyone. Perhaps the toughest skill for a change artist to learn is the skill of knowing what people and what situations to leave alone.

For instance, there's a Vietnamese proverb that says, "While it is notable to assist a stricken elephant in rising, it is foolhardy to catch one that is falling down." Change artists need to learn how to recognize whether a person or department is willing to help themselves rise.
For instance, change artists should have lots of potentially transforming ideas on hand. Most of these ideas are on the process level—that is, processes for finding ideas. Such processes might include

• reaching out to other organizations, departments, professional societies, libraries, consultants, or classes
• facilitating brainstorming processes
• keeping an inventory of sample problems, toy exercises, and simulations for right-brain exploration and left-brain investigations
• conducting focus groups, and knowing how to recognize when the group lacks the necessary knowledge (A lens doesn't focus anything if there's no ray of light.)
• changing the mixture of people to obtain more diversity and knowledge
• combining ideas from several sources to produce new ideas

A good example of combining of ideas is the process of connecting what the individuals want with what the organization or the change artist wants. If the change artist thinks the elephant might be falling down, she might make her presence (what they want) conditional on their participation (what she wants). Or if management wants the group to take a risk, the change artist might negotiate some kind of insurance to give the group safety, such as extra time in the schedule, relaxed specifications, suspension of the usual measurements, or a guarantee of their old jobs back if the project flops.

Here's an example of this kind of negotiation. In an organization producing electronic equipment with embedded software, top management threw in a foreign element by mandating certain process improvements. Some of the more traditional managers were highly technical engineers, and claimed that the other managers, being service engineers, weren't sufficiently technical to do process improvement. Thelma, a change artist, was supposed to facilitate the entire group of managers working on the improvements, but she faced a problem: Who should have the job, given that the technical managers weren't doing it, and the service managers wanted to do it?

Thelma applied several change artist principles:

• Always find the energy for change and go with it. In this case, the service managers wanted to work on change, and the technical managers didn't.
•  Don't get hooked into negative energy. The technical managers knew dozens of reasons why these changes could not be made.
• Talk in their terms and find out what the issues really are. It turned out that the technical managers were overloaded with assignments just getting products out the door. The service managers were overloaded, too, but they felt that their overload was due to service requests arising from faulty technical processes. They were willing to invest their time to reduce their future load.
• Once you're prepared, go to the source. Having assembled all these facts, Thelma made a recommendation to upper management that the service managers be given the process improvement responsibility, and that the technical managers no longer be required to attend process improvement meetings. In return, the technical managers promised their full cooperation on an as-needed basis. Upper management was happy to accept her solidly-based recommendation.
• It's perfectly all right to do nothing for a time. Dormancy periods in seeds and hibernation in animals are adaptive strategies in an environment with fluctuating opportunities for growth. In human organizations, the Zone Theory says that it sometimes makes good sense just to lie low during periods of rapid change. Knowing that Chaos is contagious, Thelma wisely decided to leave the technical managers alone. Their time would come.

In other words, just like in artistry with a canvas, paint, and a brush, sometimes the empty spaces are the most important part of the work of art.

To perfect your change artistry, you might want to participate in this year's AYE Conference.

Are you a permission giver? Feynman was.

Read the entire article, then read Feynman's letters.

Amplify’d from www.theamericanscholar.org

Permission Givers

By William Zinsser

When Richard P. Feynman, one of the giants of 20th-century physics, was awarded the Nobel Prize in 1965, he received hundreds of congratulatory letters from friends and admirers, including one from a former student named Koichi Mano. Acknowledging the letter, Feynman asked the young scientist what he working on. Koichi sent a doleful reply, regretting that he wasn’t working on fundamental problems of science, but only on “a humble and down-to-earth type of problem.”

“Your letter made me unhappy,” Feynman wrote back, “for you seem to be truly sad. No problem is too small or too trivial if we can really do something about it. It seemed that the influence of your teacher has been to give you a false idea of what are worthwhile problems.” In his own career, Feynman pointed out, he had “worked on innumerable problems that you would call humble, but which I enjoyed and felt very good about because I sometimes could partially succeed.” He went on to describe a dozen of those experiments, some of which failed, including one on the theory of turbulence that he “spent several years on without success.” Read more at www.theamericanscholar.org

 

See this Amp at http://amplify.com/u/bwosl

How to Manage Teams Congruently

Typical crisis-provoking events in the life of a programming team are machine malperformance, machine overload, unyielding bugs in critical sections, difficulties in system testing of two unit-tested programs, schedule changes, arrival of new equipment, changes in higher-level management, and changes in specifications. No wonder it seems that crisis is the normal situation in the life of a programming team.


Two general social-psychological observations about group behavior are especially relevant to the crisis-ridden programming team. First of all, it has been observed that in a crisis, members of a group more readily accept relatively strong leadership attempts. At the same time, however, the group becomes less patient with would-be leaders if their direction does not produce effective solutions to group problems rather quickly. Thus, in a programming team—which is possibly in a continual crisis—leadership patterns may be in constant flux. Because of this reshuffling, the more difficult the task is, the more the team comes to follow those leaders who can actually steer the team most effectively.


We can see, then, why the democratic—or perhaps we should say "technocratic"—organization is such a natural one for a programming team. When selecting programmers for teams, we should try to choose people who will fit well within such a self-shifting structure—neither too dominant nor too passive. In training our programmers, we should try to teach them how to follow able leaders and how to grasp leadership opportunities when they themselves are the most qualified in the group. And during the life of a team, we should try—if we are on the outside—not to interfere in those democratic processes which, though seemingly traumatic for the team and its members, will in the long run lead to most effective team functioning.


Indeed, once the team is selected and operating, the wise manager placed above it will adopt a "hands-off" policy with regard to its internal structure and structure change. When, as so often happens, team members come to him to lend an authoritative opinion on their side of some argument, he would do well to follow the pattern of the old rabbi who was sitting in his study one day when an obviously agitated man came to see him. The man told him a long story about an argument just concluded with his wife. When he finished his story, he insisted that the rabbi tell him whether he or his wife had been right.


"You're right," said the rabbi, and the man left the house beaming. Soon, however, the man's wife appeared—even more distraught than the man had been.


"What do you mean," she insisted, "saying that my husband was right? You haven't heard my side of the story." And she proceeded to relate her side, finishing with a demand for a new judgment.


"You're right," said the rabbi, and the wife left satisfied. The rabbi's own wife, however, was not satisfied, for she had overheard both stories and both answers.


"How can you do that?" she demanded. "You told the husband that he was right and the wife that she was right. They can't both be right."


"You're right," said the rabbi.

[This little tale is adapted from my books: The Psychology of Computer Programming and Managing Teams Congruently.]