Is it real or is it Agile? (Part 1)

Well, I'm writing my blog again, now that my book, Experiential Learning: Inventing, is now published on LeanPub.com. But after only one week, the feedback has started, and I feel a need to respond.

My friend and colleague, Markus Gaertner was the first to write, all the way from Germany:

"I just started reading your second book on Experiential Learning. One thing that confused me is in the chapter Design and Development Inventions where you make a positive reference to agile processes. This confused me since you usually write in a timeless manner, and I don't consider agile processes to be timeless in--say--20 years or so."

The passage in question read like this:

-----

Sometimes the specification turns on the meaning of a word, such as “support,” or “height.” The trouble is, you don’t know in advance which word it turns on ... that depends on the design possibilities. Therefore, an organization or process that discourages back-and-forth communication will generally do a poorer job of designing things. That’s one of the reasons agile processes can work so well.

-----

My first reaction to Markus's comment was that he was exactly right. My half-century of experience tells me that in 20 years, the "agile" craze will have petered out, just like so many before it--structured programming, HIPO, Nassi-Schneiderman charts, and dozens of others. So most readers in 2030 or so, won't even recognize the word "agile" as a code.

Yet forgetting the code doesn't mean that "agile" principles will have disappeared as good programming practices. I was specifically referring to two sentences from the Agile Manifesto (you know, that document that a dozen of the guys worked out a decade ago, without the help of any women):

1. "Business people and developers must work together daily throughout the project."

2. "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

That's what I meant by "back-and-forth communication," and I believe those sentences will still describe effective programming practice a generation from now (as they did a generation ago, and two generations ago).

So Markus is right. There's no reason for me to date my book by using the code word, "agile." I published my Experiential Learning series with LeanPub.com so it could be a dynamic e-book, changing as the world changed and I learned to be smarter. So, I will update the next version with something like Markus's suggested wording:

"That's one of the reasons that software development works so well with bi-directional communication in place."

 (I'll also make a batch of changes suggested by Dani--who didn't even recognize the code word, "agile," in 2012--plus whatever other wisdom arrives from my readers.)

But, as usual, I'm not finished responding to Markus and Dani. In a later blog, I'm going to continue with some thoughts about what is "agile" really.

Experiential Learning vol 2: Inventing

Regular readers of this blog have probably noticed a reduction in my posting frequency in recent weeks. Perhaps you'll all forgive me when I tell you I've been distracted from blogging by finishing volume 2 of my Experiential Learning series, called Inventing or Invention, I can never remember which. Anyway, it says "invention" on the cover, and can be found here.

Anyway, it's about the part of experiential learning that comes after the experience--the part where we invent the learnings we've found during the experience. It's what converts an ordinary experience into a learning experience. If you're teaching experientially, you'll want to learn how to facilitate invention--but that's not all. The book is full of techniques I personally use to extract learnings from all my experiences, whether in a class or in life.

As we say in life-learning, "First you pay the tuition, then the learning is optional." If you want to take advantage of the learning you've paid for with your life, Experiential Learning: Volume 2, Invention is the book for you.

Shaping a Team

A Correspondent Writes

I have taken over a group of folks that I need to shape into a team. There are many issues including getting developers to write unit tests consistently, training my test engineers and deploying more test automation. More worrisome is that they do not want to change out of a poor pattern of behaviors. I suppose since they hit their delivery schedule they think things are OK. On the plus side, they say they are committed to quality.

What would you look more into? Tackle first? Is there an inspiring story I might share at my upcoming team building event to highlight the need to change?

Any advice is welcome and greatly appreciated.

Jerry Replies

Well, you're certainly experiencing a classical problem, one I've described in a number of places, including my Becoming a Technical Leader (in terms of my pinball expertise). They're stuck on a plateau, and it's going to take some skilled leadership to move them up to the next level.

The first thing you have to do is create a safe environment that will protect them while they are changing to new practices. Although those practices must be designed to improve the quality of their work, there is no doubt that at first they will slow them down and probably hurt quality. That's why they need protection.

Start small, with some step that ideally they will choose from a list you develop together. Choose something that's as sure to succeed as possible, and it will help them in some obvious way. In other words, you want to start with a guaranteed success, and then build up from there.

 Beyond that, I suggest you read my books on change

- BECOMING A CHANGE ARTIST

- CHANGE: Planned & Unplanned

- Change Done Well

Writers Need Feedback

I recently received an email containing the following paragraph:

"A tester peer of mine here in town recently told me a great story of how your book, Perfect Software, helped save one of his tester's jobs. He gave the book to his Manager and it changed the manager's mind about testing and the need for good testers. I've encouraged my peer to contact you with the story in more detail and will keep doing that."

I love to hear stories of how my writing is influencing real people to change their world (for the better, I hope). I specifically intended Perfect Software and Other Illusions about Testing for the purpose of educating managers and others who require a better understanding of software testing if they are to do a better job.

Do You Have a Story?

I'd love to hear your story of how one of my writings helped you do a better job. I'd even like to hear your story of how one of my writings led you to do a worse job. I need this kind of feedback if I'm to do a better job myself.

In fact, I'd even like to hear stories about how other authors' writings helped or hindered your work. Or, even better, about writings that helped improve your life. Or made it worse.

I suppose I should give an example. Okay, like many smart people, I used to use my intelligence to think of reasons I should be miserable. That kind of thinking made me a rather miserable person. Then I read Bertrand Russell's little book, The Conquest of Happiness. Russell's words showed me that I could use my intelligence to be happy, not miserable. They changed my life.

They say that the pen is mightier than the sword. Well, we don't use pens much any more (or swords, for that matter), but there's still plenty of power in our keyboards. With all that power, we need to know if we're using it to people stronger or to lop off their heads.

So, let me hear from you, and I'll try to pass your feedback on to the whole world of writers.

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.