gmane.comp.programming.extreme-programming

Re: What other professions pair?

George Dinwiddie — 2008-12-02T02:06:08

Yes, it may be that pairing isn't, strictly speaking, the best way of working. It's pretty limited, and doesn't reach the richness displayed by human society. It's just /so/ much better than working alone. I'm sure we've barely scratched the surface on better ways to collaborate in software development. - George

Re: Re: Need advice preparing the waters for XP

Mike Coon — 2008-12-02T01:40:38

So have you talked to this PM about the pairing experience you had together? Have you acknowledged your shortcomings to him in a way that might allow him to trust you and help in your efforts? Why was original XP team's breakup acrimonious? Have the factors that contributed to that been addressed? Is pairing the thing you need most? Does the team understand refactoring? Do you have unit tests? Functional tests? Automated regression tests? A prioritized backlog? If technical debt is the problem you're trying to solve is pairing really the highest priority practice to start with? Mike On Mon, Dec 1, 2008 at 7:20 PM, banshee858 hotmail.com> wrote:

Re: Testing non-deterministic methods

Rodolfo Carvalho — 2008-12-02T01:28:33

Thanks for your words Kent. I quite managed to do what I wanted, though the tests may be kinda lacking. The tests: class TSPTests(unittest.TestCase): def testTSPforOneVertexGraph(self): gg = GeometricGraph(StringIO('1\n0 0')) self.assertEqual(gg.tsp(), ([1], 0)) def testTSPforTwoVertexGraph(self): gg = GeometricGraph(StringIO('2\n0 0\n1 1')) path, cost = gg.tsp() self.assert_(path in ([1, 2, 1], [2, 1, 2])) self.assertAlmostEqual(cost, 2.8284, 4) def testTSPforFourVertexGraph(self): gg = GeometricGraph(StringIO('4\n1 1\n2 2\n1 0\n2 1')) path, cost = gg.tsp() self.assert_(len(path) == 5) self.assertEqual(path[0], path[-1]) self.assertAlmostEqual(cost, 4.8284, 4) def testTSPforHorizontalLineGraph(self): n = 100 gg = GeometricGraph(StringIO( '%d\n%s' % (n, ''.join('%d 0\n' % x for x in range(n))))) path, cost = gg.tsp() self.assert_(len(path) == n+1) self.assertEqual(path[0], path[-1]) self.assertAlmostEqual(cost, 2*(n-1), 4) (suggestions and comments are welcome) The actual implementation of *GeometricGraph.tsp* takes the best path out of a mix of 1000 repetitions of a random shuffle of path and running a greedy algorithm from every vertex looking for the one closest to it. None of those two approaches can be said to be driven from the tests. The tests only assure the very simple cases, and one case that a straight line should be optimum. Cheers, Rodolfo Carvalho On Mon, Dec 1, 2008 at 13:07, kentb earthlink.net> wrote: [Non-text portions of this message have been removed] ------------------------------------ To Post a message, send it to: extremeprogramming< at >eGroups.com To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe< at >eGroups.com ad-free courtesy of objectmentor.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/extremeprogramming/join (Yahoo! ID required) <*> To change settings via email: mailto:extremeprogramming-digest< at >yahoogroups.com mailto:extremeprogramming-fullfeatured< at >yahoogroups.com <*> To unsubscribe from this group, send an email to: extremeprogramming-unsubscribe< at >yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Re: Need advice preparing the waters for XP

banshee858 — 2008-12-02T01:20:52

A good start would be to think about what sort of needs your organization has and identify the (XP) requirements which meet those needs. I have a structured set of thinking exercises I use when I coach teams on how to transition to Agile processes which might be helpful here. If you are in San Diego this week, I will be running a workshop on how to do this at the local XPSD (www.xpsd.org) meeting. Carlton www.carltonnettleton.com\blog ------------------------------------ To Post a message, send it to: extremeprogramming< at >eGroups.com To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe< at >eGroups.com ad-free courtesy of objectmentor.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/extremeprogramming/join (Yahoo! ID required) <*> To change settings via email: mailto:extremeprogramming-digest< at >yahoogroups.com mailto:extremeprogramming-fullfeatured< at >yahoogroups.com <*> To unsubscribe from this group, send an email to: extremeprogramming-unsubscribe< at >yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Re: Need advice preparing the waters for XP

