Showing posts with label rules. Show all posts
Showing posts with label rules. Show all posts

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.

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.

Wednesday, December 14, 2011

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.

Wednesday, September 21, 2011

Why English Will Never Be 100% Automated: Example

One of the nice features of the Kindle eBook service is they way they copy-edit some of their better-selling books. This can be a particularly important service for print books that have been scanned to make eBooks. For instance, Amazon recently wrote about my Kindle book, An Introduction to General Systems Thinking:

Typo issues exist that may have been caused by an Optical Character Recognition (OCR) problem. Few examples are given below:

loc 1561 - "T call them" should be " I call them".
loc 2946 - "But 1 still can't" should be "But I still can't".
loc 3351 - "Shasta the liger" should be "Shasta the tiger".

Please look for the same kind of errors throughout the book.


The first two instances are common OCR (Optical Character Recognition) errors: "T" for "I" and "1" (the numeral) for "I" (the capital letter).

The third example is a not quite so common OCR error, "l" (the letter) for "t". And, in this case, it's not an error at all.

The sentence in question was:

We do not often have our excessively sharp view of the world challenged by phenomena like Shasta the liger at the Salt Lake City Zoo, whose father was an African lion and whose mother was a Bengal tiger.

Still, the sentence contains a more subtle error: the failure of the author (me) to account for the mental state of the typical reader, for whom the term "liger" may be unfamiliar. (Even though it is found in at least 16 on-line dictionaries.)

I corrected this much more subtle error by redrafting the questionable sentence as:

We do not often have our excessively sharp view of the world challenged by phenomena like Shasta the "liger" at the Salt Lake City Zoo, whose father was an African lion and whose mother was a Bengal tiger.

As I dealt with this situation, I kept sighing and thinking, "English will never be entirely automated."

And then I took a deep breath and thought, "I suppose I prefer it that way."

How about you? Would you like English to be entirely clear and logical?

An Introduction to General Systems Thinking

Tuesday, August 17, 2010

Attendance Too Regular? Try This!

Inspired by Ajay Balamurugadas's blog at

http://enjoytesting.blogspot.com/2010/08/aware-of-other-side-of-your-application.html

The title was Enjoy Testing

which starts with:

"For the past few months, I left office at sharp 6 p.m. I felt I should not invest more hours just because someone's estimate was wrong. So, I always took the 6 p.m. cab to home instead of the 8 p.m. or 10 p.m. cab."

And Michael Bolton commented:

"...I perceive that resolution to the trickiest part of the problem starts with recognizing people."

Michael is right. It starts with people. And guess who is the first person to recognize?

Yourself, of course.

The very first thing that struck me about the (quite fine) post was the regularity with which you come and go to work. Ordinarily, such regularity is a highly valued trait. For example, people can count on knowing when you'll be there and when you won't. Very good contribution to communication--and thus very high on every tester's list.

However, as an experienced tester, you already know that too regular, too predictable, behavior is a way to miss a great many bugs--and that's true of the regularity in attendance, too.

I would suggest you come in a couple of hours early on some random day next month, and (on a different day, probably) leave quite late. And, if you have people who work night shifts, arrange to be around for one or two of those.

I probably didn't have to explain why, but some of Ajay's readers may be less experienced than others. Experienced testers can probably all tell stories of when they came in early or left late (or were somewhere they weren't usually expected to be, or even prohibited to be) and because of that noticed something that led to a bug they never would have seen otherwise. (Perhaps something they were totally unaware of.)

I myself can tell many such stories, including one that may well have saved astronauts' lives, so I regularly practice being somewhat irregular in my behavior as a consultant (yes, I know that's a paradox).

Sunday, August 23, 2009

50 Ways to Improve Your Business

At last week's BizConf, I ran a session based on an idea from Dwayne Phillips, where a bunch of independent businesspeople brainstormed 50 small ways to improve your business. The ideas flew fast and furious, so I assigned two participants, each to capture alternate ideas. Even so, it was hard to keep up with the flow. The lists were quite overwhelming, so I'll present them in two separate blogs. Today, it will be Jason Seifer's list. Jason said, "I wound up just logging everything, because I touch type like in your first rule."

So, here's Jason's list:

