Comments on: eXtreme Projects

By: Wie man Geeks NICHT führen sollte « Zahlenpeter’s Weblog

Wie man Geeks NICHT führen sollte « Zahlenpeter’s Weblog — Thu, 11 Jun 2009 21:31:57 +0000

[...] “eXtreme Projects” – Wie kann Extremprogrammierung bei Nicht-IT-Projekten angewendet werden? [...]

By: The coolest way ever to recruit developers: Extreme Interviewing

The coolest way ever to recruit developers: Extreme Interviewing — Wed, 13 Sep 2006 13:26:31 +0000

[...] Also, Menlo Innovations base their development work on the IT project model called eXtreme Programming (or XP) which is radically different from more traditional development methods and want to use the same principles when recruiting. Here’s a previous post about XP and how it can be used in non-software projects. [...]

By: Make your startup happy

Make your startup happy — Thu, 17 Aug 2006 14:10:52 +0000

[...] eXtreme Projects [...]

By: Let’s lose the job descriptions

Let’s lose the job descriptions — Wed, 16 Aug 2006 12:34:29 +0000

[...] eXtreme Projects [...]

By: Alexander

Alexander — Thu, 03 Aug 2006 09:27:33 +0000

That’s a great example, aetheogamous. I’ll try it for my next home project!

By: aetheogamous

aetheogamous — Wed, 02 Aug 2006 22:15:25 +0000

After years of failed house projects (for example, clean out the garage) I’ve sucessfully been employing aspects of XP techniques. In particular
- Frequent Small Releases
- Iteration Planning
- Simplicity
- Creating Spike Solutions

Kind of shocked my wife that I actually managed to complete a project…

By: Drack

Drack — Thu, 25 May 2006 21:09:44 +0000

Interesting ideas, but I’ve seen one drawback to XP.

I’ve watched the developers of a certain MMORPG seem to follow XP techniques. They had frequent small releases, iteration planning, and thanks to the games forums, the customer was always available day or night to comment on proposed changes.

The problem arises when management of XP is weak. There was constant development on the most important part of the game, as it was perceived by management. Developers were talking to the customer; management was listening to marketing.

I’ve seen XP techniques work, but unless management is there to keep everything in perspective and on track, it is doomed to failure.

By: Dave MacLeod

Dave MacLeod — Thu, 25 May 2006 19:17:08 +0000

Yes, its from “The Dilbert Principle”. A serious chapter tucked away amongst the serious comic strips!

Dave Mac

By: Alexander

Alexander — Thu, 25 May 2006 18:57:11 +0000

Excellent, great tip. I’ll update the post based on that. Thanks!

I’ve never heard of the OA5 stuff, but after some brief googling I can say that it sounds very sensible. Is it from one of his books?

By: Dave MacLeod

Dave MacLeod — Thu, 25 May 2006 18:21:47 +0000

Alexander,

The test-first approach is not always appropriate but, thinking about how you’re going to QA a deliverable before you start creating it can often make life easier. A recent case in point has been when putting together a training syllabus and schedule. Before starting to write it a couple of team members and a customer spent 30-40 mins writing down all of the criteria it needed to satisfy to be considered worthy. It really helped us focus on what the customer needed.

BTW: Have you read the Scott “Dilbert” Adams’ stuff about “Out At Five (OA5)”? Its the best explanation I’ve ever come across about why overtime doesn’t work.

Regards,

Dave Mac