Craig Davidson — 2008-12-01T23:23:06

Hi Olof, I don't use the word "measure", that suggests a degree of precision that I don't get. You can observe it's impact (subjectively is fine - If it has negligible impact is it really a technical debt?). And you can guesstimate what it would take to pay it off. To track debt, I like to write the main offenders as notes or index cards put them on a Technical Debit wall or column. This makes it visible to the team and stakeholders - I find without that visibility it is easily ignored - until something crunches. As a team we work out how (or whether to) address that debt, eventually adding them to the iteration plan with stories. Obviously, there is nothing wrong with carrying debt if there are more pressing concerns - you just need remain aware you are carrying it. I would write technical debt out as something like this: Fat controllers. Our Controller classes are riddled with duplication. Some action methods are 80 lines long! It takes (me anyway) at least half an hour to work out what's actually going on in these methods. Because of all the mocking our controller developer tests are becoming unreadable. We currently have over 30 actions across 8 controllers. This is only going to get worse as development progresses. What needs done: We need break these action methods up and move much of the logic into our model classes (which at the moment are just an anemic data model). This would simplify our controller tests, and give us nice simple model tests. I don't know how long this would take, I'm thinking maybe an hour per action? Even if we do this gradually, we should find the system easier to understand and easier to test. 2008/12/1 Olof Bjarnason gmail.com> [Non-text portions of this message have been removed] ------------------------------------ To Post a message, send it to: extremeprogramming< at >eGroups.com To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe< at >eGroups.com ad-free courtesy of objectmentor.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/extremeprogramming/join (Yahoo! ID required) <*> To change settings via email: mailto:extremeprogramming-digest< at >yahoogroups.com mailto:extremeprogramming-fullfeatured< at >yahoogroups.com <*> To unsubscribe from this group, send an email to: extremeprogramming-unsubscribe< at >yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Re: Testing non-deterministic methods - design by testing or refactoring?

Adam Sroka — 2008-12-01T21:05:14

There are times when refactoring can drive you toward a particular design. Joshua Kerievsky wrote a whole book on it. On the other hand, we shouldn't ignore YAGNI. If we don't ignore YAGNI, then there isn't necessarily anything compelling us towards a particular design. i.e. if my current design is clear and absent of duplication then I am done. This is what I was getting at in my earlier post. It is difficult for any non-trivial set of tests to guarantee that a particular design will emerge. On the other hand, I think it is acceptable to mock your way around a tricky algorithm and then say, "I know that I need a foo-munch here." If the "foo-munch" algorithm is able to produce the "right" output for a given input then so be it. This isn't strictly TDD, but we do this all the time when we use high level languages. For example, when I sort a collection in Java I know that the standard library is using a modified quicksort, but I don't test that part. I simply test that the collection I get back matches my expectations. You have to be careful here, though. These situations should be the exception rather than the rule. Use the simplest thing that could possibly work until some requirement drives you towards this. e.g. if the naive implementation fails to hit some hard performance numbers then it might be time to go down this path, but not before. And, you still need to have a failing test (e.g. based on the performance numbers.) On Mon, Dec 1, 2008 at 11:06 AM, Jeff Grigg charter.net> wrote: ------------------------------------ To Post a message, send it to: extremeprogramming< at >eGroups.com To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe< at >eGroups.com ad-free courtesy of objectmentor.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/extremeprogramming/join (Yahoo! ID required) <*> To change settings via email: mailto:extremeprogramming-digest< at >yahoogroups.com mailto:extremeprogramming-fullfeatured< at >yahoogroups.com <*> To unsubscribe from this group, send an email to: extremeprogramming-unsubscribe< at >yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Re: Testing non-deterministic methods - design by testing or refactoring?

Jeff Grigg — 2008-12-01T19:06:46

True. Also, let's not get stuck on the idea that tests drive design: As I see it, tests drive functionality -- forcing one to implement new features in the code. Refactoring drives improvements to design. One can have really messy code that passes all the tests. But I see that addressing code smells, with refactoring, is one of the best ways to improve the design of the code. Certainly some design improvements are often driven by testing issues

Re: Testing non-deterministic methods - accepting alternative valid results

Jeff Grigg — 2008-12-01T19:00:29