1. Learn to touch type.
2. Back-up everything. Every day.
3. Keep as much stuff online as possible.
4. Do nothing. Don't do something if someone can do it better. Don't do it if someone else can do it adequately. Do it anyway if it makes you happy. Don't do it if someone else can do it 85% as well as you.
5. Anything not worth doing is not worth doing right.
6. If in doubt charge for sales trips. If they're not willing to pay for it they don't value it.
7. If it's not on paper don't do it. If there's money involved it has to be written down. Never agree to money over the phone. If on phone, confirm in writing.
8. Listen to what other people are telling you. Instead of communicating to somebody, communicate with somebody.
9. Always have an exit strategy.
10. Make your client feel like they have a final part in the outcome. Make sure they have their fingerprints in it.
11. Listen to what they're not saying. Listen to body language and tone of voice.
12. Always be ready to sell your product if they're interested. And if they're not.
13. If you're bashful about your product, there's something wrong with your product.
14. Any successful services company has some fixed product that they sell. Have a ladder leading to your ultimate product. Don't make one big leap to the final product.
15. Make sure your contracts have some kind of follow-through so you can see how they actually came out. You won't know if you're doing well if they don't come back.
16. If you just build it they probably won't come. Alternately: if you build it be prepared to wait.
17. Manage expectations.
18. Time spent in recon is time well spent. But you have to be watching. "You can observe a whole lot just by watching."
19. Go hard or go home. Fully commit the resources to make something work or mercilessly kill it. You may not always know when it's time to kill it.
20. Ideas by themselves are not as valuable as you think they are. Ideas aren't worth anything so don't guard them too closely. "There's nothing as dangerous as an idea if it's the only idea you have."
21. Never rest on your past successes, there's always something more you could be doing. If you're not learning you're dead.
22. Sharing competitive advantages brings back advantages ten-fold.
23. Be able to say "No" to a potential client.
24. Research your clients as if you were doing the hiring.
25. If you're in the services business every client is unique. "We're different" "You are, just like everybody else."
26. You don't have to remember everything to succeed.
27. It's always ok to let a client go if it's not the right fit any more.You should organize your business so it's ok to let any one client go at any time.
28. The best way to build a business is to stay in business. Build your business so that you hang around. You may not make a lot of money but you build your reputation.
29. Actively solicit feedback from clients.
30. Actively extract the feedback. There's a lot of feedback you may not pick up on.
31. Make sure you're not alone in your role. This way someone can be honest with you.
32. Anything that's annoying and repetitive should be automated or stopped.
33. Track your budget/cost every month.
34. Don't make sampling mistakes about your budget and cost. One of the major mistakes that people fail at is expecting that income will stay the same. You might land a big client this month but might not have one next month so don't overspend.
35. Don't spend your money on office decorations. Very few of us are in a business where clients come to your office. You don't want your customers to think you're spending their money on their office furniture.
36. Make sure you've worked with someone before you hire them (if possible).
37. Learn the big lies you get from clients.
38. Double your reading speed.
39. Cut down on what you read.
40. Stay off facebook and twitter unless you can relate it to your business.
41. Sometimes you can save money by spending money.
42. Sometimes you can save money by not spending money.
43. Everyone who wants to sell you something will tell you it saves money.
44. The examples might not always teach what they're supposed to.
45. Many minds can do a better job than single minds. But not necessarily so.
46. You have to be organized.
47. Know your own limitations.
48. Learn quickly whether or not you want to work with someone.
49. If you see an organization with no enthusiasm for what they're doing they probably don't have enthusiasm for what you're offering.
50. If an organization doesn't care enough to organize, nothing is going to happen.
51. Don't mistake a solution idea for a problem definition.
52. People want a recipe but no recipe works for every organization.

So, that's Jason's (half) list. Each one could probably be a blog entry, at least, so if you want clarification, or to clarify, add a comment. I'll post Wolfram's (half) list when the traffic on this one dies down.

Friday, November 14, 2008

What is an Alcoholic?

A commenter describes his drinking habits and says they don't interfere with work. He wants to know how I define "alcoholic"?

I think he and I agree that the question turns on how your drinking affects your work, short term and long term. Since everybody's physiology is unique, I don't think the definition can depend on how much someone drinks. What would put me in the hospital (I have a severe reaction to alcohol), might just be a thirst-quencher for someone else.

