About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2003.Jul.03 Thu
A quote from Seth Godin's Purple Cow:
If you're remarkable, it's likely that some people won't like you. [...] Criticism comes to those who stand out.
Where did you learn to fail? If you're like most Americans, you learned in first grade. That's when you started figuring out that the safe thing to do was to fit in. The safe thing to do was to color inside the lines, don't ask too many questions in class [....]
A quote from Eliyahu M. Goldratt's Theory of Constraints:
We assume that the openness of these functions [marketing, distribution, etc.] will be enhanced by the positive results achieved in the other functions [production and material...]
What we found out was this is certainly not the case. [...] The emotional resistance, which already exists, prevents almost any meaningful dialog. The only way to open the Throughput channel in these case was through personnel changes.
The lesson today is loud and clear. Before any function can go on an ego trip, demonstrating and waving results (and by that digging its own grave) -- before any function can start individual improvements, all functions should decide together on a common way.
Extreme Programming is one of those "Purple Cows" that Seth Godin talks about -- it is "remarkable". Its value comes from not fitting in with what the majority of programmers do. It does more testing and more design, and requires more discipline. The documented bug-rate reductions of projects that converted to XP and their improved time-to-market are actually not believed by many, if not most managers, even when the project is within their own company.
"Selling" XP also has to recognize the manager's fears of not fitting in. Heed Weinberg's Laws of Consulting: "In spite of what your client may tell you, there is always a problem. No matter how it looks at first, it is always a people problem.... Never promise more than a ten percent improvement. (If it were possible to achieve more than a ten percent improvement, there must have been a problem, but there isn't a problem, so...)"
I'm looking to the "project community" practices of IXP to help keep an organization from rejecting XP. Retrospectives and Readiness Assessments that include more than just the programmers. Management Tests. The value of Learning.