(I'm a fan of the "alternate algorithm" idea -- as I posted on Gregorian-Julian conversion functions. And also see my comment below.) AND... * Assert that the result is /one of/ the acceptable answers. IE: You CAN put "or" conditions into assertions. For the case below... assertTrue("ABD".equals(path) || "ACD".equals(path)); When two possible answers are equally valid. And all other answers are invalid... Then assert that the answer is one of the valid ones. --- "Rodolfo Carvalho" ...> wrote: ------------------------------------ To Post a message, send it to: extremeprogramming< at >eGroups.com To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe< at >eGroups.com ad-free courtesy of objectmentor.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/extremeprogramming/join (Yahoo! ID required) <*> To change settings via email: mailto:extremeprogramming-digest< at >yahoogroups.com mailto:extremeprogramming-fullfeatured< at >yahoogroups.com <*> To unsubscribe from this group, send an email to: extremeprogramming-unsubscribe< at >yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

RE: Can one become "Too agile"?

kentb — 2008-12-01T15:07:29

Lior, Yes and no. From a theoretical point of view, if you control a system more frequently than its inputs change you can get oscillations--think of someone who raises the temperature on a thermostat once a minute even though the room takes ten minutes to heat up. Then the room is too hot and they open a window, then two, then three, then... I've seen teams do this--mid-week plan changes even though no new information has arrived. When I'm doing this the first thing I do is take a moment to laugh at myself, then I slow the rate of inputs or raise the frequency of feedback until they match, then resume shrinking them together. If working with an external customer, I might say, "These midweek changes seem to be doing more harm than good. They disrupt development and damage morale because people can see that the results of the change aren't used for another month. We want to be responsive. Can we add a To Be Estimated place on the board that we will make sure is clear at the end of every day?" Now, is the team "too agile", as in "would they produce more if they were less responsive"? Not the way I look at it. The problem is not caused by the team's responsiveness, but by the mismatch between the planning cycle and the feedback cycle. Getting to a productive rhythm is better done by taking a step back and looking at the whole system rather than gruffly saying, "No more midweek changes. Period." Regards, Kent Beck Three Rivers Institute _____ From: extremeprogramming< at >yahoogroups.com [mailto:extremeprogramming< at >yahoogroups.com] On Behalf Of Lior Friedman Sent: Wednesday, November 26, 2008 3:31 PM To: extremeprogramming< at >yahoogroups.com Subject: [XP] Can one become "Too agile"? Hi all, I know its vague, but I would like to hear what people think. Can a company become to agile for its own good? If you think the answer is yes, do you have any specific examples? Lior Friedman Email: lfriedmal< at >gmail. com typemock. com> Blog - http://imistaken. blogspot.com blogspot.com/> [Non-text portions of this message have been removed] [Non-text portions of this message have been removed] ------------------------------------ To Post a message, send it to: extremeprogramming< at >eGroups.com To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe< at >eGroups.com ad-free courtesy of objectmentor.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/extremeprogramming/join (Yahoo! ID required) <*> To change settings via email: mailto:extremeprogramming-digest< at >yahoogroups.com mailto:extremeprogramming-fullfeatured< at >yahoogroups.com <*> To unsubscribe from this group, send an email to: extremeprogramming-unsubscribe< at >yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

RE: Testing non-deterministic methods

kentb — 2008-12-01T15:07:29

Victor, I read Rodolfo's message differently. The question I heard was, "How do you write assertions when multiple answers are acceptable?" It is exacerbated in his case because calculating by hand for a realistic-sized problem is difficult. The techniques I've used in cases like this (some of which were mentioned already) are: * Work out some small problems by hand--"Given this simplified map, this heuristic should produce Chicago-London-Katmandu as the shortest path". These tests can verify that a heuristic behaves as expected. However, they tend to produce false failures because in such algorithmic development you often tweak heuristics. * Make vaguer assertions about large problems--"Given this realistic map, the algorithm should produce a path of less than 10,000 km". I think this was what Rodolfo was proposing but he was concerned that they wouldn't drive development in the same way ordinary TDD tests do. They also tend to run slowly (which I suppose is part of their lack of drive). * Run an exhaustive algorithm in parallel with the optimized algorithm on a small data set and compare the results, either for an exact match or a ratio. * Compare the output of versions of the optimized algorithm to make sure, for example, that the answers never get worse. All in all, heuristic algorithm development is not the sweet spot for TDD, although tests can still support such development. Cheers, Kent _____ From: extremeprogramming< at >yahoogroups.com [mailto:extremeprogramming< at >yahoogroups.com] On Behalf Of Victor Sent: Thursday, November 27, 2008 6:58 AM To: extremeprogramming< at >yahoogroups.com Subject: Re: [XP] Testing non-deterministic methods Hi Rodolfo, I have the impression you are confusing two different kinds of tests, TDD and acceptance. The purpose of TDD is to validate that the mechanics of the code are working, while the purpose of acceptance is to additionally verify that the outputs are meaningful within the context of the application. The computerized random calculations have a way of making the process deterministic. You can use this for your TDD. For the acceptance tests, you need to know what the range of expected values is; then run the test a thousand times (or a million, or whatever large number) and compare the results against the range. This is something very easy to do in Smalltalk (use the properties of bags), and it could take no more than a few seconds to run, depending on your system and number of comparisons. I don't know about other languages. Victor ====================== ----- Original Message ----- From: "Rodolfo Carvalho" gmail. com> To: yahoogroups.com> Sent: Thursday, November 27, 2008 9:02 AM Subject: Re: [XP] Testing non-deterministic methods eGroups.com unsubscribe< at >eGroups.com [Non-text portions of this message have been removed] ------------------------------------ To Post a message, send it to: extremeprogramming< at >eGroups.com To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe< at >eGroups.com ad-free courtesy of objectmentor.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/extremeprogramming/join (Yahoo! ID required) <*> To change settings via email: mailto:extremeprogramming-digest< at >yahoogroups.com mailto:extremeprogramming-fullfeatured< at >yahoogroups.com <*> To unsubscribe from this group, send an email to: extremeprogramming-unsubscribe< at >yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Re: Re: Need advice preparing the waters for XP

Steven Gordon — 2008-12-01T09:09:22

Pieter, Calm just sounds like going back to silently expecting things to get better until you get too frustrated again. Even better would be attempting to: - help the people who are together with you in this "same boat" to think of themselves as a single team with a common purpose, - help this team form a consensus on what is good, what is bad and how to make things better (by listening, constructively engaging, and sometimes making suggestions), - stay as balanced and consistent as possible (i.e., - proactively engage with people and lead by example every day, as opposed to alternating between passively expecting people to have the same views as you and aggressively trying to impose your own views) . Not that I am always successful at doing this myself :) Steve ------------------------------------ To Post a message, send it to: extremeprogramming< at >eGroups.com To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe< at >eGroups.com ad-free courtesy of objectmentor.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/extremeprogramming/join (Yahoo! ID required) <*> To change settings via email: mailto:extremeprogramming-digest< at >yahoogroups.com mailto:extremeprogramming-fullfeatured< at >yahoogroups.com <*> To unsubscribe from this group, send an email to: extremeprogramming-unsubscribe< at >yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Re: Need advice preparing the waters for XP