One problem with this approach is that alcohol definitely tends to take the edge off one's judgment. I have dealt with a number of worker/drinkers who believe their work is not affected by their drinking--but the reason I was asked to speak with them is that their work effectiveness has been dropping noticeably, according to their managers.

I see lots of moral judging about alcohol consumption, which in turn leads to a lot of defensiveness on the part of those who enjoy drinking. For me, I don't care if your work is affected by alcohol, M&Ms, or listening to too much opera. If something is affecting your work, then that's an issue for your manager and possibly your co-workers.

If it's affecting your health (long or short term), that's your business, and perhaps the business of your family. Of course, if it's affecting your driving, then it's my business as long as we're sharing a road. I won't accept rides from people who have been drinking--or who might be otherwise impaired.

In short, I'm concerned about your alcohol habits only insofar as they affect me. It's an individual judgment, not a stereotype--but it's definitely a sterotype for lots of people, something alcoholics have to live with in today's society.

Sunday, July 29, 2007

Working Conditions that Prevent Consultant Misery

In my workshops, I always set aside time for consulting with participants on any situation they choose. In a recent Problem Solving Leadership workshop, I spent some of this time with Celia, a programmer working as a consultant/contractor. Because she questioned some of the company's business practices, Celia was deeply troubled by the implications of her latest contract offer. "What they want me to do for them will affect the lives of thousands or millions of people," she told me.

"That's not unusual," I said. "It's the nature of networked information systems."

"But my programming is invisible to them, and most of their customers won't know what's being done to them by the system–and that it's being done by me. That's too much power for me," she complained. "What can I do about it?"

Celia wasn't willing to accept those meaningless standard explanations: “That’s the way the computer must do it,” or the even more insidious, “That’s the way things are.”

I reminded her that some consultants in her situation salve their conscience by sabotaging their client's information systems in small ways. In many cases, it’s difficult to tell whether this is an conscious or unconscious reaction to their client's questionable practices. I've seen cases where I didn't doubt the subversion was conscious, but Celia wasn't interested in sabotage. "It's not in my nature," she said.

I then explained that at least she wasn't alone. Many consultants have complained to me that their current assignment holds no meaning. They don’t know what is being done with their work, or they do know and don’t approve. Their response is to stay on the job, draw the fee, and badmouth their client at every safe opportunity. Again, Celia said this wasn't her way.

I know lots of consultants like Celia, consultants who feel an enormous responsibility to the people whose lives will be impacted by their work. These people ask me, as did Celia, "If I don’t believe in what my client is doing, or I don’t understand it, then why should I be I working there? To draw a fat fee? If so, what does that make me?"

I offered Celia a set of principles I've always used when taking a new assignment, principles that have kept me out of certain kinds of troubles for many years:

1. I will not work for an organization whose goals are not consonant with my own beliefs.

2. I will not work on projects whose goals I do not understand, or cannot agree with.

3. Before becoming part of a project, I will first obtain agreement on what percentage of my time I can (and must) spend on continuing professional development, and what resources will be provided me for that purpose.

4. I will not work under measurement schemes that pit one person’s performance against another’s. Rather, I will cooperate totally to help others in the project achieve their full potential, as I expect them to help me do.

5. I will not accept work without understanding what is to be done, and why, nor will I pass work to others without their similar understanding.

6. All my work will always be open and available for critical comments (circumscribed, as appropriate, by real security considerations); and I will always stand ready to review the work of others in exchange for them returning the reviewing service to me on my work.

7. As long as the above conditions are met, I will devote myself in the utmost to achieving the goals of my project and the organization that has retained my services.

Sometimes, a manager trying to hire me is outraged at one of these conditions. That's unfortunate, but it's a sure indication of trouble later, if I make the mistake of accepting that assignment.

Over the years, I’ve found that consultants who ask these questions and set those conditions don’t wind up in assignments that make them miserable. Sometimes, when they ask them honestly, they leave their present position for somewhere else that makes them happier, even at a lower fee.

Saturday, June 02, 2007

The Exception is the Rule

Recently, I was trying to help a client (let me call them "StartupCompany") mired in conflicts, exceptions, errors, anomalies, lapses, modifications and other deviations from the norm. These annoying exceptions were playing tricks with my blood pressure, so I had to be wired to a wearable blood pressure computer for twenty-four hours. As if StartupCompany didn't have enough interruptions, now my wearable computer was inflating a blood pressure cuff at random intervals throughout the day.

