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:
Matt Heusser describes a major [http://xndev.blogspot.com/2006/11/metrics-madness.html problem with using metrics]:
As they are presented in the textbooks (and I have read a lot of them), Metrics make things easier. After all, once we define "Good" and put performance metrics in the way, then all the decision maker has to do is breathe easy (when the numbers keep going higher) or make a stink (when they don't.)
Now, read that paragraph again. I submit that in some cases, it's not really about making the job easier - it's about creating a situation where people don't have to think. After all, they can just manage to the numbers.
Rosabeth Moss Kanter, a professor at Harvard Business School, [http://hbsworkingknowledge.hbs.edu/item/5525.html speaks about innovation]:
Look for small innovations, not just blockbusters. Big hits are rare, but too many executives swing for the fences with each new innovation. This not only marginalizes people who work on smaller projects, but also tends to result in projects modeled on existing market successesthat is, not that innovative. Truly new concepts often spring from smaller beginnings.
Create processes and controls. The innovation process is inherently uncertain, so companies must develop new ways of tracking progress in these units. Rewarding a manager who "sticks to plan" doesn't encourage something new.
Select the right leadership. Innovation teams can't be isolatedtheir ideas will never catch on. So pick leaders who not only can communicate inside and outside the organization but who also know how to foster a collaborative culture.
In short, there are a lot of specific things companies can do to encourage rather than stifle innovation. But overall, companies need a culture and way of working that emphasizes flexibility and attention to relationships across areas.
Ryan Cooper describes the [http://on-agile.blogspot.com/2006/10/trust-vs-camaraderie.html difference between trust and camaraderie]
When a team doesn't have trust, it's not a team at all. It's a group of individuals, each with seperate and often conflicting goals. This wastes time and reduces productivity.
Why do so many teams have camaraderie but not trust?
Building camaraderie is easy. Socializing is easier for some than for others, but if you put a bunch of people in a room together all day, day after day, soon enough they will be comfortable chatting and joking around. Building camaraderie does not require commitment.
Building trust does. It requires commitment both from individuals, and from the organization. Individuals must remember to give their co-workers the benefit of the doubt, always.
Michael Vizdos, (with Tony Clark drawing the cartoon), [http://www.implementingscrum.com/cartoons/implementingscrum-20061106.html says]
Because guess what... Scrum has a lot less to do with techno-bla-bla than it does dealing with people. Real people. On a daily basis.
Unfortunately, he also says
"You suck. And that makes me sad."
Only one person in the world can say that and get away with it (most of the time). His name is Ken Schwaber, one of the founders of Scrum. Funny thing is, he gets paid to give you this kind of advice.
This kind of advice sucks, and makes me sad. Even sadder, there are many people in the world who say things like that and get away with it. I've certainly said it (in different words), sometimes unintentionally and sometimes without thinking. And I know how destructive it can be. There are better ways of "dealing with people."
William Watkins, CEO of Seagate Technology, said in an [http://news.com.com/The+face+of+a+kinder%2C+gentler+Seagate+-+page+3/2008-1015_3-6131978-3.html interview]
Before you took over, Seagate always had a reputation of the "school of hard knocks," the kind of place where people would get burned out or fired. What was it like when you first arrived, and how did you change it?
Watkins: It really changed when Steve (Luczo) took over as CEO. He took over as CEO, and I took over as COO, and we had both lived under the old culture, and we both really wanted to change it.
I will tell you about my first meeting at Seagate. I was on executive staff, and the meeting lasted about four or five hours, and I have never been around so many people who just screamed and yelled at each other. Everyone was, "F--- you, f--- you." The sales guy would say, "I need this" and the operations guy would say, "Well, f--- you. I'm not doing that." And the design guy would say. "F---, I hate doing that." It was six hours of "f--- you."
If you can create an environment where you respect each other, you trust each other and you get to this point where people think "I am not just going to let you down."
It was my first meeting coming in, and we had real issues to take care of, and I mean not one issue got resolved. It was like you didn't have to. You could just say "f--- you." There were seven of us, and everything was just screaming. I was stunned that I just had a meeting for six hours, and not one decision got agreed upon.
It sounds like an episode of "The Sopranos."
Watkins: And when it was over, they brought out the dog head. It was a head of a stuffed dog. They cut it off and sewed up the bottom. Then they all took a vote on who is the biggest ---hole in the meeting and they gave him the dog head award. That was the only agreement, and the person who got the dog head was sort of happy.
So Steve and I started talking about things offline a little bit, about communication and culture and values, and so when we got our opportunity, we just started changing things.
What do you think motivates people? There has been a big turnaround at Seagate.
Watkins: I will tell you what I think, and we strive to apply it. I kind of learned it in the Army. People don't die for their country, they don't die for their God, and they surely don't die for money. But they will die and put their life on the line for their platoon mates, because they don't want to let them down.
Now, you don't want people to die. Business and war aren't the same thing, and I'm not a big fan of that analogy. But if you can create an environment where you respect each other, you trust each other and you get to this point where people think "I am not just going to let you down." That is more powerful than money or anything else. So everything we do at Seagate is to create a teamwork culture. If employees learn we don't motivate by fear or firing, then you can create that environment. It's not just putting up posters.
I mean, you spend your whole life at work. You want to feel like you belong. I love corporate--corporations can do great things. These are places where people spend an amazing amount of time in their life. Why can't it be a positive thing? I think you focus on your customer, and focus on your people, and you focus on any community you're in--and if you do those, the stockholders do fine.
Stephen Covey's book, Living the 7 Habits (0684846640 or 0684857162), page 221 of the hardback first edition:
I've come to feel that being efficient with people in difficult situations is usually ineffective. It is so easy to be efficient, to make quick judgments or to act on other people's judgements without any involvement or effort to understand, and to judge everything in terms of it's impact upon the bottom line. Listening is like peeling an onion. There are many, many layers and a soft inner core. Once you get to the soft inner core your whole picture of the situation often profoundly changes, as do your actions. This new correct picture affects your attitude and usually creates in you a feeling of reverence for other people. You cease judging, and third-alternative solutions are more naturally produced. When two people are congruent and authentic, when they both say what they feel and what they feel is in harmony with what they are experiencing, creative energies are released and deep bonding almost always takes place. But when there are incongruencies, when people are not expressing what they are feeling, or they are not feeling what they are really experiencing, a seedbed of confusion, frustration, and low trust is sown.
Watts Humphrey's paper [http://www.sei.cmu.edu/news-at-sei/columns/watts_new/2003/1q03/watts-new-1q03.htm Some Programming PrinciplesRequirements] says this:
These programming principles are as follows:
- When we program, we transform a poorly understood problem into a precise set of instructions that can be executed by a computer.
- When we think we understand a programs requirements, we are invariably wrong.
- When we do not completely understand a problem, we must research it until we know that we understand it.
- Only when we truly understand a problem can we develop a superior product to address that problem.
What the users think they want will change as soon as they see what we develop.
Jeff Sutherland has termed this Humphrey's Requirements Uncertainty Principle - for a new software system, the requirements will not be completely known until after the users have used it.
See also http://www.loudthinking.com/arc/000538.html#comments
Alistair Cockburn's paper [http://alistair.cockburn.us/index.php/Foundations_for_Software_Engineering Foundations for Software Engineering], which has much wisdom about the nature of Engineering, also has this gem of a metaphor:
Some programming languages are very malleable, such as LISP, APL, Smalltalk, Python, and Ruby. Other languages are less malleable, such as Ada, C++, and the other strongly typed languages. Programmers sometimes compare working in the former languages to working with clay and working in the latter languages to working with marble. Wonderful sculptures can be made from either clay or marble, but the necessary skills and the approach differ significantly.
Gojko Adzic's [http://gojko.net/2006/10/11/how-to-develop-software-like-commanding-a-tank/ How to develop software like commanding a tank] talks about how to give direction such that those directed can continue to make progress in the face of the unexpected. The main points are to communicate not just the "what" and "how," but the "goals" and "anti-goals" (or problems to watch out for) as well. He reports the changes seen in the work of junior, senior, and mid-level programmers using this technique. He also warns of three challenges:
- "identifying and expressing true goals, not just repeating specifications or requirements"
- "a single project should not have too many goals," and
- how to "pass on the goals throughout the organisation without overloading people with information."
Fast Company [http://www.fastcompany.com/magazine/94/open_change-or-die.html Change or Die] (Issue 94, May 2005, Page 53) by Alan Deutschman:
Instead of trying to motivate them with the "fear of dying," Ornish (Dr. Dean Ornish, a professor of medicine at the University of California at San Francisco and founder of the Preventative Medicine Research Institute, in Sausalito, California) reframes the issue. He inspires a new vision of the "joy of living" -- convincing them they can feel better, not just live longer. That means enjoying the things that make daily life pleasurable, like making love or even taking long walks without the pain caused by their disease. "Joy is a more powerful motivator than fear," he says.
...
In Louis V. Gerstner Jr.'s successful turnaround of IBM in the 1990s, he learned the surprising importance of this kind of emotional persuasion. When he took over as CEO, Gerstner was fixated on what had worked for him throughout his career as a McKinsey & Co. consultant: coolheaded analysis and strategy. He thought he could revive the company through maneuvers such as selling assets and cutting costs. He quickly found that those tools weren't nearly enough. He needed to transform the entrenched corporate culture, which had become hidebound and overly bureaucratic. That meant changing the attitudes and behaviors of hundreds of thousands of employees. In his memoir, Gerstner writes that he realized he needed to make a powerful emotional appeal to them, to "shake them out of their depressed stupor, remind them of who they were -- you're IBM, damn it!" Rather than sitting in a corner office negotiating deals and analyzing spreadsheets, he needed to convey passion through thousands of hours of personal appearances. Gerstner, who's often brittle and imperious in private, nonetheless responded admirably to the challenge. He proved to be an engaging and emotional public speaker when he took his campaign to his huge workforce.
...
Radical Change Reframing alone isn't enough, of course. That's where Dr. Ornish's other astonishing insight comes in. Paradoxically, he found that radical, sweeping, comprehensive changes are often easier for people than small, incremental ones. For example, he says that people who make moderate changes in their diets get the worst of both worlds: They feel deprived and hungry because they aren't eating everything they want, but they aren't making big enough changes to quickly see an improvement in how they feel, or in measurements such as weight, blood pressure, and cholesterol. But the heart patients who went on Ornish's tough, radical program saw quick, dramatic results, reporting a 91% decrease in frequency of chest pain in the first month. "These rapid improvements are a powerful motivator," he says. "When people who have had so much chest pain that they can't work, or make love, or even walk across the street without intense suffering find that they are able to do all of those things without pain in only a few weeks, then they often say, 'These are choices worth making.' "
[http://www.easycomp.org/cgi-bin/OrgPatterns?OrganizationalPatternLanguages Organizational Pattern Languages]
James Shore, in [http://jamesshore.com/Change-Diary/Intermission.html Change Diary]:
Although I made plenty of mistakes--I should have been more inclusive, for one--those mistakes didn't hurt me in the long run. The one mistake that came back to haunt me had nothing to do the techniques I used to inspire change.
No, my biggest mistake was different. I was too sure of my solution. Ultimately, an agile approach was the wrong approach for this project.
The right approach was not to do the project at all: it couldn't be accomplished in the time available.
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].