Regular readers of this blog may have noticed that I slow down from time to time, which may signify that either (a) I'm sick or (b) I'm finishing a project. This time, it was a bit of both: (a) when I fell on my head and (b) when I was finishing a new book—Experiential Learning: Beginning.

If you are a writer, you may find my publication method interesting: LeanPub.com.

Those of you who teach should find my newest book interesting.

The Title is Experiential Learning: Beginning.

Experiential Learning the first volume in a series that collects and organizes more than fifty years of experience by many learning leaders using the experiential method to aid students in a variety of subjects, including, at least the following subjects:

* software development

* software testing

* anthropology

* physics

* writing

* design

* project management

* education

* medicine

* business administration

* architecture

* biology

* chemistry

* communication

* economics

* environmental science

* family therapy

* computer science

Where Can The Series Be Helpful?

At present, the Experiential Learning series is planned for three volumes. The first volume—Beginning—concerns getting started: starting using the experiential method, starting to design exercises, and getting a particular exercise off to a good start.

It should be particularly helpful for short classes—a day or two, or even an hour or two—though it could be for starting to use experiential parts of a longer workshop consisting of both short and long experiential pieces as well as more traditional learning models.

The second volume—Class—guides the reader in constructing,  delivering, and—most importantly—debriefing classes consisting entirely (or almost entirely) of one or more experiential exercises.

Volume Three—Simulations—takes up the possibilities for longer classes and longer exercises.

What Can Be Learned from the Series?

At the beginning of our classes, we generally gather the students' hopes for what will happen as a result of the class. (You can read more about this practice in the section called Requirements Gathering.) We haven't figured out how to gather requirements from each reader of a book, but we do offer a class about experiential learning, and from the participants in these classes, we've developed some ideas of what most of our students want.

So, what can you hope to gain from reading these volumes? We've made a list of hopes distilled from these classes:

• Learn practical knowledge about designing experiential exercises.
• Expand my understanding of what participants experience during experiential exercises.
• Unlearn things that interfere with effective experiential learning.
• Help to expand my "big picture" about this topic.
• Link to other knowledge to help increase my effectiveness.
• Figure out if students are really learning.

We've used this list to guide us in deciding what to include, and as with any experiential exercise, this book may lead its readers to many additional lessons we never planned for them.

Experiential Exercises

In the final analysis, a book about the effectiveness of experiential exercises may seem to be a paradox, but there's a learning there, too.

We are not claiming that the experiential method is the only way to learn. We're not even claiming that experiential exercises always teach anything worthwhile, or that students never take away erroneous or vacuous learnings. We're merely saying that we have found this approach to be one more tool for our teaching repertoire—a tool that has been strikingly effective for us as both teachers and learners. We hope it turns out that way for you, as well.

Mahlberg Interview

As promised, here's the rest of Michael Mahlberg's interview:

Michael: One of your books that comes to mind after experiencing the learnings of the AYE is titled The Psychology of Computer Programming.  How do you see the role of psychology in todays software industry?

Jerry: Quite simple, software is an industry based on mental processes, not physical ones. Our products are not made of metal or plastic, but are entirely mental constructs. Psychology is the study of our "production facility"--our brains. How we think and feel form the only true "software science."

Michael: You have written non-fiction books for decades and in this century you have started to write more fiction than non-fiction - what is the appeal of writing fiction for you?

