Approximity blog home
855 to 864 of 910 articles

Where is the snow?   25 Sep 04
[print link all ]

Summertime .. so all we do is to ski-roller. High time for the snow to come back and cool it down a bit. I found that pic a long time ago on I have forgotten what website.

Case stories   25 Sep 04
[print link all ]
Been skimming the XP-ML this morning.

About the $200M Oracle-Ford Desaster: the management did not give them enough power to go fully agile

Chet Hendrickson:

 It was a very frustrating situation.  The team asked Don and me
 to help with preventing the Oracle consutants from making changes
 directly to the production system.  This was about $150 million into the project.

 We tried to sell them on a more agile approach (as you might imagine), but by
 this time they were pretty far gone.

 It was unfortunante that we were not operating at a level in the organization
 that would have allowed us to get the plug pulled sooner.


Georg Tuparev has a nice case story, too: speak out if you are put on a death march.

 Few years ago I was called to lead a huge team stuck in one and half
 year design phase. The team was supposed to build a control software
 for a network of telecom satellites. Cannot disclosed names and
 resources, but one could imagine ...

 Three days in the project I had a phone conference with the CxO's of
 both companies involved. Told them that the way it is going no
 satellite will ever fly and that I know a better way. After getting
 green line, the design document was burned with a small celebration at
 a BBQ, and 85% of the initial team members were sent to an indefinitely
 long vacation. With the rest (15%) of the team we had the first
 functioning version 2 months ahead of the schedule and 50% lower then
 expected expenses.

 So the lessons:
 - it is never late to change direction of a project in order to save it.
 - I do not agree with Kent that this is a sad story. If you are a good
 programmer put on a death march project you should speak out! If no one
 listens - walk away. There is just one very precious life in front of
 us - do not waste it! And if these folks wasted 2 years of their lives,
 well, it is their business ... but they should not expect my

 BTW, Philip is right - the project I was telling about had a 9 months x
 40 people "Big Requirements Up Front"!!! Then the design started...

 Just my 0.02

 Georg Tuparev

What's the Second Directive?   25 Sep 04
[print link all ]
(Source: Ron Jeffries, aka Mr. XP) I’m been struggling for years with notions like having empathy with our mistakes, Kerth’s Prime Directive, and the like. Springing from a couple of notes on the extremeprogramming group, and a blog entry from Dale Emery, here’s my latest rant.

XPlorations: The Humble Yo   25 Sep 04
[print link all ]
(Source: Bill Wake) "The Humble Yo" The humble "Yo!" is a simple convention for getting help. link Nice explanation of why not asking for help can actually hurt the team.

fit   25 Sep 04
[print link all ]
Ward Cunningham has released an acceptance testing tool called fit fit is about tests that people can read.

The Cook’s Tour offers an excellent howto to get yourself and your customers into the test-writing mode.

An intro article by Bill Wake.

Communication is the Transfer of Emotion   25 Sep 04
[print link all ]
Seth Godin has put together a nice pdf about how todo decent powerpoint slides. By the way, his new book "Free Prize" is out, too.

I always enjoy reading his weblog.

Software for your head by Jim and Michelle McCarthy   25 Sep 04
[print link all ]
What Ron Jeffries says: if you read this book, really study and consider it, you will think thoughts you haven’t thought before, and you will likely learn something about yourself, your colleagues, and your projects. I read a lot of books and recommend a lot of books. This one is special. Do yourself a favor: buy it, read it, and give it deep consideration.

Working on a book: Driving Software Projects with Examples   25 Sep 04
[print link all ]
Brian Marick posted this to agile-testing.

I’ve started work on a book, tentatively titled _Driving Projects with Examples: a Handbook for Agile Teams_. All that’s done to date is the Preface.

Two years ago, this would have been about driving projects with tests, but I think the role of examples in projects is larger than that. Also, examples fit more obviously into the whole "individuals and interactions over processes and tools" thing. Examples are something people use to explain themselves to each other. Conversations and learning are more obviously part of the picture.

Because I’m so hot on examples, I’ve put the draft book on a new site, Here’s the book: <>

(And, rather than "QA", "tester", or even "ECaBian", "exampler" might be a good name for those people on an Agile project that exhibit certain traits more strongly than other team members.)

Some of you practice the style of development I’m documenting - or variants of it. If you do, I want to talk to you, be it on the phone, or via emai, or in person. (I am budgeting travel money to visit worthy sites.) I’m serious about the "handbook" in the title: I want to fill it with tricks, tips, techniques, and stories. The more people I gather them from, the better the book will be.

Advantages of Extreme Programming   25 Sep 04
[print link all ]
(Source: Kevin Smith post to After a couple years of pitching XP, it became very clear to me that XP has different key advantages for different audiences. You’ll have to decide whether to pitch to a single audience, or try to cover several.

For developers, XP allows you to focus on coding and avoid needless paperwork and meetings. It provides a more social atmosphere, more opportunities to learn new skills, and a chance to go home at a decent hour each night. It gives you very frequent feelings of achievement, and generally allows you to produce code that you feel good about.

For the Customer, XP creates working software faster, and that software tends to have very few defects. It allows you to change your mind whenever you need to, with minimal cost and almost no complaining from the developers. It produces reliable estimates so you can coordinate your schedule easier.

For management, XP delivers working software for less money, and the software is more likely to do what the end users actually want. It cuts risk in a couple ways: 1) It allows you to "pull the plug" on development at almost any time, and still have highly valuable code, and probably even a valuable working (if incomplete) application. 2) It reduces your dependence on individual superstars, and at the same time can improve employee satisfaction and retention.

The biggest disadvantage: It’s hard. It’s difficult to get many developers to accept the practices, and it takes a lot of discipline to keep doing them all. Customers may not like the idea of having to be so involved. Management may expect fixed-cost, fixed-scope estimates, which XP teams often refuse to create (because they are usually incorrect with any methodology).

Also, certain people may feel their jobs are being threatened, particularly architects, testers, and project managers. "Cowboy" coding "superstars" may dislike the reduction in fame, attention, and adreneline from "saving" the project at the last minute.

When Should We Test?   25 Sep 04
[print link all ]
Kent Beck, one of the people that invented extreme programming (XP) offers an economic model. The financial risk management community and the software development community can learn a lot from each other. Think of this article as: When should you put Risk Management into place?

Amongst other things this article tells you when best to have children :-).


powered by RubLog
855 to 864 of 910 articles Syndicate: full/short