| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
|
---- * James Shore, in [http://jamesshore.com/Change-Diary/Weeks-One-Through-Eight.html Change Diary]: ''I seem to remember making this fundamental mistake over and over. It was really a problem of arrogance: I thought I knew the answers and I thought all I had to do was show the yokels how to do things right.'' ''No, I didn't really think of people as "yokels." I knew this arrogance was a problem and I tried to suppress it. I even wrote some notes about not being arrogant. But arrogance simmered deep-down. It prevented me from going to the group and asking their permission to make decisions together. Rather than work __with__ the group to come up with good ideas, I tried to __sell__ the group on __my__ ideas. If I had worked with them, I would have been much more effective.'' |
Jerry Weinberg's book, Weinberg on Writing: The Fieldstone Method (093263365X) describes a technique of gathering ideas like fieldstones until you have a collection with which you can build a book. Such a technique may not make you a William Faulkner or William Shakespeare, but it will enable anyone to become a journeyman author.
Fieldstones can come from anywhere. Here are some pointers to some I've come across:
James Shore, in [http://jamesshore.com/Change-Diary/Weeks-One-Through-Eight.html Change Diary]:
I seem to remember making this fundamental mistake over and over. It was really a problem of arrogance: I thought I knew the answers and I thought all I had to do was show the yokels how to do things right.
No, I didn't really think of people as "yokels." I knew this arrogance was a problem and I tried to suppress it. I even wrote some notes about not being arrogant. But arrogance simmered deep-down. It prevented me from going to the group and asking their permission to make decisions together. Rather than work with the group to come up with good ideas, I tried to sell the group on my ideas. If I had worked with them, I would have been much more effective.
- Michael Hill (on the XP mailing list):
There are four criteria for a good [user] story:
Verticality -- It must run from "pixels to bits".
Testability -- It must be testable.
Fit -- It must be small enough to fit comfortably in one iteration.
Value -- It must be something the customer wants.
from Mark Gerzon's [http://hbsworkingknowledge.hbs.edu/pubitem.jhtml?id=5351&t=leadership Moving Beyond Debate: Start a Dialogue] article:
As I worked in more than a hundred organizations or communities over the past decade, I kept track of which form of discourse my clients most often wanted. They did not want more speeches and presentations. They did not want more debates between two know-it-alls, each of whom was sure they were right and the other person was wrong. They did not want yet another "exchange of views" that skirted difficult issues and papered over problems. What they yearned for was deep, honest, inclusive, and respectful dialogue. Dialogue is designed for situations in which people have fundamentally different frames of reference (also called worldviews, belief systems, mindsets, or "mental models"). "Ordinary conversation presupposes shared frameworks," says Daniel Yankelovich, who has been a pioneer in analyzing public opinion for the past quarter century. Dialogue makes just the opposite assumption: It assumes that the participants have different frameworks. The purpose of dialogue is to create communication across the border that separates them. It is a way of conversing that:
Enables a wider range of feelings to be expressed than in debate.
Inspires more honesty and forthrightness than other methods.
Avoids superficial, forced compromises.
Generates learning, new options, and innovations.
Increases the likelihood that everyone will be "heard."
Seeks the deeper truth in each perspective.
Simply put, dialogue fosters the trust that is essential to leading through conflict. Its purpose is not to be nice. Its purpose is to be effective. When it comes to conflict, it is far more effective to build trust than to deplete it. Every tool we have used so far has helped to lay a stronger foundation for trust building."
from Ed Gibb's blog, [http://edgibbs.com/2006/05/01/agile-methodology-context/ Musings of a Software Development Manager] blog:
"At the end of the day, it all comes down to common sense." Its a relevant point and one I tend to get caught up in. The point is really to adjust the process to fit the needs of the team and the context while making forward progress.
from Skip Angel's [http://spaces.msn.com/chiefskipper/blog/cns!A59D550BCED8263B!851.entry?_c=BlogPart#permalink Random Thoughts from a CTO] blog: In talking about the four project variables, Cost, Schedule, Scope, and Quality, Skip says,
"Clarify your quality. Make sure that the project team knows how to measure the success of the project (In other words, what is good enough?). What are your quality criteria i.e. performance, scalability, usability? What is the threshold measure for each of the criteria e.g. Each function must handle x customers at once time at take no longer than y time? What is the priority of each of the criteria?"
Where in here is the Quality that differentiates extensible, maintainable code from cut-and-paste hack-it-together spaghetti? That's the Quality I mean.
from Annie Lamott's Bird by Bird (via [http://ellen-kushner.livejournal.com/42408.html?thread=478376#t478376 Ellen Kushner's blog]):
"I thought such awful thoughts that I cannot even say them out loud because they would make Jesus want to drink gin straight out of the cat dish."
Bruce Eckel's [http://mindview.net/FAQ/FAQ-006 definition of mentoring]:
Consulting guidance on a project - that is, a team is working on an actual project and the mentor comes on site periodically and helps "steer the boat," which includes reviews and walkthroughs of design, code, and/or process. You could think of it as "someone to watch over you."
J. Steven York's [http://york-multiplex.blogspot.com/2006/03/writers-and-other-delusional-people.html writing blog] states:
"Stealing words is a crime. Stealing ideas is frequently a smart thing to do, but always steal from the best. Start with Shakespeare and work your way forward."
"And remember that you don't even have the right to call yourself a failure if you don't try, and you still don't have the right unless you've stopped trying. Until then, you're still a success waiting to happen."
[http://www.altisinc.com/Links/100_Rules.html One Hundred Rules for NASA Project Managers] by Jerry Madden includes such gems as these:
Rule #8: Running fast does not take the place of thinking for yourself. You must take time to smell the roses. For your work, you must take time to understand the consequences of your actions.
Rule #43: Documentation does not take the place of knowledge. There is a great difference in what is supposed to be, what is thought to have happened, and reality. Documents are normally a static picture in time that get outdated rapidly.
Rule #63: Software has now taken on all the parameters of hardware (i.e., requirement creep, high percentage of flight mission cost, need for quality control, need for validation procedures, etc.). It has the added feature that it is hard as blazes to determine it is not flawed. Get the basic system working first and then add the bells and whistles. Never throw away a version that works even if you have all the confidence in the world that the newer version works. It is necessary to have contingency plans for software.
Rule #82: Wrong decisions made early can be recovered from. Right decisions made late cannot correct them.
Rule #87: Projects require teamwork to succeed. Remember, most teams have a coach and not a boss, but the coach still has to call some of the plays.
Rule #88: Never assume someone knows something or has done something unless you have asked them; even the obvious is overlooked or ignored on occasion, especially in a high stress activity.
Rule #90: A puzzle is hard to discern from just one piece; so don't be surprised if team members deprived of information reach the wrong conclusion.
Rule #94: Mistakes are all right but failure is not. Failure is just a mistake you can't recover from; therefore, try to create contingency plans and alternate approaches for the items or plans that have high risk.
Rule #96: Experience may be fine but testing is better. Knowing something will work never takes the place of proving that it will.
Rule #100: Never make excuses; instead, present plans of actions to be taken.
Also see this [http://appl.nasa.gov/ask/issues/14/practices/ask14_lessons_madden.html similar and related list].