Olof Bjarnason — 2008-12-01T06:50:34

2008/11/30 Craig Davidson gmail.com>: Interesting - How do you measure technical debt? ------------------------------------ To Post a message, send it to: extremeprogramming< at >eGroups.com To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe< at >eGroups.com ad-free courtesy of objectmentor.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/extremeprogramming/join (Yahoo! ID required) <*> To change settings via email: mailto:extremeprogramming-digest< at >yahoogroups.com mailto:extremeprogramming-fullfeatured< at >yahoogroups.com <*> To unsubscribe from this group, send an email to: extremeprogramming-unsubscribe< at >yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Re: What other professions pair?

Pieter Nagel — 2008-12-01T06:24:52

I thought they did. I'll ask around, because if surgeons actually mostly keep one hand on the patient, a surgical team would be a radical example of a kind of pairing. I'm interested in examples of how people actually work in pairs/groups, but where an outside observer could reasonably think that there's a "bottleneck" which makes the extra participants unproductive. Then I'm interested in comparing the dynamics in the other situations to the dynamics of pair programming - why are THEIR bottlenecks only apparent, not real, and what can we learn from that? Sorry. It's a communication-glitch I have. I often begin conversations on a concrete level, then get interested in the abstract, jump to the meta level, and get irritated if the participants did not make the leap with me. In this case, the concreate specific conversations I was planning to have triggered a train of thought that has since long gone "meta". Mea culpa. I realised I was doing that. In this case I felt like a pilot on an imaginary "Extreme Piloting" mailing list, who asked about what other professions co-pilot. And then gets frustrated with all the advice about how piloting isn't really just about moving a stick. Which he knows, but he's actually interested in learning that "some programmers do something similar, they call it pairing". I get the impression that there's no ONE single example of something else quite like pairing out there. Instead, it seems the sheer number of situations where people engage in teamwork for varying trade-offs is what's relevant. ------------------------------------ To Post a message, send it to: extremeprogramming< at >eGroups.com To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe< at >eGroups.com ad-free courtesy of objectmentor.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/extremeprogramming/join (Yahoo! ID required) <*> To change settings via email: mailto:extremeprogramming-digest< at >yahoogroups.com mailto:extremeprogramming-fullfeatured< at >yahoogroups.com <*> To unsubscribe from this group, send an email to: extremeprogramming-unsubscribe< at >yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Re: What other professions pair?