Every time the cuff inflated, I petulantly asked myself: Why can't they run a project like real people living run-of-the-mill, low-blood-pressure lives?

That night, I was using the Yellow Pages, and in the A categories in the Yellow Pages index, I chanced to notice a curious pattern. Here are the first few items:

Abortion Services and Alternatives. These were the first two entries in the index. I decided to skip them both, so as not to take sides in the pro-choice/pro-life conflict. I had enough conflicts within StartupCompany.

Abuse - Men, Women, Children. I decided to continue my scan of the index, and this was the next entry. The normal process of family living involves people loving and respecting each other, communicating well, and behaving appropriately according to societal norms. But when people start behaving inappropriately, they need Abuse Services. In StartupCompany, people normally respected one another, communicated well, and behaved appropriately according to societal norms. But they sometimes didn't, and they lacked "abuse services" for coping.

Academies (including private schools and special education). When the formal education system doesn't provide special knowledge or handle special cases, private academies and special education are called for. People within StartupCompany often needed to know things they hadn't learned in the public schools, but StartupCompany had no provision for special education.

Accident Prevention. Accidents aren't "supposed" to happen, StartupCompany had accidents. In order to improve, they needed processes to prevent accidents and to mitigate their consequences.

Accordions. Despite what some people think, accordions are perfectly normal, though not everybody learns to play them or appreciate them. Still, StartupCompany could have used some entertainment to lighten the mood once in a while.

Accountants. Accounting is also normal, but, if everything always went according to plan, we wouldn't need to account for things so carefully. We have to protect our financial well-being from mistakes and misbehavior, and that's what accountants do - and also what they should have been doing in StartupCompany.

Acetylene Welding. Some welding is normal, and some is for repairing things that are not supposed to break - but do anyway. StartupCompany lacked a "welding team" to handle lots of stuff that broke.

Acrylic Nails. Most normal people have fingernails, so why is there a nail business? Oh, yes, it's the human interface, and StartupCompany had to cope with conflicting ideas of what made a system beautiful - but they had no special beauty experts to resolve the conflicts.

Acting Instruction. We all need to "put on an act" now and then when we're caught by surprise. StartupCompany's people certainly needed training in how to behave in improvisational situations, but there was no acting instruction.

Acupressure/Acupuncture. If we were all healthy all the time, we wouldn't need medical services, and if "normal" Western medical services worked all the time, we wouldn't need acupressure and acupuncture. So, there are not only abnormal services, but meta-abnormal services - the services when the normal abnormal services fail - certainly true in StartupCompany.

Addressing Service. Have you ever tried to maintain a mailing list? Almost all the work is not the mailing itself, but maintaining the addresses. It's even worse for email, because email services haven't yet evolved "normal" ways of dealing with changes. Gee, neither had StartupCompany.

Adjusters. Adjusters, of course, are an abnormal service from the get-go. Without accidents, we wouldn't need insurance, and if things stayed on course, StartupCompany wouldn't have needed risk analysis. But they did.

Adobe Materials and Contractors. Adobe materials may not be "normal" where you live, but here in New Mexico, adobe is a normal building method. StartupCompany, too, has its idiosyncratic processes that are not normal in other projects - and newcomers have to learn about them or pay the price. But StartupCompany had no special services to bring newcomers up to speed.

Adoption Services. Yes, sometimes people are not wanted by their parents, and StartupCompany certainly had some unwanted people. But, they lacked "adoption" services for moving unwanted people around.

Adult Supervisory Care. "Normal" adults can take care of themselves without supervision, and normal workers wouldn't need much managing at all. But StartupCompany had two adults who could not take proper care of themselves, and the managers spent an inordinate amount of time on these two out of a hundred.

I stopped there, sobered by my reading. It was now clear to me that StartupCompany, being a startup, had an overly simplistic picture of what it takes to run a company. I needed an adjustor to adjust my blood pressure - I needed to see that my job as their consultant was to teach them that deviations are normal, and that they (and I) could do what real people do:

• stop whining and deal with them

• create systems to deal with them

• create systems to prevent them

And, of course, I have to do these three things in my own company - like not whining about my blood pressure.