Peter Principle Simulated

Some Italian professors have tried to simulate the famous Peter Principle:

"All new members in a hierarchical organization climb the hierarchy until they reach their level of maximum incompetence."

http://www.technologyreview.com/blog/arxiv/23800/

The Peter effect arises from the practice of promoting the best performer at Level N to a position at level N+1.

The Italians also simulated two other promotion policies:

1. Alternately promote first the most competent and then the least competent individuals.

2. Promote individuals at random.

According to their simulations, each of these methods improves the efficiency of an organization over the Peter method.

My thought: They could try promoting on the basis of who is most suited for the next level job. Duh!

Or maybe they could try not mixing the concept of "promotion" with that of "reward."

Or maybe even getting rid of the hierarchical notion altogether.

The Paul Principle

As a relevant post-script for my audience, they might want to look into the "Paul Principle," proposed by Paul Armer, who, like me, started out in computing as a desk calculator operator (or "computer" as we were known back then).

"People become progressively less competent for jobs they once were well equipped to handle."

Paul proposed his law in 1970, the year after Peters proposed his. Paul claimed his principle was more relevant in high-tech fields, when the complexity of jobs grows faster than the people doing them. The Paul Principle has been virtually forgotten, but I think it is still worth some careful thinking by IT managers and consultants.

The Other Paul Principle

It seems there's another "Paul Principle," after St. Paul's treatise in Corinthians:

"Continue to provide people with what they need to succeed."

I suspect this management principle would also prove more effective at growing an organization than the Peter Principle.

Perhaps those old Pauls knew something that's still worth studying today.

Why Choose One Conference Over Another?

In these days when money is short, lots of people cannot afford to participate all the conferences they might have attended last year. Money may be the first criterion for choosing conferences, but it's not the only one. I'm going to three conferences this year, each chosen by different characteristics. For me, money doesn't enter into it, so my reasons might be helpful for those who can afford to be in at least one conference, but are trying to choose. my first step in choosing a conference is to eliminate the majority of conferences by applying the following guides.

What Makes Conferences Less Attractive

I generally eliminate conferences that

- overschedule event with no time or place for spontaneous meetings

- overcrowd, usually to maximize profits, with just too many people, which encourages people to hang out only with their old pals

- lack adaptability so opportunities pass by without notice or care

- offer too much lecturing, not enough interaction, and insufficient experiential work--or none at all

- invite presenters of widely varied and untested skill and preparation

- do not name their presenters in advance, or give biographical information

- provide insufficient time and space for socializing, meeting new people