Jeff Grigg — 2008-12-01T02:51:01

Cavers always (are supposed to ;-) go in groups of /at least/ four: If one gets injured, one stays behind (one pair) and the other two go for help: You don't /ever/ want to cave alone -- not even when going out to arrange an emergency rescue. (And all this is /in addition to/ notifying someone before going in as to when you intend to return, and being sure to contact them when you do return!) ------------------------------------ To Post a message, send it to: extremeprogramming< at >eGroups.com To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe< at >eGroups.com ad-free courtesy of objectmentor.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/extremeprogramming/join (Yahoo! ID required) <*> To change settings via email: mailto:extremeprogramming-digest< at >yahoogroups.com mailto:extremeprogramming-fullfeatured< at >yahoogroups.com <*> To unsubscribe from this group, send an email to: extremeprogramming-unsubscribe< at >yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Re: What other professions pair?

George Dinwiddie — 2008-12-01T02:37:15

Rock climbers--one climbing and one belaying.

Re: What other professions pair?

George Dinwiddie — 2008-12-01T02:31:11

Do doctors tend to work with multiple hands on at the same time? You might ask some doctors about that. Or are you just looking for examples of the way people /think/ others work? You know, the way people think that programmers work by typing. OK. Things like > But my problem is one would first have to lead management over that > bridge *before* the analogy make sense that "pair programming is like > advertisers brainstorming around a table". make it /seem/ like you're planning a conversation with other people. Oh, and the frequent rejection of suggestions makes it /seem/ like something other than curiosity--at least to me. You want examples of pairing, but some aren't fit for the purpose you have in mind. - George P.S. Perhaps "conversationalists" could be added to the list.

Re: Your chance to influence how agile is defined in an upcoming IEEE-standard

Gary Brown — 2008-12-01T02:04:41

Erik, I don't mean to shoot the messenger, but please don your kevlar and duck! How many of the following people are invited? Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas Do you or the folks intending to define Agile in an upcoming IEEE standard understand that there is no Agile software development method? Agile is an umbrella concept for the defined software development methods, that adhere to the Agile Manifesto and the Agile Principles. The actual defined Agile software development methods are already well documented by Lean Software Development, Scrum, and Extreme Programming, among others. Who is convinced by discussing how much documentation, what the maifiesto really means, what Agile is good for, what good Agile does? People adopt Agile one by one. Those with safety-critical requirements would be well served by adopting Agile. A thoughtful review of the defined Agile software development methods may suffice. Hard-nosed Waterfall-ish government bodies deserve and sustain their fate. A thoughtful review of the defined Agile software development methods may release them from their bondage. Auditors are Customers of the software development process. If they have a requirement, write the story. If those who would be influenced by an official IEEE version of Agile, need a new definition, what is to be different from what the original authors defined? What is the weather like in Finnish Lapland this time of year?!? GB. First, do no harm ... The Hippocratic Oath. ----- Original Message ----- From: "Erik Lundh" compelcon.se> To: yahoogroups.com> Sent: Sunday, November 30, 2008 6:01 PM Subject: [XP] Your chance to influence how agile is defined in an upcoming IEEE-standard ------------------------------------ To Post a message, send it to: extremeprogramming< at >eGroups.com To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe< at >eGroups.com ad-free courtesy of objectmentor.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/extremeprogramming/join (Yahoo! ID required) <*> To change settings via email: mailto:extremeprogramming-digest< at >yahoogroups.com mailto:extremeprogramming-fullfeatured< at >yahoogroups.com <*> To unsubscribe from this group, send an email to: extremeprogramming-unsubscribe< at >yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Re: What other professions pair?