Jerry: I see fiction as a natural extension of all my work. Stories allow me to create appealing and memorable lessons about life in general, but software thinking in particular. For many readers, stories are the best way to learn, other than through expensive personal life lessons (which often don't teach anything because they're too entangled with personal life issues. Fiction stories give some readers the "distance" they need to see the lessons, while offering the "closeness" to make the reading simulate true life. 

Also, for me personally, fiction writing is a new challenge, the kind of challenge I've always sought to further my lifelong learning.

Michael: In the early days of your career computers and software were used only on very few, very special projects - the Mercury Project, where you played a vital role, comes to mind - whereas nowadays computers are everywhere and even for the most mundane tasks software gets written. How would you say that this has changed the way our profession is conducted?

Jerry: First of all, nowadays, 99% of software developers are not "professionals." Still, the remaining 1% constitue a far larger population of professionals than we had when I started, more than 50 years ago. Those days, I basically knew every software pro in the USA, if not the world. So, the larger group of professionals gives us the opportunity to create a much more powerful community for learning and sharing (as long as we are able to distinguish the professionals from the amateurs).

Michael: Between writing novels, preparing conferences, conducting workshops - do you still find time to do consulting work? And if so, could you tell us a bit about current trends in software development as you perceive them in your consulting work?

Jerry: Consulting is the essential third leg of my business. From consulting, I learn what is really going on among the best organizations (the worst would never voluntarily hire a consultant, though I've met a few who were involved in non-performance lawsuits). From my consulting, I learn what I should be teaching (the second leg). And, through my teaching, I learn how to offer the significant lessons in the most effective way, and these ways are what leads to my books.

As far as current trends are concerned, I'm not too interested. Why? Because "current trends" have almost always turned into fads. What I seek is clients who are actually using some of the important things we've learned in the past 50 years. There aren't many of those, but the organizations who do them (rather than talk about the latest fads), are consistently the best.

Michael: Thank you very much for this interview!

Jerry: And thanks for the great questions. You've done a great job, Michael.

------------------- end of interview ----------------------------------

Why so successful and durable?

At November's AYE Conference, participant Michael Mahlberg asked if he could interview me for a German magazine. The interview and his article about AYE have now been published, but in German, so I thought I'd make the English version available to my readers whose German language skills are no better than mine. It's a long interview, so I'll probably use several blog entries to cover it all.

Michael: I thank you very much that you take the time for this Interview. You just came back from the 12th AYE - Amplifying Your Effectiveness - conference if I have counted correctly. 

Looking back on twelve years of AYE Conferences, why do you think that this unusual format proved so successful and durable?

Jerry: Several reasons come to mind, in no particular order:

1. We designed the conference in reaction to a number of conferences we hosts had just attended. We kept what we thought was good (such as, a few interactive sessions; some rare meal-time interaction;  comfortable accommodations) 

2. We discarded what we thought was bad (such as: overcrowding that really eliminated participant-participant interaction; segregation of presenters from participants; non-interactive presentations, such as power-point reading by presenters; a few big-name presenters who thought they knew all there was to know; amateur presenters who simply didn't know how to handle crowds [which were too big, anyway]; expensive accommodations; irrelevant activities such as nightclub events, stand-up comedians, shopping trips; third-party event planners who did not know the audience and/or topics).

3. We limited participation to 75, which after experimentation proved to be a number that kept down overcrowding and maximized interaction opportunities, while providing sufficient energy to run all sorts of experiential sessions.

4. We forbade power-point altogether, and required every session to be experiential.

5. We trained ourselves to be good designers and presenters of experiential sessions.

6. We kept prices low so independents would be able to come and add their viewpoint to the interactions.

7. We were not trying to make a pile of money, but instead were attempting to show what a conference would be like if we shed all the commercialism that has crept ahead of the espoused purposes of other conferences.

All in all, we've tried to do unto others as we would have others do unto us—and not just "unto" others, but with the full participation of others.

________________end of first question–––––––––––

Note: The 2012 AYE Conference will be held in Raleigh, North Carolina, Sunday, November 4 through Thursday November 8, 2012. You can read details at http://www.ayeconference.com

Perhaps the nicest feature of WIGGLE charts is the way they can be used with just about anybody's diagrammatic technique.

The following figure shows a Hierarchic WIGGLE, or a WIGGLE Visual Table of Contents (WVTOC) for use with a HIPO system. In this application of the WIGGLE the overall size of the boxes can be used to indicate (roughly) how big an effort we anticipate in building this box. Alternatively, it can be used to approximate how much execution time or other resource we expect to be consumed here.

A WIGGLE visual table of contents from a HIPO system (Each box has input on left end, output on right.)

Figure 27 shows a Nassi-Shneiderman WIGGLE. In this chart, the size of the wiggles in the diagram indicates roughly how uncertain we are of the particular part of the design. 

Figure 27. A Nassi-Shneiderman WIGGLE

The vertical loop wiggle is quite small, perhaps indicating we're not sure if the loop is to be done N or N+1 times. Similarly, the slanted wiggles on the decision are small, indicating perhaps we don't yet know just where the "equal" case will go. But the large wiggles dividing the right branch of the decision into three boxes are very large, indicating great uncertainty about the functions to be performed here.

All these conventions may be applied to sides of boxes, regardless of the shape of the box, as well as to arrows or other lines connecting boxes. Each of these charts should be sufficiently "clear"—as sketches—to readers who can read the original, unwiggled, chart. Just for completeness, Figure 28 shows a key to the use of the WIGGLE. Using this figure, you should be able to begin sketching your favorite design pictures using the WIGGLE, even if you're still in love with good old flowcharts.

Figure 28. The WIGGLE system condensed to a few simple rules applicable to any graphic scheme

Source

This material on WIGGLE charts is adapted from my book, Rethinking Systems Analysis and Design.

The Order of Maria Theresa

Today's idea is embodied in a medal established in Austria. According to Wikipedia, the military order of Maria Theresa. "It was specifically given for 'successful military acts of essential impact to a campaign that were undertaken on [the officer's] own initiative, and might have been omitted by an honorable officer without reproach.' This gave rise to a popular myth that it was awarded for (successfully) acting against an explicit order."

The Order of Maria Theresa is a marvel of bureaucratic invention, but it's not unique. Every successful organization—nation, business, or neighborhood kite club—has rules for breaking its own rules. The only unusual aspect of the Order of Maria Theresa is that the rule was written down and officially recognized.

When Jefferson was drafting the United States Constitution, he naturally wrote an article concerning amendments. But when asked to write something granting the people the right to throw out the Constitution entirely and start afresh, Jefferson refused. He argued—correctly, I think—that the people had such a right whether or not it was written in the Constitution. It was a right superseding any government and any written rules of government. It was, in effect, a tautology, for without the consent of the governed, there is no government. A shadow, perhaps, but no government.

The same is true in any modern bureaucracy. Rules are not made to be broken, but neither are they made to be not broken. Rules are made so that the organization operates more effectively. The rule above all other rules is "Do what is necessary to operate effectively." You ultimately get punished for not operating effectively, but not for breaking the rules.

It seems to me the problem with bureaucracies is this: the obverse side of this coin isn't so shiny. If you obey the rules and things turn out badly, you don't get punished. In war, the problem may be easier, because if things turn out badly you may be dead and not have to face the Empress. In the XYZ Pork and Bean Factory, your life is not usually at risk—even if your customers are taking their lives in their hands every time they pick up a pork fork.

I'd be interested in pursuing the biographies of Maria Theresa winners after they won the medal. I know that in the United States—where the Medal of Honor is often given under similar circumstances—many winners wind up, as civilians, trying to get a few cents for their medals in a pawn shop. Even medal-winning is a short-lived glory in the best of circumstances.

When I started to write this essay, I hoped to conclude by recommending each organization install an Order of Maria Theresa to counteract the conformist tendencies infecting even the best-managed organizations. But as my thoughts developed, I realized medals are not the answer. If you're on top of a large organizational pyramid and want protection from your own mistaken orders, you're going to have to work harder than Maria Theresa.

You can start by ensuring nobody is punished merely for discussing the merits of a particular order of yours. Even if you don't punish discussion, you'll need a long time to overcome the fears people have learned throughout their long careers in other organizations. But the long wait will be worth it, for then you will be relieved of the burden of perfection—a burden no person and no nation can long endure.

You might think your next step would be to encourage people to disobey orders they think are wrong or foolish, but they won't need any encouragement if the climate for talking is right. At least some of them won't, and the others will be watching to see what happens to the pioneers. 

So your second problem comes when someone disobeys—and fails! Now you have the perfect opportunity to play "I told you so," but if you do, there won't be any further games. Instead, you must convince the person to tell you why the order was disobeyed. It might have been a stupid order, destined to fail even if it had been carried out. Or it might have been misunderstood—a most likely alternative.

And once you've understood the reasons for the disobedience, drop the whole matter! Everyone is entitled to make a mistake now and then. If people never make mistakes, it means they're never trying and never thinking, which is the most horrible fate a bureaucracy can contemplate. Only if the same person disobeys orders over and over will you have to take any action—and by then your course of action should be obvious.

But won't the repeated failures create a disaster? Perhaps, but then you can take comfort from the Austrian motto: The situation is hopeless but not serious.

In the programming business, we have the comfort of a large cushion of safety in what we do. We make many mistakes, but we have procedures designed to detect them and remove them before they cause too much harm. If those procedures are working well, it gives us some breathing room in which to make mistakes—the same room we need in order to learn. In such situations, we shouldn't need medals to keep us disobeying foolish orders.

This essay is adapted from a chapter in the book, Understanding the Professional Programmer. The book is actually a series of such essays, all aimed at the often difficult task mentioned in the title.

Where Do Bad Managers Come From?

On a recent flight out of Chicago, I found myself seated next to Jack, a IT manager in a medium-sized company. Jack was on his way to interview for the IT manager in a larger corporation. He explained that he had reached the limit of his present job, and his only chance to advance himself was with a company with a larger organization.

"Why don't you stay with your present organisation and move into general management?" I asked.

"That was my goal when I took this job three years ago," Jack said, "but there's not a chance. The president of the company sees me as a technical specialist, lacking skills to become a 'real' executive. So I'm looking for someplace else, where I'll be appreciated."

"But three years isn't a very long time with one company," I said. "Perhaps they don't feel you've had enough time to prove yourself to them."

"I've done a lot for them in three years, but they don't appreciate how much work it takes to manage in the present crisis environment."

"What do you mean?"

Before I could hear his answer, one of the cabin attendants came by to ask for our choices for lunch. She beckoned the other attendant to come over and refresh our drinks. By the time all the fuss was over, we had our lunches, but I had forgotten their was an unanswered question still suspended between us. But Jack hadn't forgotten. He seemed eager to dump his woes on me while I picked at my sirloin tips.

"Technology is changing every month, and I can't find good people. It's impossible to keep a technical staff together long enough to make improvements in present systems, let alone keep up with the new technology. Junior programmers demand inflated salaries, and if they don't get them, they jump ship to some other company that is desperate enough to pay them. And senior programmers ..." He stopped talking and unrolled his cutlery.

"What about senior programmers?" I asked.

"Why talk about it?" Jack said bitterly. "There's no sense even thinking about hiring a senior person, let alone starting to search for one. You give them the moon, and a year later they want the sun. They seem to think they could get rid of us managers and run the place without us."

I could see why Jack was so bitter. In effect, he was being squeezed from both top and bottom. His management did not want to let him advance, and he felt the pressure of his own employees trying to advance up from below. Still, I had a hard time feeling sorry for Jack. I'm always suspicious of managers who speak badly of their employees.

I almost told Jack the Army saying: "There are no bad soldiers, only bad officers." Instead, I dipped the tiny spoon into my dessert custard. I had a feeling Jack wouldn't appreciate Army wisdom.

Of course Jack has problems with employees. But a manager's iob is to deal with such problems, so if Jack complains about bad people, he's telling me he's not doing his job. Jack says his people were leaving for better salaries, but salaries are roughly tenth on the list of reasons technical people switch jobs. The first reason they leave jobs is poor management. Probably the second and third reasons, too.

Jack himself was leaving his job because his own management did not understand him. They would not give him the opportunity he thought he deserved, nor would they guide him to the self-improvement he needed to advance his career.

Jack complained that his bosses never supported his requests for management training, but when I asked him about training his own people, he said: "Why invest in training them? They are going to leave before I get a return on my investment. My staff is turning over at a rate of 25 per cent a year. Technical people have no company loyalty whatsoever."

By changing jobs every three years, Jack himself was "turning over" at a rate of 33 per cent a year. His management, knowing that "technical people have no company loyalty," refused to take Jack's own executive aspirations seriously.

Jack, like so many IT managers, was locked in a "disloyalty cycle." His management did not take him seriously as a person, so he was not loyal to them. Because he was not loyal to them, they refused to take him seriously as a person. In his own career, Jack was modelling the problem he was having with his own staff.

Not every IT manager has Jack's problems. Some have broken the "disloyalty cycle," or stayed out of it in the first place. They are not panicked by the pace of technology, but insist on developing their own employees.

They may hire experienced people, but do not try to "buy" instant expertise. They know that the expertise they buy is more likely to be bought again by someone else. They have excellent technical staffs, with low turnover, but their pay scales are merely competitive, not exceptional.

Their employees tend to be loyal to their companies because they know their managers are also loyal to their companies. One of my clients has a IT manager who budgets a minimum of 20 days per year of training per employee, and woe to one of his managers who fails to reach that minimum for each employee. He does not "waste" this investment because most employees want to stay at a company that actively demonstrates loyalty to them. Sure he has some turnover, but around six per cent, rather than Jack's 25 per cent. Moreover, he tends to turn over the people he would rather lose, rather than the ones he would rather retain.

IT managers like Jack cannot have it both ways. If they want to become "real" executives, they will have to start acting like real executives. That means taking responsibility, rather than blaming their employees. It means developing good people, not trying to pirate them from other companies and then griping about how other companies are pirating from them.

But Jack does not have time to develop his employees. If he does not get promoted in three years, he will not be around to reap the benefits of his investment in them. He will be out looking for a new job that will show him more "loyalty."

"Real" executives take the long view. They are the kind of people who, at age 60, can be found planting trees. IT managers who think that fast moving technology requires short-term quick fixes are stuck in a middle management mentality. They will never become real executives.

Managing Yourself and Others

Where There’s a Will There’s a Murder

I've been slow posting on this blog for the past few weeks, and now you know why:


I've been finishing the next novel in my Residue Class Mystery Series: Where There’s a Will There’s a Murder

You can buy it now for Kindle, Nook, or at Smashwords for any other reader format. Just click the link above.


Note on PSL 
Problem Solving Leadership Workshop for May is almost full. We are considering a session for the overflow, so if you want in, get in touch with me right away. Jerry Weinberg

WIGGLE Charts—A Sketching Tool for Designers (Part 2)

Wiggle Charts (Part 2)

Perhaps the nicest feature of WIGGLE charts is the way they can be used with just about anybody's diagrammatic technique.

The following figure shows a Hierarchic WIGGLE, or a WIGGLE Visual Table of Contents (WVTOC) for use with a HIPO system. In this application of the WIGGLE, the overall size of the boxes can be used to indicate (roughly) how big an effort we anticipate in building this box. Alternatively, it can be used to approximate how much execution time or other resource we expect to be consumed here.

A WIGGLE visual table of contents from a HIPO system (Each box has input on left end, output on right.)

The next figure shows a Nassi-Shneiderman WIGGLE. In this chart, the size of the wiggles in the diagram indicates roughly how uncertain we are of the particular part of the design. 

A Nassi-Shneiderman WIGGLE

The vertical loop wiggle is quite small, perhaps indicating we're not sure if the loop is to be done N or N+1 times. Similarly, the slanted wiggles on the decision are small, indicating perhaps we don't yet know just where the "equal" case will go. But the large wiggles dividing the right branch of the decision into three boxes are very large, indicating great uncertainty about the functions to be performed here.

All these conventions may be applied to sides of boxes, regardless of the shape of the box, as well as to arrows or other lines connecting boxes. Each of these charts should be sufficiently "clear"—as sketches—to readers who can read the original, unwiggled, chart.

Just for completeness, the next figure shows a key to the use of the WIGGLE. Using this figure, you should be able to begin sketching your favorite design pictures using the WIGGLE, even if you're still in love with good old flowcharts.

The WIGGLE system condensed to a few simple rules applicable to any graphic scheme

Source

This material is adapted from my book, Rethinking Systems Analysis and Design.

A Christmas Present for My Readers: A Free Story

This year I created a Christmas present for all my faithful readers. It's about one of the characters in my series of novels, The Stringers–Ember, a blind girl with extraordinary powers. The story is titled "The Blind Warrior," and it's free.

I wanted to put the story free on Amazon.com, but Amazon took a long time to make it a free story. They finally did, but now it's too late for Christmas, so I'm doing it anyway. To obtain your copy of The Blind Warrior, go to smashwords.com. You will find the story at this address:

http://www.smashwords.com/books/view/106977?ref=JerryWeinberg

Or, on Kindle, it's at

http://www.amazon.com/dp/B006CDQEYK

And it's even on Barnes and Noble, for you Nooknicks:

http://www.barnesandnoble.com/w/the-blind-warrior-gerald-m-weinberg/1107956526?ean=2940032888451

It's free of all charges, and you can download the story in any format you need  (Smashwords has 'em all, or in more than one format). You can read the story on your computer, or you can transfer it to any other device.

Of course I have an ulterior motive. I hope you will like the story so much that you will want to read more about Ember and her Stringer friends. Or maybe you'll write a one-or-two sentence review.

Find all my books through http://www.geraldmweinberg.com, including the Stringer Series, so far.

WIGGLE Charts—A Sketching Tool for Designers

There's no sense being precise about something when you don't even know what you're talking about. - John von Neumann

For systems designers, it is the best of times and the worst of times. For years we muddled through with a few simple graphic tools for design and documentation—flowcharts, block diagrams, and perhaps decision tables. Then came the diagram explosion, with HIPO, HIPO/DB, Warnier-Orr diagrams, Softech's SADT, Nassi-Shneiderman charts, Petri nets, Constantine structure charts and data flow diagrams, Jackson data structure diagrams, and coding schemes. And for each of these diagrams, you need only bend a line or add a symbol to become known as the inventor of yet another graphic design tool.

Although the choice is large, it is really not very wide. Each of these diagrammatic schemes shares the characteristic of precision—wonderful when you know what you're talking about, but time-consuming and thought-stifling when you don't. And, since most design work is spent thinking roughly, few of these diagrams are of much help through large parts of the design process.

In other design fields, such as architecture, the rough sketch is the most frequently used graphic device, and precise detailed drawings are rarely used at all until the creative part of the design work is finished. The rough sketch has several advantages over the precise drawing:

1. It can be drawn much faster, thus using less time.

2. It represents less investment of time, so we're not afraid to throw it away and try something else.

3. It's very roughness conveys important information about where we are in the design process.

In information processing, rough sketches have always existed, but have never been glorified by a name or by favorable publicity. Schools of architecture offer courses in sketching. The student architect who makes clear quick sketches is much admired by faculty and peers alike. It's time we learned from more mature disciplines and put sketching up on a pedestal.

For many years, I've taught a method of sketching usable with most of the diagrammatic techniques now used in information processing. Although it's been received with enthusiasm, it's never received much publicity, perhaps because:

1. It doesn't require a template.

2. It doesn't have a name.

Although I'll continue to resist the template forces, I've decided to bring the baby to life with a catchy acronym, WIGGLE Charts, for Weinberg's Ideogram for Generating Graphics Lacking Exactitude.

A WIGGLE is merely a box, or block, or line, with one or more rough edges. The rough edges indicate what parts represented by the box or line are imprecisely known. For instance, the following figure is a sketch of a system using a block diagram form

A WIGGLE block diagram

Each box represents input coming from the left, processing inside, and output going to the right. Box 1 has a straight line at its left side, indicating the input to Box 1 is clearly defined somewhere. The right side, however, is rough, indicating we haven't decided what its output will be. As indicated in the diagram, some output will be passed to a second box. but we don't know exactly what. The top and bottom of Box 1 are rough lines, indicating we don't know exactly what this process will be.

Box 2 has undefined input and output, but its process is well known to us, and clearly delimited in scope. Perhaps we have decided to use an off-the-shelf sort, though we don't know which one, so we haven't decided upon a record format.

Box 3 takes the unknown output of Box 2 as its unknown input. By a process that's not yet well defined, it produces two outputs, one well defined and one known only roughly. Perhaps the first report is defined by legal requirements, or by input needs of another system, while the second output is an error report whose format is left open at this stage of the design process. The rough arrows between the boxes indicate we haven't yet decided how control will pass from one box to another. They could be subroutines of the same master routine, or steps in the same job, or separate steps manually coordinated.

Taken together, these three WIGGLE boxes and their arrows give a sketch of the overall design we have in mind. Perhaps more important is what they don't do:

1. They don't give us or any reader an unjustified feeling of precision.

2. They don't intimidate anyone who has an idea about changing something to improve the design.

3. They haven't wasted a lot of time drawing with templates.

Perhaps the nicest feature of WIGGLE charts is the way they can be used with just about anybody's diagrammatic technique. In the second half of this blog post, we'll look at a few more examples of how WIGGLE charts can be used.

(to be continued)

Source

This material on WIGGLE charts is adapted from my book, Rethinking Systems Analysis and Design.

Problem Solving Leadership Workshop (Revisited)

Today, I'm revisiting a post I put here almost exactly three years ago. At that time, I was announcing the resumption of PSL (Problem Solving Leadership Workshops). Today, I'm announcing the continuation of what has become a treasured tradition.

We're giving the next offering of the famous Problem Solving Leadership (PSL) on May 19-25, 2012, in Albuquerque, NM led by me, Esther Derby, and Johanna Rothman

The workshop's purpose is to learn and practice a consultant's most valuable asset: the ability to think and act creatively. We have designed this workshop to be practical and applicable to the modern workplace. Your problems and concerns provide a frame of reference for all
the workshop activities.

What you will learn
. to be a leader while being a member of a team
. to focus your thinking while in chaos
. to make change a productive, creative event
. to build truly effective teams
. to design projects people really want to work on
. to observe exactly what is happening
. to use tools of effective communication
. to handle conflict in problem solving groups

The workshop provides five and a half days of intensive focus on developing your unique consulting style and abilities.

Graduates Answer: "What Did You Learn in PSL?"

Janet:

My PSL course made me realize that observation alone is not enough. Sometimes you need to get in and ask questions and listen to really know what's going on.

Amy:

It's interesting to reflect on this fourteen years after the fact (Sept. 1997) of what was a profound experience.  My biggest observation was my tendency to pick problems that are too big to be solved—or at least solved all at once or on the term initially envisioned.  And my lesson was that I could turn to others and ask for help parsing the problem into resolvable packets.  I'm still using that one every day. . . when I remember to step back and observe the observer observing.

Jim (who sent me the panda picture):

I took PSL in 1983 (Jacksonville, Fl.). At the time I learned a valuable lesson about myself.  I have a tendency to cling to an obsolete and inappropriate technology long after it is no longer effective. Years later, taking training facilitated by amateurs (managers saving money on their training budget) I learned how important it is to have qualified trainers and good exercises.

Marjie:

I learned so many ways to help my teams back home become self - sufficient problem solvers by teaching. I became far more self-aware of my own behavior which was to just solve the problem and try to make life easier for everyone else when in fact, it was much more relaxing to give people the skills to solve their own problems (at least the tricks I learned at PSL) and to watch them do great things. 

I learned that Jerry's expression, "expect brilliance"—became the motto of my management style.

Sharon:

Big lessons, life-changing, agreed. The immediate lesson was: respond.  That is, I found that sometimes, in the heat of the moment, I would listen, hear, see, take in and wait, processing the inputs.  That was good.  But most important was once I did that, I should give feedback, respond, react.  Even if other people are responding, get into the mix and say what needs to be said.

The long-term lesson was that there is a fabulous community around us all.  Jerry and others became part of an extended community that has vastly changed what work I do, how I do it, and to whom I reach for support.

Becky:

Sharon, I like your point about community! I've connected with delightful, smart and engaging people who shared a similar path through JerryWorld. Not to mention the wizards who helped lead us down the path—all of those who encouraged us to be our own wizards. Gee - I hadn't thought of that. 

PSL - the gift that keeps on giving.

David:

I started learning to listen to myself, instead of asking others for validation before believing myself. Something that has served me well since then, and that I'm still learning to do better."

Rachel:

I think I'm still unpacking lessons from PSL :)

I signed up for PSL because I was uncomfortable with taking on leadership roles. I feel happier about taking the lead nowadays. For me the key is sharing passion and vision for what's possible and make it easy for people to contribute in their own way. It's important to step back and let others shape things whilst caring how things are done and being there as support when people get stuck.

I'd love to do PSL over again and also connect up with people I met there.

Jason:

I seem to have 'aha' moments often since PSL in May 2011.  A couple things stand out for me.  One, how Jerry talked about having fun and learning at work.  So simple, yet something I live by. If I'm not having fun or learning, I move on.

Second was observing the difference in outcomes between a controlling culture and cultivation culture.  I'm also amazed at in a short period of time how many people I became very close to.  It was a fantastic experience.

Zeger:

Hi all, I took PSL in May last year, and what has stuck with me, well... that's still evolving. I was an observer during the VerseWorks exercise and it struck me how much you can see and learn about what is going on in teams if you just take a step back and observe. When you're too involved, you become blind for things that are apparent to outsiders. Noticing all that going on and refraining from commenting or pointing out was quite hard. That was quite a epiphany for me. 

I also became aware of the power of silence. Doing or saying nothing can also be an act of problem-solving leadership, helping the team forward. Sometimes, less is truly more. That was a pretty sobering insight too.

Jerry:

I've "taken" PSL many, many times, and I'm still learning lessons with every workshop. Mostly, I keep learning how many wonderfully creative people are out there, always ready to take one more step toward their full potential.

If you would like more information about in this unique workshop experience, email to
jr@jrothman.com and/or take a look at http://www.estherderby.com/workshops/ProblemSolvingLeadership.htm

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.

Change Artist Challenge #11: Putting Theory Into Practice

There's nothing more practical than a good theory. - Kenneth Boulding

Reading a book is one thing. Applying what you learn is quite another. If you don't apply it soon, it simply fades away. The same is true of any educational experience. If you come back from a class and don't start using some of the material, you may as well not have gone in the first place.

The Challenge
Your challenge is to review the chapters in any of the four Quality Software Management volumes concerning specifics of the Anticipating organization and consider each idea in terms of the artistry that you can use to introduce it to your organization. Try to create at least one specific action item that will advance the transformation to that way of doing things.

Experiences
1. I started a brown bag special-interest group on our new CASE tool as a place for people who were using it to share learnings, and as a low-risk place for those who weren't using it to find out about it. The hardest part for me—and the real challenge—was to be the first speaker. I haven't been a person who enjoys speaking in front of groups, but I got some support and made myself do it. The group now runs on its own—with little nudges from me once in a while—and there's no trouble getting speakers. It has tripled in size as our use of the tool has grown, and people think that without the group the tool would have died in the original group, or at least not spread.

2. I set out to measure something that would be useful to upper management and to the people whose work was being measured. After a few false starts, I hit upon measuring resolution time for failures found in test. I set up a system to capture this data from our bug database and to plot it automatically week by week. One of the surprising things it showed was the way the new configuration management system actually slowed down resolution time. Since I was advocating the new system, I was rather disappointed, but I resisted the temptation to fudge the figures. Management wanted to throw the system out, but I invoked the Satir Change Model to get a few weeks grace period. With the help of some investigation into the causes of Chaos, the graph improved. In about three weeks, the resolution time was back to what it was before the tool, and after six weeks, the time was cut by 32%. This was the first time anyone had ever demonstrated the value of a new tool in our organization.

3. My challenge to myself was to open up information in my organization. To do this, I decided to be the model by using Public Project Progress Posters for the three projects I'm managing. I was surprised by the emotional reactions—mine and others'. I was apprehensive and defensive, yet proud of my courage. One of the other managers came into my office, shut the door, and started screaming obscenities at me for embarrassing him (because he wasn't going to post his progress). The people in the projects were generally accepting, though I spent a lot of time in the next two weeks explaining how to read the posters, what certain slippages meant, and what I was going to do about them. It was a lot more trouble than I anticipated, but now that things have settled down, it seems to be worth it.

Reference

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

Change Artist Challenge #10: Learning from History

The liberation of a tree is not the freedom from its roots.- Rabindranath Tagore
The Grand Tour shows you what's going on now, but perhaps more interesting to a change artist is how things got the way they are.

The Challenge
Your challenge is to discover the history of some practice that you consider non-productive.

Experience#1
1. Darn you! This assignment almost got me fired. I started questioning why we chose our LAN software and then it came out that my boss was the one who made the study that led to the decision. We got into a BIG argument over what I considered a dumb choice that was really hurting communication around here. He gave me a copy of his original study (actually, he practically shoved it down my throat) and I grudgingly read it. I was halfway into it when I realized that they really had chosen the best that was available at that time. The system I was favoring didn't even exist then. I don't think the company that makes it even existed then. I didn't know that; I didn't even think of that. Well, I learned a couple of things:

• Don't argue with the boss until you have all your facts straight. (I suppose I knew this, but needed reinforcing.)

• Everybody really is doing the best they can, with what they have, at the time they do it.

• I'm likely to make the same mistake (if it really is a mistake) of not seeing far enough into the future.

• An apology actually works with my boss, and doesn't kill me (though it embarrasses me).

Experience#2
While studying how we used consultants in the past, I learned that we have a pattern of paying them a lot, putting in a lot of work with them, and then putting their reports on the shelf. I don't know what I'm going to do about this, but obviously something has to change. Perhaps we won't hire consultants any more, or we'll hire different ones, or we'll work with them differently. Maybe we're expecting too much from a report.

Experience#3
I found out why we put quarters in the bowl at meetings when somebody interrupts someone else. That started before I came to this group. Now we give that money to charity, but originally it was used for beer after the meeting. I've re-instituted the beer-sharing—we really needed some kind of team-building, or team-repairing like that. Don't worry, though. We still give the quarters to charity, and just take turns buying the beer.

Experience#4
I wanted to find out what really happened to the previous two process groups. I did. I'm going to make a few changes, right away.

Experience#5
Well, I couldn't do this assignment. I wanted to study the history of our weekly status meetings, but I couldn't find anyone who remembered how they got started. I couldn't find anyone who remembered why they got started. I couldn't even find anybody who knew why we were still doing them. So we're not doing them any more. But I didn't do the assignment.

Reference

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

Disposable Programs (Part 2)

There are many reasons why a program brought out of hibernation could incur costs:

1. The hardware environment has changed.

2. The system software environment has changed.

3. The size or format of the data has changed.

4. The human environment has changed.

5. Some part of the program or its supporting material has been lost or damaged.

So it does cost to rerun an "unchanged" program, and the longer the period of hibernation, the greater the cost. But you already knew this—we all know this. Then why, oh why, do we keep tumbling into the same trap?

Part 2
I believe the answer lies in our unwillingness or inability to feed-back the true costs of programming and program maintenance to our users. Among our service bureau clients, the problem seems to have been brought to manageable proportions by the following steps:

1. When a program is commissioned, the lifespan and the number of executions must be specified.

2. If there is uncertainty about either of these figures, contingent prices are given, reflecting the differing costs.

3. The contract is written stating that the program will be destroyed after a certain time and/or number of runs, whichever comes first.

4. The program remains the property of the service bureau, unless the customer takes ownership—in which case a much higher cost is placed on the job, in order to pay for preparing the program to be taken over by other than the original programmers.

5. The customer is notified when the program is about to be destroyed, and is given the option (at a substantial and realistic price) of having the program rebuilt for further use.

6. If the program is a "one-time" program, no notification is given, but the program is destroyed—literally—as soon as the customer agrees to accept the results.

When working with inexperienced users, it is not difficult to get these terms accepted. Neither is it difficult with very experienced users, who know quite well the realities of "one-time" programs that turn out to be "N-time" programs. Only the in between users have difficulty accepting these conditions, for they believe they understand about programming, but actually have no solid basis for understanding.

After a few costly lessons, they are more than willing to sit down in advance and decide whether they want to invest in an N-time program or merely in a disposable program that will actually be disposed of.

In internal data processing situations, especially where there is no true chargeback for programming or program maintenance, these lessons are difficult to teach. There is no cost to the users of specifying a one-time program and then asking that it be run N times. Without cost, there is no motivation to learn.

Where there is chargeback, it is possible to do what good, professional service bureaus do. Without chargeback, you can sometimes achieve some relief by manipulating the one parameter you have available—time. You request the user to specify a one-time or N-time program and then give different time estimates for each. The one-time estimate is shorter, but carefully spells out the procedure that will be followed in destroying the program after its first use.

At first, users will not believe this procedure will be enforced. After a few lessons, they will begin to understand and devote some energy to the decision. Of course, some users will simply attack the computing center manager, or the programmer, with an axe, literal or figurative. Such are the perils of our profession. Besides, even an axe in the forehead is better than the pain in some lower anatomy caused by an immortal one-time program.

Disposable Programs

In many IT installations today, the number one problem is program maintenance.
Although the total problem is far from simple, there are a number of relatively simple ideas that can be applied immediately to furnish "prompt relief." One such idea is the disposable program.

The idea of disposable programs is not new. Every programmer has written code that was to be used once and then thrown away—codes such as:

1. First-cut subroutines, as for simple, quick formatting of output.

2. One-time reports.

3. Test drivers.

4. Research programs to probe some peculiar feature of the programming language, operating system, database, or other "black box."

5. Engineering assist programs, to help diagnose a particular hardware malfunction.

If you consider these five examples relative to your own experience, you will notice two categories:

KEPT: first-cut routines, and one-time reports, and

DISPOSED: test drivers, research programs, and hardware testers. That is, though all are thought of as single use programs, the KEPT routines tend to be held, somewhere, "just in case." Only the DISPOSED programs are actually discarded, whether they should be or not.

Can you recall an instance when you wished you had actually retained a discarded program?

And can you recall cases of KEPT programs you devoutly wish you had destroyed when you had the chance? These are the programs you see and curse almost every day, as their user phones, pleading for "just one little change."

Perhaps we would immediately begin improving the maintenance situation by applying two simple rules about "one- time" programs:

1. If you are about to throw it away, keep it.

2. If you are about to keep it, throw it away.

Unfortunately, applying these two rules together creates an infinite recursion. All programmers would be instantly paralyzed. There must be a better way. (Or do you believe that instant paralysis of all programmers would be of great benefit to the human species?)

Consider the examples once again; you'll notice that the underlying principle seems to be:

If the programmer is responsible for the decision, the program is discarded; but if the user is responsible the program is kept.

But why not just keep all programs, for all time? There are many reasons why a program brought out of hibernation could incur costs:

1. The hardware environment has changed.

2. The system software environment has changed.

3. The size or format of the data has changed.

4. The human environment has changed.

5. Some part of the program or its supporting material has been lost or damaged.

So it does cost to rerun an "unchanged" program, and the longer the period of hibernation, the greater the cost. But you already knew this—we all know this. Then why, oh why, do we keep tumbling into the same trap? And how do we get out, or stay out, of the trap.

Well, we'll watch for readers' ideas on these questions, and next blog entry, I'll give a few ideas of my own.

Who is Right, and What is to Be Done About It? (2)

Today, I give the rest of the story as it actually happened, then consider some of the astute comments given already.

What the Consultant Did
The consultant was astonished by the programmer's response: "That's not an error. Actually, the formula was in error, so I corrected it. The formula I programmed is correct, whereas the original formula was simply wrong."

The consultant understood, which the programmer did not, that a program error occurs when the program does not do what the customer wanted, not what the programmer thinks the customer should have wanted. That was the programmer's first mistake.

The programmer's second mistake was not understanding who his customer was. He seemed to think that the French were the customer, but the actual customer was the consultant.

(NOTE: If the actual customer had been the French, the programmer's action was still wrong, because of his first mistake. If a programmer thinks his customer has asked for the wrong thing, he could, politely, bring this thought to the customer's attention. So, if the French had been the customer, the programmer's third mistake was not bringing his thought to them. And even if the customer had been correctly identified, the programmer's fourth mistake was being rude and arrogant. That's simply not the way to get your point across, especially if your point is that your customer has been wrong.)

What the Consultant Said
"You didn't understand your assignment," the consultant said. "We're trying to simulate the precise formula used in France so we can compare it to the formula used in other countries. It's not a question of right or wrong, but merely of matching the existing French formula."

"Well," the programmer replied, "anyone with half a brain and a smattering of knowledge of inventory theory can see immediately that the French formula cannot possibly be correct, so what's the sense of programming it? Tell them to use my formula, if they want to improve their inventory management."

The management consultant decided to try another approach with the recalcitrant programmer. "That's a good idea. If you're right, I'm sure they'll really appreciate getting a better formula. In the meantime, it will help them to accept the new formula if they can see how it compares with their original one on this data, so I'd appreciate having their formula programmed as soon as you can manage."

"You don't seem to understand," the programmer insisted, "Why should I waste my valuable time on a formula I know is wrong? Just show them my formula and they'll understand."

At this point, the management consultant gave up on the programmer and got himself another one. The French formula was programmed and found to give the claimed results which were, in fact, superior in many circumstances to the approaches used in other countries. It turns out that the programmer's fifth mistake was overestimating the "correctness" of "inventory theory."

Readers' Comments
A number of readers correctly (I believe) said they would try talking with the programmer. In the actual case, the consultant tried this, but learned that the programmer was not going to listen. Perhaps this was the consultant's fault in the way he tried to talk to the programmer, but in any case, if your employee (and the programmer was, of course, working for the consultant) won't talk with you about a situation, then you have to get rid of that employee. So, attempting to talk is a good approach, in that it gives you essential information even if the programmer refuses to talk.

Other readers warned the consultant to consider his own role carefully, and to consider myriad possible interpretations of what's going on. This is always good advice for a consultant.

Several readers correctly identified one or more of the programmer's mistakes (above). Clearly, someone needs to educate the programmer about what his job is, and how to do it, but evidently the consultant lacked the skill to accomplish that. So, again, the consultant needs to consider his own role, at least for the future. In a similar situation, for example, he might take more care in choosing the programmer and/or making the programmer's task much clearer from the outset.

Those who advised the consultant to get "on the ground" with the inventory application were also on a productive track. In this case, the consultant was in the USA, and meekly accepted the refusal to pay him to travel to France and study the French approach first hand. If the consultant knew what he needed but didn't insist on having it, he made a major consulting mistake. If you insist, but your client won't supply it (time, or access, or money, or whatever), then the consultant should simply resign from that assignment.

Using specific examples rather than simply theory—what a good idea. Both the consultant and the programmer were probably "intuitives" in the MBTI sense, so they kept the discussion on the level of theory, which often misses some crucial data. In this case, if the French formula actually worked in practice, that would have thrown an entirely different light on the discussion.

Next Steps
All in all, the case example seems to have done its job—namely, stimulating an outpouring of darn good advice about consulting and programming.

Now that you have the "whole story," what further observations would you like to make as comments?