- allow little or no interaction with the presenters (In some conferences, presenters eat in a special area, intentionally separated from the participants. In others, presenters speak and run.

- schedule sales pitches instead of teaching presentations

- schedule canned pitches instead of original material

- offer too many plenary sessions, when participants have no choice of what to attend

Few conferences meet all my criteria, but I look for those conferences that do, like the three (below) that I am attending this year. I have long-ago reached a stage in my life where I cannot tolerate several days sitting in an uncomfortable chair listening to someone read bullet points from PowerPoint slides.

CAST

[http://www.associationforsoftwaretesting.org/drupal/CAST2009]

I participated in the Conference of the Association for Software Testing (CAST) last year, and I'm returning this year because the subject of the conference is precisely focused on my current interest: promoting and improving the practice of software testing.

The sessions I attended were all of high quality and interest to me. Also, it's a reasonably small conference with numerous opportunities to participate in spontaneous hall sessions.

BizConf

[http://bizconf.heroku.com/]

BizConf is a new conference this year, and I'm participating primarily because of the other participants, who, like me, are small entrepreneurs running technology businesses. It's a small conference, limited to 75 participants, and scheduled once again to encourage spontaneous hall and meal sessions. All of the presenters I know are of the highest quality.

AYE (Amplifying Your Effectiveness)

[http://www.ayeconference.com]

You might say I participate in AYE every year because I'm a host--one of the people who created the conference. But I wouldn't have been a host in the first place if I had been satisfied with most of the conferences available. When we designed the conference, we had several issues in mind in addition to the ones listed above. We wanted the conference to be reasonably priced, easy to reach, and easy to learn more about than could be found on a simple website. We created a wiki that registrants could write on and anybody could read. We retained a small staff of intelligent, personable people (Lois and Suzy) to give information and solve problems over the phone. I hope we've made it easy to get to AYE, and I hope to see you there or at one of the other two conferences I'll be attending.

Was There Process Before Agile?

Reader June Kim recently wrote:

On p.328 of Volume 4 of your Quality Software Management series, the first line goes:

"Here's another example, mixing incremental development and hacking:"

In this Chapter 18, the process models you mention and describe are Waterfall, Cascade, Iterative Enhancement, and Prototyping (with Hacking and Rapid Prototyping as its variants). There isn't incremental development.

"incremental development" as you wrote on that page, doesn't appear before that line in the chapter.

Is Agile An Example of Incremental Development?

QUESTION: Which process model are you referring to when you wrote "incremental development"?
Is it one among the four process models that you mentioned earlier in the chapter, or Is it something different?

ANSWER: First, you have to remember that when QSM was written, there was no "Agile" development craze. We were doing various development process, some of which were given capital letters, some which were not, and some which were "owned" by certain advocates. I was trying to be descriptive then, not favor anybody's pet process.

There were some "owned" processes (using the hated word, "methodology," and charging tens of thousands of dollars for shelves full of notebooks which nobody read). I suppose some of them are still around, but most of the organizations I work with are now smarter than to fall for that fallacy. For the most part, every organization custom-tailored its own process (or, in most cases, processes, plural).

Of course, that's still true today. I don't find many organizations using some "pure" version of agile.

Where Do You Place Agile?

QUESTION: I am interested where you would put Agile process. I think Agile(XP and Scrum, for example) is closest to Rapid Prototyping as you described.

ANSWER: Historically, the people who first named "Agile" processes were borrowing the best of all these methods. You could also say that any agile process is a cascade (or iterative enhancement if you're actually putting each iteration's output into use). Agile is much more than these processes, making explicit many team practices to support the iterative nature of the development.

What Happens When the Customer Won't Participate?

QUESTION: If so, it has the same danger when the customer isn't willing to be the integral part of the process.

ANSWER: That's always the case, no matter what the method, if the customer is reluctant to participate. (Until the end, when they whine, "But that's not what we wanted.")

QUESTION: What could you do in this case? Drop Agile process?

ANSWER: It's not an Agile process if the customer (or surrogate) isn't participating. In fact, I would drop any customer who doesn't participate. That's the rule I use in all my consulting, too. I don't believe you can help people who aren't willing to help themselves.

QUESTION: Or, make the customer be the part of the process? Then how? This is still a hard question to me, even with 10 years of experience in agile.

ANSWER: It's definitely one of the hardest questions with Agile or any method. Hard for most technical leaders because they lack the training and skills to work with reluctant customers.

So, I train them in these skills (a major goal of the AYE Conference and the PSL workshop), but primarily everything starts by simply pausing the work unless and until the customer has been identified and persuaded to participate.

Session Based Test Management Advice

One of the challenges of a blog on consulting is the difficulty of showing what actual consulting looks like. From time to time, though, I receive a consulting request by email which can be answered with a brief email. Brent Plumley recently sent me a request and had given me permission to blog it and my reply, so others may share, and comment.

Brent's Situation

I am currently researching methods to improve our (Session Based Test Management) SBTM debrief/review process in an attempt to make the process more efficient and scalable. Our current process has the Test Manager reviewing 100% of the testing sessions. As the testing team grows, the test manager no longer has the capacity to review all the sessions and as a result a significant backlog session list has accumulated.


- I have several areas that I was hoping you would be able to provide some insight

(1) Testing Session Debrief Trade off

- When a test session is reviewed we consider the following and attempt to achieve a 10/10 score on each.

     (a) Quality of testing performed

          - Did all the risk areas get covered

          - Were the correct test techniques implemented

          - Are there anything missing(different combinations, order of events etc...)


     (b) Quality of Testing Notes

          - Do the notes clearly outline the testing

          - Is the testing reproducible using the notes

          - Does the test properly convey the thoughts and observations

          - etc...



- As a result, the time required to perform the debriefs is quite long.



QUESTION: When performing a session debriefs should we consider a trade off between 'time', 'Quality of Testing Performed' and 'Quality of Testing Notes'. (ie. spent less time, ensure 10/10 on 'quality of testing performed' and 6/10 on 'quality of notes') or, do you think that both (a) and (b) above are important?

(2) Debrief Process

- Even if we can reduce the time spent on session reviews, as the team continues to grow, we will once again be faced with the problem of scalability (more testers = more test sessions = more time needed to review)



- We are currently considering several ways to address the scalability issue


(1) Test Sessions are reviewed by other team members (peer-review process). This will help relieve the strain on the Test Manager of having to review all test session. Also, this will provide opportunity to all test team members to learn from each others unique styles.


ANSWER: This is what I usually suggest to clients in similar situations. The number one job of any manager is to develop the people who work under their mentorship. This is an excellent way to do so.


You can introduce this leadership training opportunity incrementally, with the early leads being supervised by the manager until she finds each person prepared to lead on their own.



(2) Test Manager continues to review the test sessions but depending on the experience level of the tester, only a certain percentage of test sessions will be reviewed (ex: 100% of sessions are reviewed for junior/New testers, and 15% of test sessions for more experienced testers)


ANSWER: Absolutely not. This simply encourages people to game the system by not having their test sessions reviewed. DO NOT DO THIS.


- I have identified several problems with both of the above options. For both options, the test manager may feel out of the loop as much of the testing is not reviewed by them. Ultimately it is the test manager that is responsible for signing off on the testing that is performed. If the session notes are reviewed by peers, or not reviewed at all (only 15% of experienced testers sessions are reviewed), the test manager personally cannot guarantee perfect coverage of testing.


ANSWER: Managers must know how to delegate. If you cannot delegate, you should not be a manager.


Option 2, however, is not a matter of delegating, but of abdicating.


Again, DO NOT DO THIS.


- We are currently leading towards the Peer-Review process. This will ensure that all test sessions are reviewed by someone, which will help guarantee proper test coverage.


ANSWER: I totally agree.


QUESTION: Do you know of any other debrief processes which have been successful for other companies?


ANSWER: Not successful ones.


QUESTION: What method would you suggest for keeping the test manager informed and in the loop? We have thought of bi-weekly team meetings where key points and high level outline of testing performed is presented. Of another option, the test manager will debrief a small sample of the test sessions to get a measure of the quality of testing and debriefing performed by their team.


ANSWER: Forget the sampling. Each person who leads a review should fill out a simple report that everyone, including the test manager, can see. (For more on such reports, see my book, The Handbook of Walkthroughs, Inspections, and Technical Reviews.)


I hope this helps, Brent. It represents half a century of observations on my clients, what works and what doesn't work.



My blog readers, of course, know that no advice works in every situation, though certain mistakes seem to repeat themselves with every new generation. Brent responded by telling me the advice was helpful to him, but let me know how this advice works for you. And ask for answers and clarification.

Why We Love and Hate Meetings

Did you ever notice how many consultants have back problems? I do, from too much time in miserable seats on airplane, working on my computers at home, or sitting in boring meetings at clients' offices.

Because of my back problems, I can't bend over easily, which means I can't do an effective job of cutting my toenails. So, when I need to trim my toenails, I visit a salon for a pedicure. While having my toes clipped, I read the available magazines, such as Brides, Modern Bride, and Elegant Bride.

Bridal magazines are incredibly popular, with 135 different ones in print last time I checked. Topics include Beach Weddings, Bridal Parties, Destination Weddings, Accessories, Cakes, Ceremonies, Decorations, Dresses, Etiquette, Favors, Flowers, Gifts, Invitations, Planners, Receptions, Traditions, Trends, and many others.

Looking at all these magazines, I asked myself, "Who reads this stuff?" Well, obviously, guys don't usually read it, because nothing in the magazines evokes any emotional response—in guys. For many women, it's a different story.

From writing fiction, I've learned that emotion sells writing. My Plotbusters critique group constantly tells me that my stories don't sufficiently describe or evoke strong emotions. I didn't understand their comments, because the rest of my reader network didn't agree with them. What was the difference?

My Plotbusters colleagues are all multi-published writers, but generally not techies like the rest of my reader network. Evidently, non-techies don't fully appreciate my fiction. They say, "It's not emotional enough." Why? Because mostly the stories do not involve conflict, random violence, death, bad sex, unrequited love, and so forth.

What they do involve is smart people trying to solve problems, step by step. To me, that's not boring at all, but, indeed, extremely emotional. Tremendously exciting—which perhaps defines me as a nerd.

Which brings me back to meetings—why they bore me and cause back problems.

When I walk a client's corridors, I frequently meet people on their way to meetings. Although these same people have told me that meetings are boring, they often seem excited when they're on their way to one. Why?

Over the years, here's what I figured out. Most of my clients' people are techies—nerds like me. They find the meetings boring when they don't seem to be trying to solve problems, step by step.

At the same time, what these meetings are doing is playing out an emotional drama—conflict, blaming, flirting, one-upsmanship, random outbursts, anger, and so forth. For these happy people heading for meetings, it's those the soap-opera aspects of meetings are the most exciting parts of their jobs.

To the techies, the interest in these soap-operas is a distant second to the interest in a well-conducted problem-solving session. On the other hand, all this drama—the stuff we contemptuously call "politics"—seems to be the bread and butter of the non-techies. Indeed, these people are often upset if I show them how to conduct well-run meetings, because I've taken all the joy out of their lives.

Maybe I should bring them Brides Magazine to read in the time they save. Or perhaps Hot Rod Magazine for the guys.

Oh, and BTW, if you like to read stories of smart people trying to solve problems and be happy, take a look at my eStore.

Reader Feedback: Sample Pages

If you want to have a successful business, you have to pay attention to customer feedback. In the case of eMarketing, that feedback can be fast and focused. Using Google Analytics, I discovered my eStore was attracting 50 or more readers a day, but most these potential customers were not buying books.

Following some astute reader feedback, I've now made sample pages available for each of the novels in my eStore:

Mistress of Molecules

First Stringers: or eyes that do not see

The Freshman Murders

The Hands of God

This way, my readers will not be buying a pig in a poke. We'll see if it works.

eNovel Store: First Month Report and Lesson

It's been about a month since I opened my eNovel store. After a snappy first two weeks, activity slowed to zero, and I thought nobody would ever buy another novel of mine, let alone put me over the tipping point where the novels would take off like Harry Potter.

I learned that worrying over day-to-day or week-to-week sales is a futile wasted of time. After one dry week, sales picked up again. If they stay at this level, I'll earn a small but welcome addition for my charities each year.

Will I be satisfied? I don't know, but at least I won't worry day-to-day. I've learned my lesson.

It's a worthwhile lesson for consultants in all phases of their business. By its nature, independent consulting is a highly variable business. As I wrote in The Secrets of Consulting, there are, theoretically, three states a consultant's business can be in: A: too much business; B: not enough business; and C:just the right amount of business. But no individual is ever in state C.

So stop worrying and do something about it. Me, I'm asking everyone I know to take a look at my book store.