Chris Wheeler — 2008-12-01T01:34:57

Porn stars? Chris. [Non-text portions of this message have been removed] ------------------------------------ To Post a message, send it to: extremeprogramming< at >eGroups.com To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe< at >eGroups.com ad-free courtesy of objectmentor.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/extremeprogramming/join (Yahoo! ID required) <*> To change settings via email: mailto:extremeprogramming-digest< at >yahoogroups.com mailto:extremeprogramming-fullfeatured< at >yahoogroups.com <*> To unsubscribe from this group, send an email to: extremeprogramming-unsubscribe< at >yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Re: Your chance to influence how agile is defined in an upcoming IEEE-standard

Phlip — 2008-12-01T00:46:21

Sorry, but I can't help thinking of the "Salon des Refusés", out in back of the (official) Paris Salon of 1863. All the great artists that we remember from that time, such as Édouard Manet and James McNeill Whistler, were from the "Salon of Rejects" - _not_ the official Paris Salon...

Your chance to influence how agile is defined in an upcoming IEEE-standard

Erik Lundh — 2008-12-01T00:01:43

I am going to the finnish Lapland (right where Santa Claues lives) on Sunday November 30 for 72 hours of intense discussions about what Agile is. Participants are invited internationally from industry and academia However, I feel that the participants could use additional input. Earlier work on this standard has spent some time on interpretations of things like "How much documentation" and even to some degree what the manifesto really means. I feel that we need to define Agile by what it is useful for. A definition of what good Agile does might last longer than a detailed description of current practices in the evolving art of Agile. Who wants a standard for what Agile is? Well, people who have to comply with e g safety-critical requirements from hard-nosed government bodies will appreciate support from an actual rationale for going from waterfall(ish) development to Agile. And just being convinced that agile helps does not impress on auditors. A standard that defines agile in a way that makes sense will help these folks tremendously. Please use the survey to express your view on what Agile is useful for and what makes you think that someone is Agile. Email with additional comments is of course also welcome. The short "What makes you agile?" survey is at: http://www.polldaddy.com/s/6DF01D606D905EBB/ Feel free to forward this link to people whose opinion you value. Your answers is more useful if you give them before or on Tuesday December 2 /Erik Lundh ------------------------------------ To Post a message, send it to: extremeprogramming< at >eGroups.com To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe< at >eGroups.com ad-free courtesy of objectmentor.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/extremeprogramming/join (Yahoo! ID required) <*> To change settings via email: mailto:extremeprogramming-digest< at >yahoogroups.com mailto:extremeprogramming-fullfeatured< at >yahoogroups.com <*> To unsubscribe from this group, send an email to: extremeprogramming-unsubscribe< at >yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Re: Need advice preparing the waters for XP

Craig Davidson — 2008-11-30T22:52:53

Hi Pieter, You wrote: I wish to (re)introduce XP to our team, because our system is suffering from years of technical debt. Are you currently tracking technical debt? Is it and it's impact visible enough to motivate the team to re-evaluate what they are doing? Is there a way you make your technical debt, it's impact, and what it would take to "pay it off" more visible to the project team and the stakeholders? Cheers, Craig 2008/11/28 Pieter Nagel nagel.co.za> [Non-text portions of this message have been removed] ------------------------------------ To Post a message, send it to: extremeprogramming< at >eGroups.com To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe< at >eGroups.com ad-free courtesy of objectmentor.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/extremeprogramming/join (Yahoo! ID required) <*> To change settings via email: mailto:extremeprogramming-digest< at >yahoogroups.com mailto:extremeprogramming-fullfeatured< at >yahoogroups.com <*> To unsubscribe from this group, send an email to: extremeprogramming-unsubscribe< at >yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/