Monday, January 23, 2012

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, 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 You will find the story at this address:

Or, on Kindle, it's at

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

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, including the Stringer Series, so far.

Friday, January 20, 2012

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)

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

Tuesday, January 17, 2012

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?"

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.
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.

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.

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.
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.
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."
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.
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.

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.

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 and/or take a look at

Sunday, January 15, 2012

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.


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.

Thursday, January 05, 2012

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.

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.


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