<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_02_09_0551202</id>
	<title>Game Development In a Post-Agile World</title>
	<author>Soulskill</author>
	<datestamp>1265740080000</datestamp>
	<htmltext>An anonymous reader writes <i>"Many games developers have been pursuing agile development, and we are now beginning to <a href="http://gwaredd.blogspot.com/2010/02/game-development-in-post-agile-world.html">witness the debris and chaos it has caused</a>. While there have been some successes, there have also been many casualties. As the industry at large is moving away from the phantasmagoria of Agile, <a href="http://www.mobygames.com/developer/sheet/view/developerId,118103/">Gwaredd Mountain</a>, Technical Director at <a href="http://www.climaxgroup.com/">Climax Studios</a>, looks at Post-Agile and what this might mean for the games industry."</i></htmltext>
<tokenext>An anonymous reader writes " Many games developers have been pursuing agile development , and we are now beginning to witness the debris and chaos it has caused .
While there have been some successes , there have also been many casualties .
As the industry at large is moving away from the phantasmagoria of Agile , Gwaredd Mountain , Technical Director at Climax Studios , looks at Post-Agile and what this might mean for the games industry .
"</tokentext>
<sentencetext>An anonymous reader writes "Many games developers have been pursuing agile development, and we are now beginning to witness the debris and chaos it has caused.
While there have been some successes, there have also been many casualties.
As the industry at large is moving away from the phantasmagoria of Agile, Gwaredd Mountain, Technical Director at Climax Studios, looks at Post-Agile and what this might mean for the games industry.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31081324</id>
	<title>Re:Excellent article against Agile</title>
	<author>IIRCAFAIKIANAL</author>
	<datestamp>1265728680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Some would say that if you're working nights and weekends, that's a sign you need a better iterative development methodology (like agile).</p><p>My experience has been contrary to yours. Having everyone own the code means that people don't throw bugs over the fence to the only dev that is working with that bit (who happens to be on vacation for three weeks); instead, they fix the damn bug themselves and, if they're not confident about the fix, send a note to the guy that knows the most about that code.</p><p>I don't think Agile is a silver bullet. I think iterative development with frequent testing is generally a good thing, whether it's in the form of agile, rup, whatever. Doesn't have to be Agile.</p></htmltext>
<tokenext>Some would say that if you 're working nights and weekends , that 's a sign you need a better iterative development methodology ( like agile ) .My experience has been contrary to yours .
Having everyone own the code means that people do n't throw bugs over the fence to the only dev that is working with that bit ( who happens to be on vacation for three weeks ) ; instead , they fix the damn bug themselves and , if they 're not confident about the fix , send a note to the guy that knows the most about that code.I do n't think Agile is a silver bullet .
I think iterative development with frequent testing is generally a good thing , whether it 's in the form of agile , rup , whatever .
Does n't have to be Agile .</tokentext>
<sentencetext>Some would say that if you're working nights and weekends, that's a sign you need a better iterative development methodology (like agile).My experience has been contrary to yours.
Having everyone own the code means that people don't throw bugs over the fence to the only dev that is working with that bit (who happens to be on vacation for three weeks); instead, they fix the damn bug themselves and, if they're not confident about the fix, send a note to the guy that knows the most about that code.I don't think Agile is a silver bullet.
I think iterative development with frequent testing is generally a good thing, whether it's in the form of agile, rup, whatever.
Doesn't have to be Agile.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31071842</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069488</id>
	<title>I am a game developer.</title>
	<author>Anonymous</author>
	<datestamp>1265747820000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>What the hell is he talking about?</p><p>Agile? Scrum? Waterfall? Sprints?</p><p>What do those words even mean? This article seems like it's written in some kind of alien language.  And these charts look completely worthless.</p><p>Do people in management at large corporations actually talk like this? Do they actually think charts like this somehow help them run the company better?  Ugh.</p></htmltext>
<tokenext>What the hell is he talking about ? Agile ?
Scrum ? Waterfall ?
Sprints ? What do those words even mean ?
This article seems like it 's written in some kind of alien language .
And these charts look completely worthless.Do people in management at large corporations actually talk like this ?
Do they actually think charts like this somehow help them run the company better ?
Ugh .</tokentext>
<sentencetext>What the hell is he talking about?Agile?
Scrum? Waterfall?
Sprints?What do those words even mean?
This article seems like it's written in some kind of alien language.
And these charts look completely worthless.Do people in management at large corporations actually talk like this?
Do they actually think charts like this somehow help them run the company better?
Ugh.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31072676</id>
	<title>voted for Obama, then voted for Brown.</title>
	<author>recharged95</author>
	<datestamp>1265733900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>"<i>I am not a partisan of either camp. I am only interested in results and do not have the time or inclination to advocate a particular point of view.</i>"
<br>
<br>
Great, another swing voter<nobr> <wbr></nobr>;)</htmltext>
<tokenext>" I am not a partisan of either camp .
I am only interested in results and do not have the time or inclination to advocate a particular point of view .
" Great , another swing voter ; )</tokentext>
<sentencetext>"I am not a partisan of either camp.
I am only interested in results and do not have the time or inclination to advocate a particular point of view.
"


Great, another swing voter ;)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069946</id>
	<title>Re:Not sure how Agile helps game development</title>
	<author>Anonymous</author>
	<datestamp>1265712240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>When I *do* game development, I know it is an iterative process.  You don't just sit down and churn content to deadlines.</p><p>There is a fine interplay between character control, physics, animation and content which can only be perfected iteratively.  There is also iteration towards completion.  You will never completely perfect the former, and you can and will drop levels that aren't working, or that you don't have time for.</p><p>Agile methodology is a very good fit for this, and I debate the article's context.  Game development methodology has come on in leaps and bounds since we all started picking from the Agile tree.  But game development is fundamentally hard, and getting harder.  Game project management will always be an uphill struggle.  The issue is not that you can't write a given piece of functionality in a given time, but that when you do so, there are aesthetic concerns which may not be completely addressed.  No-one has ever come up with a methodology which includes the management of aesthetics.  Historically, major works of art are usually late.</p><p>As for the "gap in QA between professional and game software development" - there's no such thing.  Game software development is by and large done professionally, and by and large has very good QA.  The gap in complexity between a server app and a game is the main thing that's widening, yet I still see fewer bugs in V1.0 of a console game than I do in V1.0 of released "professional" software.  Ironically, the main factor worsening this is the industry's widespread adoption of "internet patches", a hack used for a decade by your professional software developers to cover up the known &amp; accepted fact that no software is perfect.  For 10 years before that, our software was bug-free from day one, with a *very* few notable exceptions.</p><p>Still, you may know better than me, despite your having a low opinion of the industry in general, and no particular insight into how it works.  I look forward to the success of your games company where everyone is just a "code jockey" whose time is micro-managed on a daily basis to churn out content in predictable timescales, which somehow also has sufficient aesthetic appeal to be a commercial success.  The publishers will love you.</p></htmltext>
<tokenext>When I * do * game development , I know it is an iterative process .
You do n't just sit down and churn content to deadlines.There is a fine interplay between character control , physics , animation and content which can only be perfected iteratively .
There is also iteration towards completion .
You will never completely perfect the former , and you can and will drop levels that are n't working , or that you do n't have time for.Agile methodology is a very good fit for this , and I debate the article 's context .
Game development methodology has come on in leaps and bounds since we all started picking from the Agile tree .
But game development is fundamentally hard , and getting harder .
Game project management will always be an uphill struggle .
The issue is not that you ca n't write a given piece of functionality in a given time , but that when you do so , there are aesthetic concerns which may not be completely addressed .
No-one has ever come up with a methodology which includes the management of aesthetics .
Historically , major works of art are usually late.As for the " gap in QA between professional and game software development " - there 's no such thing .
Game software development is by and large done professionally , and by and large has very good QA .
The gap in complexity between a server app and a game is the main thing that 's widening , yet I still see fewer bugs in V1.0 of a console game than I do in V1.0 of released " professional " software .
Ironically , the main factor worsening this is the industry 's widespread adoption of " internet patches " , a hack used for a decade by your professional software developers to cover up the known &amp; accepted fact that no software is perfect .
For 10 years before that , our software was bug-free from day one , with a * very * few notable exceptions.Still , you may know better than me , despite your having a low opinion of the industry in general , and no particular insight into how it works .
I look forward to the success of your games company where everyone is just a " code jockey " whose time is micro-managed on a daily basis to churn out content in predictable timescales , which somehow also has sufficient aesthetic appeal to be a commercial success .
The publishers will love you .</tokentext>
<sentencetext>When I *do* game development, I know it is an iterative process.
You don't just sit down and churn content to deadlines.There is a fine interplay between character control, physics, animation and content which can only be perfected iteratively.
There is also iteration towards completion.
You will never completely perfect the former, and you can and will drop levels that aren't working, or that you don't have time for.Agile methodology is a very good fit for this, and I debate the article's context.
Game development methodology has come on in leaps and bounds since we all started picking from the Agile tree.
But game development is fundamentally hard, and getting harder.
Game project management will always be an uphill struggle.
The issue is not that you can't write a given piece of functionality in a given time, but that when you do so, there are aesthetic concerns which may not be completely addressed.
No-one has ever come up with a methodology which includes the management of aesthetics.
Historically, major works of art are usually late.As for the "gap in QA between professional and game software development" - there's no such thing.
Game software development is by and large done professionally, and by and large has very good QA.
The gap in complexity between a server app and a game is the main thing that's widening, yet I still see fewer bugs in V1.0 of a console game than I do in V1.0 of released "professional" software.
Ironically, the main factor worsening this is the industry's widespread adoption of "internet patches", a hack used for a decade by your professional software developers to cover up the known &amp; accepted fact that no software is perfect.
For 10 years before that, our software was bug-free from day one, with a *very* few notable exceptions.Still, you may know better than me, despite your having a low opinion of the industry in general, and no particular insight into how it works.
I look forward to the success of your games company where everyone is just a "code jockey" whose time is micro-managed on a daily basis to churn out content in predictable timescales, which somehow also has sufficient aesthetic appeal to be a commercial success.
The publishers will love you.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069340</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070924</id>
	<title>Re:Oh ... I did not know ...</title>
	<author>wrook</author>
	<datestamp>1265724720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The problem is that "Agile" as a methodology means almost nothing.  We value people over processes, etc, etc.  It could be anything.</p><p>I've worked on a couple of very successful XP style projects.  One was so successful that it surpassed my wildest expectations.  We had good people on the project, but it wasn't much different than other teams I've worked on before.  The biggest difference was an interest in the XP practices and a consistent approach to applying them.  The more we did it, the more we learned, and the more successful we became.  I can't really explain it well, but the more code we wrote, the rate at which we could implement functionality increased (exactly the opposite from other projects I'd been on).</p><p>But it's this not being able to explain our success that is the problem.  I now know what a lot of people mean when they talk about hyper-productivity in "agile" projects.  And after that wildly successful project I would look on in despair at other projects.  Management would suggest that this project was successful too and I would have to disagree.  I could point to places in the code where cruft was developing.  "All code has cruft", they would say.  But cruft slows you down.  It makes you have to think hard about what you are doing.  It makes you make difficult decisions about what you should be doing.  Truly agile projects can't afford cruft.  Think about how easy it is to write new code compared to writing code in an old system.  Well, truly agile code is *easier* to code in than new code.  And the more you write, the easier it becomes.  You get more functionality, it's better organized, it's easier to read, it gets closer and closer to the real problem domain.  And it even tells you (through "tests") when you use it improperly.</p><p>This kind of code comes from the dedication of the developers, I think.  The "agility" doesn't come from avoiding overhead.  It comes from constantly making things easier and easier.  It comes from being sensitive and saying, "That bugs me" and improving it -- every single time.  It comes from understanding the separation between the business side where the 80/20 rule applies and the technical side where the 80/20 rule means you're going into technical debt everyday.</p><p>I have no doubt that there are people who experience the "agility" that I experienced using a variety of different methods.  XP isn't what made me "agile".  It was more of a bootstrapping process that let me start understanding what was important and what wasn't.  I suspect there are people who are more talented than me who can see that without being shown.  But from experience they are very rare indeed.  And unfortunately the vast majority of people believe that "Agile" means exactly the opposite of the discipline that is required to achieve it.</p></htmltext>
<tokenext>The problem is that " Agile " as a methodology means almost nothing .
We value people over processes , etc , etc .
It could be anything.I 've worked on a couple of very successful XP style projects .
One was so successful that it surpassed my wildest expectations .
We had good people on the project , but it was n't much different than other teams I 've worked on before .
The biggest difference was an interest in the XP practices and a consistent approach to applying them .
The more we did it , the more we learned , and the more successful we became .
I ca n't really explain it well , but the more code we wrote , the rate at which we could implement functionality increased ( exactly the opposite from other projects I 'd been on ) .But it 's this not being able to explain our success that is the problem .
I now know what a lot of people mean when they talk about hyper-productivity in " agile " projects .
And after that wildly successful project I would look on in despair at other projects .
Management would suggest that this project was successful too and I would have to disagree .
I could point to places in the code where cruft was developing .
" All code has cruft " , they would say .
But cruft slows you down .
It makes you have to think hard about what you are doing .
It makes you make difficult decisions about what you should be doing .
Truly agile projects ca n't afford cruft .
Think about how easy it is to write new code compared to writing code in an old system .
Well , truly agile code is * easier * to code in than new code .
And the more you write , the easier it becomes .
You get more functionality , it 's better organized , it 's easier to read , it gets closer and closer to the real problem domain .
And it even tells you ( through " tests " ) when you use it improperly.This kind of code comes from the dedication of the developers , I think .
The " agility " does n't come from avoiding overhead .
It comes from constantly making things easier and easier .
It comes from being sensitive and saying , " That bugs me " and improving it -- every single time .
It comes from understanding the separation between the business side where the 80/20 rule applies and the technical side where the 80/20 rule means you 're going into technical debt everyday.I have no doubt that there are people who experience the " agility " that I experienced using a variety of different methods .
XP is n't what made me " agile " .
It was more of a bootstrapping process that let me start understanding what was important and what was n't .
I suspect there are people who are more talented than me who can see that without being shown .
But from experience they are very rare indeed .
And unfortunately the vast majority of people believe that " Agile " means exactly the opposite of the discipline that is required to achieve it .</tokentext>
<sentencetext>The problem is that "Agile" as a methodology means almost nothing.
We value people over processes, etc, etc.
It could be anything.I've worked on a couple of very successful XP style projects.
One was so successful that it surpassed my wildest expectations.
We had good people on the project, but it wasn't much different than other teams I've worked on before.
The biggest difference was an interest in the XP practices and a consistent approach to applying them.
The more we did it, the more we learned, and the more successful we became.
I can't really explain it well, but the more code we wrote, the rate at which we could implement functionality increased (exactly the opposite from other projects I'd been on).But it's this not being able to explain our success that is the problem.
I now know what a lot of people mean when they talk about hyper-productivity in "agile" projects.
And after that wildly successful project I would look on in despair at other projects.
Management would suggest that this project was successful too and I would have to disagree.
I could point to places in the code where cruft was developing.
"All code has cruft", they would say.
But cruft slows you down.
It makes you have to think hard about what you are doing.
It makes you make difficult decisions about what you should be doing.
Truly agile projects can't afford cruft.
Think about how easy it is to write new code compared to writing code in an old system.
Well, truly agile code is *easier* to code in than new code.
And the more you write, the easier it becomes.
You get more functionality, it's better organized, it's easier to read, it gets closer and closer to the real problem domain.
And it even tells you (through "tests") when you use it improperly.This kind of code comes from the dedication of the developers, I think.
The "agility" doesn't come from avoiding overhead.
It comes from constantly making things easier and easier.
It comes from being sensitive and saying, "That bugs me" and improving it -- every single time.
It comes from understanding the separation between the business side where the 80/20 rule applies and the technical side where the 80/20 rule means you're going into technical debt everyday.I have no doubt that there are people who experience the "agility" that I experienced using a variety of different methods.
XP isn't what made me "agile".
It was more of a bootstrapping process that let me start understanding what was important and what wasn't.
I suspect there are people who are more talented than me who can see that without being shown.
But from experience they are very rare indeed.
And unfortunately the vast majority of people believe that "Agile" means exactly the opposite of the discipline that is required to achieve it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069712</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069642</id>
	<title>there is no engineering in software</title>
	<author>Anonymous</author>
	<datestamp>1265706720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Software development is still a craft.. more than art, but way less than engineering..</p><p>until we have tools to make software in a consistent, reproductible way, we can't apply engineering tecniques to software development</p><p>until then, we have to treat it as a craft.</p><p>we have to focus on communication of processes between people</p><p>the main problem today in software development is communication.<br>with the client, between developers, with management.</p><p>we have to develop tools to help the client communicate better the expectations. tools to help the developers communicate to the management how long it will take to do what. and to help management communicate to the client what will really be done, and how much it will cost, and how long it will take</p></htmltext>
<tokenext>Software development is still a craft.. more than art , but way less than engineering..until we have tools to make software in a consistent , reproductible way , we ca n't apply engineering tecniques to software developmentuntil then , we have to treat it as a craft.we have to focus on communication of processes between peoplethe main problem today in software development is communication.with the client , between developers , with management.we have to develop tools to help the client communicate better the expectations .
tools to help the developers communicate to the management how long it will take to do what .
and to help management communicate to the client what will really be done , and how much it will cost , and how long it will take</tokentext>
<sentencetext>Software development is still a craft.. more than art, but way less than engineering..until we have tools to make software in a consistent, reproductible way, we can't apply engineering tecniques to software developmentuntil then, we have to treat it as a craft.we have to focus on communication of processes between peoplethe main problem today in software development is communication.with the client, between developers, with management.we have to develop tools to help the client communicate better the expectations.
tools to help the developers communicate to the management how long it will take to do what.
and to help management communicate to the client what will really be done, and how much it will cost, and how long it will take</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069688</id>
	<title>Re:Staring blankly</title>
	<author>RPoet</author>
	<datestamp>1265707740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You know, it's about leveraging the curation of your social graph in the hyperpersonal news-stream of the post-2.0 web. I think.</p></htmltext>
<tokenext>You know , it 's about leveraging the curation of your social graph in the hyperpersonal news-stream of the post-2.0 web .
I think .</tokentext>
<sentencetext>You know, it's about leveraging the curation of your social graph in the hyperpersonal news-stream of the post-2.0 web.
I think.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069584</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070084</id>
	<title>Re:When to use "agile" methods.</title>
	<author>CrazyIvanovich</author>
	<datestamp>1265715120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Exactly! Your life cycle for software is a design choice just like any other!  I don't know how many times I puked in my mouth during software engineering classes in college where we were simply beaten with "Waterfall bad; Iterative good!" in the name of 'No Silver Bullet.'  It completely misses the point!  The title says it all, if you believe it.</p><p>The life cycle of your product needs tailored to its requirements.</p></htmltext>
<tokenext>Exactly !
Your life cycle for software is a design choice just like any other !
I do n't know how many times I puked in my mouth during software engineering classes in college where we were simply beaten with " Waterfall bad ; Iterative good !
" in the name of 'No Silver Bullet .
' It completely misses the point !
The title says it all , if you believe it.The life cycle of your product needs tailored to its requirements .</tokentext>
<sentencetext>Exactly!
Your life cycle for software is a design choice just like any other!
I don't know how many times I puked in my mouth during software engineering classes in college where we were simply beaten with "Waterfall bad; Iterative good!
" in the name of 'No Silver Bullet.
'  It completely misses the point!
The title says it all, if you believe it.The life cycle of your product needs tailored to its requirements.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070254</id>
	<title>Was it ever Agile?</title>
	<author>SharpFang</author>
	<datestamp>1265716980000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>The problem is not in "Agile" methodology.</p><p>The problem is in "Mongolian Clusterfuck" methodology, called "Agile" by managers who think "Mongolian Clusterfuck" isn't catchy enough.</p><p>Agile sets short reachable targets, and reiterates and modifies them upon reaching them. The cycle is 2-4 weeks.</p><p>Mongolian Clusterfuck is similar, but the cycle is 2-4 hours and the targets that haven't been reached are abandonned half-finished.</p><p>Agile has specs that accept modifications when the customer requests them. Mongolian Clusterfuck has specs that change every time your boss stops by.</p><p>Agile has daily meetings of what problems to solve and how. Mongolian Clusterfuck is "this is broken, leave whatever you're doing and fix it now."</p><p>Agile has one clear set of goals of a golden middle between performance, stability, portability, cost, time and maintainablity. Mongolian Clusterfuck has two. Simultaneously.</p><p>Game development is exceptionally prone to Mongolian Clusterfuck methodology. And then people who never knew Agile think it sucks bad.</p></htmltext>
<tokenext>The problem is not in " Agile " methodology.The problem is in " Mongolian Clusterfuck " methodology , called " Agile " by managers who think " Mongolian Clusterfuck " is n't catchy enough.Agile sets short reachable targets , and reiterates and modifies them upon reaching them .
The cycle is 2-4 weeks.Mongolian Clusterfuck is similar , but the cycle is 2-4 hours and the targets that have n't been reached are abandonned half-finished.Agile has specs that accept modifications when the customer requests them .
Mongolian Clusterfuck has specs that change every time your boss stops by.Agile has daily meetings of what problems to solve and how .
Mongolian Clusterfuck is " this is broken , leave whatever you 're doing and fix it now .
" Agile has one clear set of goals of a golden middle between performance , stability , portability , cost , time and maintainablity .
Mongolian Clusterfuck has two .
Simultaneously.Game development is exceptionally prone to Mongolian Clusterfuck methodology .
And then people who never knew Agile think it sucks bad .</tokentext>
<sentencetext>The problem is not in "Agile" methodology.The problem is in "Mongolian Clusterfuck" methodology, called "Agile" by managers who think "Mongolian Clusterfuck" isn't catchy enough.Agile sets short reachable targets, and reiterates and modifies them upon reaching them.
The cycle is 2-4 weeks.Mongolian Clusterfuck is similar, but the cycle is 2-4 hours and the targets that haven't been reached are abandonned half-finished.Agile has specs that accept modifications when the customer requests them.
Mongolian Clusterfuck has specs that change every time your boss stops by.Agile has daily meetings of what problems to solve and how.
Mongolian Clusterfuck is "this is broken, leave whatever you're doing and fix it now.
"Agile has one clear set of goals of a golden middle between performance, stability, portability, cost, time and maintainablity.
Mongolian Clusterfuck has two.
Simultaneously.Game development is exceptionally prone to Mongolian Clusterfuck methodology.
And then people who never knew Agile think it sucks bad.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069468</id>
	<title>Many games developers ?</title>
	<author>Antiocheian</author>
	<datestamp>1265747580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Many games developers have been pursuing agile development</p></div><p>Who ?</p></div>
	</htmltext>
<tokenext>Many games developers have been pursuing agile developmentWho ?</tokentext>
<sentencetext>Many games developers have been pursuing agile developmentWho ?
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069444</id>
	<title>Re:Conclusions</title>
	<author>Anonymous</author>
	<datestamp>1265746920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I've seen agile cause colossal messes; I've seen agile make miracles happen.  The only conclusion I have is that "a fool with a tool is still a fool".</p><p>Think of agile as advanced martial arts; if you've mastered the basics, it'll take you to the next level.  If you haven't, you just wind up hurting yourself.</p></htmltext>
<tokenext>I 've seen agile cause colossal messes ; I 've seen agile make miracles happen .
The only conclusion I have is that " a fool with a tool is still a fool " .Think of agile as advanced martial arts ; if you 've mastered the basics , it 'll take you to the next level .
If you have n't , you just wind up hurting yourself .</tokentext>
<sentencetext>I've seen agile cause colossal messes; I've seen agile make miracles happen.
The only conclusion I have is that "a fool with a tool is still a fool".Think of agile as advanced martial arts; if you've mastered the basics, it'll take you to the next level.
If you haven't, you just wind up hurting yourself.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069712</id>
	<title>Oh ... I did not know ...</title>
	<author>Anonymous</author>
	<datestamp>1265708280000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>that<br><i>As the industry at large is moving away from the phantasmagoria of Agile<nobr> <wbr></nobr>... </i></p><p>I guess calling Agile a <i>silver bullet</i> and/or calling it a <i>hype</i> or <i>anti hype</i> is just a thing of the media. As a Software Developer you are used to at least <i>know</i> the best tool for your job and the best language for your job (albeit some reasons may prevent you from using them). The same should be true for software project management methods.</p><p>Keep in mind that perhaps 50\% of all software development houses have no <b>method</b> at all but just do it with more or less success. That often is topped by neither having a version control system nor having an issue tracker. <i>Project management</i> is done with Excel Sheets, which are mailed around and edited/annotated by multiple persons.</p><p>Calling Agile "failing" is in my eyes a clear sign that you have no clue about it.</p><p>Every single thing that is stated as best practice in TDD, XP or Scrum is a <b>very good thing</b> to do in your process, regardless wether you follow any of those methods strict or prefer a more traditional approach.</p><p>Most people calling Agile fail either have (as I stated above) no process at all, never tried it, or <b>already do</b> do a lot of the core practices like nightly builds and continuos integration etc.</p><p>This said: no one ever claimed that a good running traditional process which is already yielding high quality result would be even better if run Agile. However everyone who has <b>no process</b>, everyone who has quality problems, everyone who has tracking, budget delivery time problems, those have a much easier term in adopting some agile process and a much easier introduction and adoption of tools instead of one who switches to RUP or similar heavy weight processes.</p><p>angel'o'sphere</p></htmltext>
<tokenext>thatAs the industry at large is moving away from the phantasmagoria of Agile ... I guess calling Agile a silver bullet and/or calling it a hype or anti hype is just a thing of the media .
As a Software Developer you are used to at least know the best tool for your job and the best language for your job ( albeit some reasons may prevent you from using them ) .
The same should be true for software project management methods.Keep in mind that perhaps 50 \ % of all software development houses have no method at all but just do it with more or less success .
That often is topped by neither having a version control system nor having an issue tracker .
Project management is done with Excel Sheets , which are mailed around and edited/annotated by multiple persons.Calling Agile " failing " is in my eyes a clear sign that you have no clue about it.Every single thing that is stated as best practice in TDD , XP or Scrum is a very good thing to do in your process , regardless wether you follow any of those methods strict or prefer a more traditional approach.Most people calling Agile fail either have ( as I stated above ) no process at all , never tried it , or already do do a lot of the core practices like nightly builds and continuos integration etc.This said : no one ever claimed that a good running traditional process which is already yielding high quality result would be even better if run Agile .
However everyone who has no process , everyone who has quality problems , everyone who has tracking , budget delivery time problems , those have a much easier term in adopting some agile process and a much easier introduction and adoption of tools instead of one who switches to RUP or similar heavy weight processes.angel'o'sphere</tokentext>
<sentencetext>thatAs the industry at large is moving away from the phantasmagoria of Agile ... I guess calling Agile a silver bullet and/or calling it a hype or anti hype is just a thing of the media.
As a Software Developer you are used to at least know the best tool for your job and the best language for your job (albeit some reasons may prevent you from using them).
The same should be true for software project management methods.Keep in mind that perhaps 50\% of all software development houses have no method at all but just do it with more or less success.
That often is topped by neither having a version control system nor having an issue tracker.
Project management is done with Excel Sheets, which are mailed around and edited/annotated by multiple persons.Calling Agile "failing" is in my eyes a clear sign that you have no clue about it.Every single thing that is stated as best practice in TDD, XP or Scrum is a very good thing to do in your process, regardless wether you follow any of those methods strict or prefer a more traditional approach.Most people calling Agile fail either have (as I stated above) no process at all, never tried it, or already do do a lot of the core practices like nightly builds and continuos integration etc.This said: no one ever claimed that a good running traditional process which is already yielding high quality result would be even better if run Agile.
However everyone who has no process, everyone who has quality problems, everyone who has tracking, budget delivery time problems, those have a much easier term in adopting some agile process and a much easier introduction and adoption of tools instead of one who switches to RUP or similar heavy weight processes.angel'o'sphere</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31072964</id>
	<title>Re:Oh ... I did not know ...</title>
	<author>shutdown -p now</author>
	<datestamp>1265735100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Every single thing that is stated as best practice in TDD, XP or Scrum is a very good thing</p></div><p>Is overcomplicating and mangling your code to conform to the limitations of your testing framework a very good thing?</p></div>
	</htmltext>
<tokenext>Every single thing that is stated as best practice in TDD , XP or Scrum is a very good thingIs overcomplicating and mangling your code to conform to the limitations of your testing framework a very good thing ?</tokentext>
<sentencetext>Every single thing that is stated as best practice in TDD, XP or Scrum is a very good thingIs overcomplicating and mangling your code to conform to the limitations of your testing framework a very good thing?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069712</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069584</id>
	<title>Staring blankly</title>
	<author>Anonymous</author>
	<datestamp>1265749080000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext>I don't know what anything in this thread means.
<br>
<br><nobr> <wbr></nobr>...but I like games.</htmltext>
<tokenext>I do n't know what anything in this thread means .
...but I like games .</tokentext>
<sentencetext>I don't know what anything in this thread means.
...but I like games.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073544</id>
	<title>Re:Not sure how Agile helps game development</title>
	<author>Monkeedude1212</author>
	<datestamp>1265737080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It really depends on the game and the end goal in mind, and how you want to achieve getting there.</p><p>I've just started this past week with my room mate the idea of a web based RPG. Think Dungeons and dragons with a Pokemon style interface. Anyways, for something like that, there are a lot of aspects to it, basically everything world of warcraft would have, minus the engine.</p><p>So what I have in mind is a mostly agile development. It will initially be released as a stand alone combat system, you have your character and your stats and you get experience for fighting other characters. While I don't expect it to "Take off" just on that alone, it'll be public to start growing in fan base and get the word around. Then each module will be added on. Marketplace, Crafting, Locations and movement, Dungeons, etc etc.</p><p>Agile development will basically be giving everyone a public beta testing of modules I complete, allowing me to address bugs while working on other modules.</p><p>It might eventually come in to play that we integrate this with some form of flash game, we have discussed the possibilities. If all goes well, we may have to build one using the Source engine from Valve.</p></htmltext>
<tokenext>It really depends on the game and the end goal in mind , and how you want to achieve getting there.I 've just started this past week with my room mate the idea of a web based RPG .
Think Dungeons and dragons with a Pokemon style interface .
Anyways , for something like that , there are a lot of aspects to it , basically everything world of warcraft would have , minus the engine.So what I have in mind is a mostly agile development .
It will initially be released as a stand alone combat system , you have your character and your stats and you get experience for fighting other characters .
While I do n't expect it to " Take off " just on that alone , it 'll be public to start growing in fan base and get the word around .
Then each module will be added on .
Marketplace , Crafting , Locations and movement , Dungeons , etc etc.Agile development will basically be giving everyone a public beta testing of modules I complete , allowing me to address bugs while working on other modules.It might eventually come in to play that we integrate this with some form of flash game , we have discussed the possibilities .
If all goes well , we may have to build one using the Source engine from Valve .</tokentext>
<sentencetext>It really depends on the game and the end goal in mind, and how you want to achieve getting there.I've just started this past week with my room mate the idea of a web based RPG.
Think Dungeons and dragons with a Pokemon style interface.
Anyways, for something like that, there are a lot of aspects to it, basically everything world of warcraft would have, minus the engine.So what I have in mind is a mostly agile development.
It will initially be released as a stand alone combat system, you have your character and your stats and you get experience for fighting other characters.
While I don't expect it to "Take off" just on that alone, it'll be public to start growing in fan base and get the word around.
Then each module will be added on.
Marketplace, Crafting, Locations and movement, Dungeons, etc etc.Agile development will basically be giving everyone a public beta testing of modules I complete, allowing me to address bugs while working on other modules.It might eventually come in to play that we integrate this with some form of flash game, we have discussed the possibilities.
If all goes well, we may have to build one using the Source engine from Valve.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069340</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069538</id>
	<title>Re:I am a game developer.</title>
	<author>91degrees</author>
	<datestamp>1265748480000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>Yes.  It's convenient jargon.  Scrum is a design methodology.  Sprints are short project segments where a defined piece of work is completed.  Waterfall is the traditional requirements, design, implementation, verification, maintenance way of developing software.  <br> <br>
We use these terms because it's very long winded to spell out what we mean in much the same way that we say wi-fi when talking about a wireless system for transmitting data between general purpose computing devices.</htmltext>
<tokenext>Yes .
It 's convenient jargon .
Scrum is a design methodology .
Sprints are short project segments where a defined piece of work is completed .
Waterfall is the traditional requirements , design , implementation , verification , maintenance way of developing software .
We use these terms because it 's very long winded to spell out what we mean in much the same way that we say wi-fi when talking about a wireless system for transmitting data between general purpose computing devices .</tokentext>
<sentencetext>Yes.
It's convenient jargon.
Scrum is a design methodology.
Sprints are short project segments where a defined piece of work is completed.
Waterfall is the traditional requirements, design, implementation, verification, maintenance way of developing software.
We use these terms because it's very long winded to spell out what we mean in much the same way that we say wi-fi when talking about a wireless system for transmitting data between general purpose computing devices.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069488</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069496</id>
	<title>Re:Not sure how Agile helps game development</title>
	<author>hackerjoe</author>
	<datestamp>1265747940000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>It's easy to lose track of the fact that good software is written by good teams.</p><p>I've worked on a couple of game teams that used scrum, and I'm kind of with you in that I don't think it made a whole lot of sense. However, nobody on our teams believed scrum precluded longer-term waterfall-style planning -- so we did that too, we just used scrum for the week-to-week divvying up the work. My impression is that a functional, experienced team can make something workable out of pretty much any process, we certainly did.</p><p>Those were traditional fire-and-forget commercial titles, though. Scrum makes a lot more sense for a long-life-cycle online game where you're adding features on a regular basis for 5 years post-launch. This is actually very similar to the context where (I understand) scrum is usually employed: internal information systems that see regular revisions for years after they're put in service.</p></htmltext>
<tokenext>It 's easy to lose track of the fact that good software is written by good teams.I 've worked on a couple of game teams that used scrum , and I 'm kind of with you in that I do n't think it made a whole lot of sense .
However , nobody on our teams believed scrum precluded longer-term waterfall-style planning -- so we did that too , we just used scrum for the week-to-week divvying up the work .
My impression is that a functional , experienced team can make something workable out of pretty much any process , we certainly did.Those were traditional fire-and-forget commercial titles , though .
Scrum makes a lot more sense for a long-life-cycle online game where you 're adding features on a regular basis for 5 years post-launch .
This is actually very similar to the context where ( I understand ) scrum is usually employed : internal information systems that see regular revisions for years after they 're put in service .</tokentext>
<sentencetext>It's easy to lose track of the fact that good software is written by good teams.I've worked on a couple of game teams that used scrum, and I'm kind of with you in that I don't think it made a whole lot of sense.
However, nobody on our teams believed scrum precluded longer-term waterfall-style planning -- so we did that too, we just used scrum for the week-to-week divvying up the work.
My impression is that a functional, experienced team can make something workable out of pretty much any process, we certainly did.Those were traditional fire-and-forget commercial titles, though.
Scrum makes a lot more sense for a long-life-cycle online game where you're adding features on a regular basis for 5 years post-launch.
This is actually very similar to the context where (I understand) scrum is usually employed: internal information systems that see regular revisions for years after they're put in service.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069340</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069340</id>
	<title>Not sure how Agile helps game development</title>
	<author>dhall</author>
	<datestamp>1265658300000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>When I think of game development, I think of milestones.  I think of (relatively) set targets.  This is more true for console games than PC game, but lately when I think of games I think console first.</p><p>Iterative style development?  Maybe that might work for an MMO where the customers don't mind being permanent beta testers.  The gap in QA between professional and game software development already feels pretty vast, but add to that yet another style that promotes a more aggressive, less strict regimen of development just sounds like a recipe of disaster.</p><p>I'm not sure when Agile became the silver bullet buzzword for programming. I have participated in it, attended Ken Schwaber's talks on managing scrums.  I can see its positives and negatives, and it's difficult for me to see how game software development could benefit from being agile unless you're coming up with the next big project with a bunch of friends in your 'garage'.  Designing your own game engine and concepts from the ground up where nearly every member of your team is a software architect level and the lightweight methods help.  Otherwise if you're a code jockey working on a pre-existing engine then project management and deadlines are likely more effective.</p><p>And try pairing up agile software development with offshoring.  It reminds me of the old "don't do drugs" commercials with the eggs.</p><p>*holds up an egg* this is your software development<br>*cracks egg* this is going agile<br>*opens egg over stove* this is agile offshoring<br>*ignores the fact that there is no pan to catch the egg* any questions?</p></htmltext>
<tokenext>When I think of game development , I think of milestones .
I think of ( relatively ) set targets .
This is more true for console games than PC game , but lately when I think of games I think console first.Iterative style development ?
Maybe that might work for an MMO where the customers do n't mind being permanent beta testers .
The gap in QA between professional and game software development already feels pretty vast , but add to that yet another style that promotes a more aggressive , less strict regimen of development just sounds like a recipe of disaster.I 'm not sure when Agile became the silver bullet buzzword for programming .
I have participated in it , attended Ken Schwaber 's talks on managing scrums .
I can see its positives and negatives , and it 's difficult for me to see how game software development could benefit from being agile unless you 're coming up with the next big project with a bunch of friends in your 'garage' .
Designing your own game engine and concepts from the ground up where nearly every member of your team is a software architect level and the lightweight methods help .
Otherwise if you 're a code jockey working on a pre-existing engine then project management and deadlines are likely more effective.And try pairing up agile software development with offshoring .
It reminds me of the old " do n't do drugs " commercials with the eggs .
* holds up an egg * this is your software development * cracks egg * this is going agile * opens egg over stove * this is agile offshoring * ignores the fact that there is no pan to catch the egg * any questions ?</tokentext>
<sentencetext>When I think of game development, I think of milestones.
I think of (relatively) set targets.
This is more true for console games than PC game, but lately when I think of games I think console first.Iterative style development?
Maybe that might work for an MMO where the customers don't mind being permanent beta testers.
The gap in QA between professional and game software development already feels pretty vast, but add to that yet another style that promotes a more aggressive, less strict regimen of development just sounds like a recipe of disaster.I'm not sure when Agile became the silver bullet buzzword for programming.
I have participated in it, attended Ken Schwaber's talks on managing scrums.
I can see its positives and negatives, and it's difficult for me to see how game software development could benefit from being agile unless you're coming up with the next big project with a bunch of friends in your 'garage'.
Designing your own game engine and concepts from the ground up where nearly every member of your team is a software architect level and the lightweight methods help.
Otherwise if you're a code jockey working on a pre-existing engine then project management and deadlines are likely more effective.And try pairing up agile software development with offshoring.
It reminds me of the old "don't do drugs" commercials with the eggs.
*holds up an egg* this is your software development*cracks egg* this is going agile*opens egg over stove* this is agile offshoring*ignores the fact that there is no pan to catch the egg* any questions?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070024</id>
	<title>Agile without user feedback!???</title>
	<author>Aceticon</author>
	<datestamp>1265714100000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>The essential philosophy of Agile is that development should be done in tight cycles were small self-contained features are designed and implemented, followed by user feedback while planning for the next cycle.</p><p>This process is intended to cope with a couple of problems from the old waterfall model, such as:</p><ul><li>End users of a system have needs but they don't know them fully and correctly up-front, so a fully defined requirements document is impossible. Tight cycles of feature-development-user-feedback facilitate user discovery of requirements and allow for small adjustments based on user feedback.</li><li>It avoids the "As soon as we give the requirements to the IT guys we stop hearing from them for a year while all they tell us is that 'they're working on it'" problem. The end users of the system being developed become part of the development process in an Agile process - that brings all sorts of benefits like keeping them happy and getting quick feedback on potential problems.</li><li>The planning stage before each cycle helps with prunning of low-value-high-cost features. By having the user-stakeholder choose the priority of the features to implement in each cycle, the important features will not be left behind just because they didn't look important to the developers</li></ul><p>All that this has in common is the existence of end-users (which can be other systems, if your system does not have an UI), which have roughly defined needs (typically a business process) which the software being built will address.</p><p>Now look at games:</p><ul><li>The real end-users (gamers) need entertainment. They don't have a pre-existent process which the game would automate to achieve that - in fact some of the best entertainement comes from games that do things no games ever done before. </li><li>"Having fun" is an emotional state which depends on many things that are difficult to pin-down and that even change over time and depend on the user's mind-set: a way to make users achive it cannot be discovered as part of small interactive development loops</li><li>There is no typical end user that can act as a representative of the other users. In fact a successfull game aims to entertain as many sorts of users as possible and as cannot be tunned to the wishes of only some users</li><li>Games are often one-pass entertainment: you play it once and then you never play it again. This means that any users trying the game in between the tight development cycles of Agile would quickly become useless as test-subjects (as boredom overwelmed fun)</li><li>The programming part of a game is often the least important bit of it. In fact in most modern games the code just powers the rules engines (for the mechanics of the games) and the graphics engine (that gives shape to the game world and displays the artwork) and is at it's best when it's not noticed.</li></ul><p>So games don't usually fit in the (software development context) pattern for using Agile development methodologies wholesale.</p><p>At best, some games might have a creative person behind it with a vision which can serve as the user-stakeholder, but even then often the "vision" is vague and can change a lot over time (a "vision" is much less prone to a continuously-improving discovery process than a "business process" - in fact if the person with the "vision" is not methodical, you end up with a process where a cycle is just as likelly to take the software closer to the "vision" as it is to take it further way from it).</p><p>To repeat the often heard (but seldom heeded) motto: <i> <b>"There is no silver bullet!"</b> </i></p></htmltext>
<tokenext>The essential philosophy of Agile is that development should be done in tight cycles were small self-contained features are designed and implemented , followed by user feedback while planning for the next cycle.This process is intended to cope with a couple of problems from the old waterfall model , such as : End users of a system have needs but they do n't know them fully and correctly up-front , so a fully defined requirements document is impossible .
Tight cycles of feature-development-user-feedback facilitate user discovery of requirements and allow for small adjustments based on user feedback.It avoids the " As soon as we give the requirements to the IT guys we stop hearing from them for a year while all they tell us is that 'they 're working on it ' " problem .
The end users of the system being developed become part of the development process in an Agile process - that brings all sorts of benefits like keeping them happy and getting quick feedback on potential problems.The planning stage before each cycle helps with prunning of low-value-high-cost features .
By having the user-stakeholder choose the priority of the features to implement in each cycle , the important features will not be left behind just because they did n't look important to the developersAll that this has in common is the existence of end-users ( which can be other systems , if your system does not have an UI ) , which have roughly defined needs ( typically a business process ) which the software being built will address.Now look at games : The real end-users ( gamers ) need entertainment .
They do n't have a pre-existent process which the game would automate to achieve that - in fact some of the best entertainement comes from games that do things no games ever done before .
" Having fun " is an emotional state which depends on many things that are difficult to pin-down and that even change over time and depend on the user 's mind-set : a way to make users achive it can not be discovered as part of small interactive development loopsThere is no typical end user that can act as a representative of the other users .
In fact a successfull game aims to entertain as many sorts of users as possible and as can not be tunned to the wishes of only some usersGames are often one-pass entertainment : you play it once and then you never play it again .
This means that any users trying the game in between the tight development cycles of Agile would quickly become useless as test-subjects ( as boredom overwelmed fun ) The programming part of a game is often the least important bit of it .
In fact in most modern games the code just powers the rules engines ( for the mechanics of the games ) and the graphics engine ( that gives shape to the game world and displays the artwork ) and is at it 's best when it 's not noticed.So games do n't usually fit in the ( software development context ) pattern for using Agile development methodologies wholesale.At best , some games might have a creative person behind it with a vision which can serve as the user-stakeholder , but even then often the " vision " is vague and can change a lot over time ( a " vision " is much less prone to a continuously-improving discovery process than a " business process " - in fact if the person with the " vision " is not methodical , you end up with a process where a cycle is just as likelly to take the software closer to the " vision " as it is to take it further way from it ) .To repeat the often heard ( but seldom heeded ) motto : " There is no silver bullet !
"</tokentext>
<sentencetext>The essential philosophy of Agile is that development should be done in tight cycles were small self-contained features are designed and implemented, followed by user feedback while planning for the next cycle.This process is intended to cope with a couple of problems from the old waterfall model, such as:End users of a system have needs but they don't know them fully and correctly up-front, so a fully defined requirements document is impossible.
Tight cycles of feature-development-user-feedback facilitate user discovery of requirements and allow for small adjustments based on user feedback.It avoids the "As soon as we give the requirements to the IT guys we stop hearing from them for a year while all they tell us is that 'they're working on it'" problem.
The end users of the system being developed become part of the development process in an Agile process - that brings all sorts of benefits like keeping them happy and getting quick feedback on potential problems.The planning stage before each cycle helps with prunning of low-value-high-cost features.
By having the user-stakeholder choose the priority of the features to implement in each cycle, the important features will not be left behind just because they didn't look important to the developersAll that this has in common is the existence of end-users (which can be other systems, if your system does not have an UI), which have roughly defined needs (typically a business process) which the software being built will address.Now look at games:The real end-users (gamers) need entertainment.
They don't have a pre-existent process which the game would automate to achieve that - in fact some of the best entertainement comes from games that do things no games ever done before.
"Having fun" is an emotional state which depends on many things that are difficult to pin-down and that even change over time and depend on the user's mind-set: a way to make users achive it cannot be discovered as part of small interactive development loopsThere is no typical end user that can act as a representative of the other users.
In fact a successfull game aims to entertain as many sorts of users as possible and as cannot be tunned to the wishes of only some usersGames are often one-pass entertainment: you play it once and then you never play it again.
This means that any users trying the game in between the tight development cycles of Agile would quickly become useless as test-subjects (as boredom overwelmed fun)The programming part of a game is often the least important bit of it.
In fact in most modern games the code just powers the rules engines (for the mechanics of the games) and the graphics engine (that gives shape to the game world and displays the artwork) and is at it's best when it's not noticed.So games don't usually fit in the (software development context) pattern for using Agile development methodologies wholesale.At best, some games might have a creative person behind it with a vision which can serve as the user-stakeholder, but even then often the "vision" is vague and can change a lot over time (a "vision" is much less prone to a continuously-improving discovery process than a "business process" - in fact if the person with the "vision" is not methodical, you end up with a process where a cycle is just as likelly to take the software closer to the "vision" as it is to take it further way from it).To repeat the often heard (but seldom heeded) motto:  "There is no silver bullet!
" </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073788</id>
	<title>Re:Not sure how Agile helps game development</title>
	<author>hey!</author>
	<datestamp>1265737920000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Look. Anybody with a brain knows that many agile practices don't apply to certain kinds of projects. That's just common sense.   I've been in this business long enough to have seen a parade of silver bullet methodologies go by.  All of them worked for people who had the development experience, business awareness, and common sense to know when to bend the rules or ignore them.  Likewise none of them would take a person incapable of delivering a project and fix that.</p><p>"Agile" is a marketing term, and like most marketing terms it's a lie.   Agile works best in those places that left without guidance would try to be too agile for their own good.  The places where management, if you let them, will barge in twice a day with a new direction.  Now if you know developers, you know they have good days and bad days, and if you want to get anything out of them you've got to give them a long enough stretch in one direction so that they can catch the wind in their sails.  So you take down a few books from your shelf, and you say, "This is the latest thing. It's *agile development*."</p><p>Immediately management gets it. It's about getting more done faster.  What you don't tell them is that it's about keeping them out of your team's hair long enough to get *anything* done.</p><p>Now if you can define a good set of requirements and keep the goalposts from moving for longer periods, that's even better.  Thirty days is a reasonable compromise for a sprint.  You want to measure progress in a detailed way at least that often anyway, and it provides ample time to get identifiable bits done and to even try and discard a few creative approaches. But there's nothing magically necessary about changing priorities every thirty days.  If you can reasonably keep them constant for six months, that'd be even better.  But in *some* kinds of development that's not possible.</p><p>When you are building software to support business functions, priorities shift based on the response to competition, assumptions in the business plan that don't pan out etc.  Even the software itself changes the requirements environment. I've been in situations where I know that the organization needs B, but they can't *see* that need until they've seen A first.  So the quintessentially agile part of "agile" is  really indispensable on these kinds of "dynamic requirements" jobs.  The rest of it (unit testing etc.) is just motherhood and apple pie engineering.</p><p>Now as far as the game industry is concerned, everything I've heard about it makes it sound like a horror show.  I attribute this to two things.  First it is attractive to young folks enamored of the romance of creating the kind of games they love.  In other words people easy to exploit.   The other factor is bravado and immaturity of the company management.  In time as the people in the industry mature, maybe things will change.  But "methodology" isn't going to solve the problem of self-deluded and exploitative management.</p></htmltext>
<tokenext>Look .
Anybody with a brain knows that many agile practices do n't apply to certain kinds of projects .
That 's just common sense .
I 've been in this business long enough to have seen a parade of silver bullet methodologies go by .
All of them worked for people who had the development experience , business awareness , and common sense to know when to bend the rules or ignore them .
Likewise none of them would take a person incapable of delivering a project and fix that .
" Agile " is a marketing term , and like most marketing terms it 's a lie .
Agile works best in those places that left without guidance would try to be too agile for their own good .
The places where management , if you let them , will barge in twice a day with a new direction .
Now if you know developers , you know they have good days and bad days , and if you want to get anything out of them you 've got to give them a long enough stretch in one direction so that they can catch the wind in their sails .
So you take down a few books from your shelf , and you say , " This is the latest thing .
It 's * agile development * .
" Immediately management gets it .
It 's about getting more done faster .
What you do n't tell them is that it 's about keeping them out of your team 's hair long enough to get * anything * done.Now if you can define a good set of requirements and keep the goalposts from moving for longer periods , that 's even better .
Thirty days is a reasonable compromise for a sprint .
You want to measure progress in a detailed way at least that often anyway , and it provides ample time to get identifiable bits done and to even try and discard a few creative approaches .
But there 's nothing magically necessary about changing priorities every thirty days .
If you can reasonably keep them constant for six months , that 'd be even better .
But in * some * kinds of development that 's not possible.When you are building software to support business functions , priorities shift based on the response to competition , assumptions in the business plan that do n't pan out etc .
Even the software itself changes the requirements environment .
I 've been in situations where I know that the organization needs B , but they ca n't * see * that need until they 've seen A first .
So the quintessentially agile part of " agile " is really indispensable on these kinds of " dynamic requirements " jobs .
The rest of it ( unit testing etc .
) is just motherhood and apple pie engineering.Now as far as the game industry is concerned , everything I 've heard about it makes it sound like a horror show .
I attribute this to two things .
First it is attractive to young folks enamored of the romance of creating the kind of games they love .
In other words people easy to exploit .
The other factor is bravado and immaturity of the company management .
In time as the people in the industry mature , maybe things will change .
But " methodology " is n't going to solve the problem of self-deluded and exploitative management .</tokentext>
<sentencetext>Look.
Anybody with a brain knows that many agile practices don't apply to certain kinds of projects.
That's just common sense.
I've been in this business long enough to have seen a parade of silver bullet methodologies go by.
All of them worked for people who had the development experience, business awareness, and common sense to know when to bend the rules or ignore them.
Likewise none of them would take a person incapable of delivering a project and fix that.
"Agile" is a marketing term, and like most marketing terms it's a lie.
Agile works best in those places that left without guidance would try to be too agile for their own good.
The places where management, if you let them, will barge in twice a day with a new direction.
Now if you know developers, you know they have good days and bad days, and if you want to get anything out of them you've got to give them a long enough stretch in one direction so that they can catch the wind in their sails.
So you take down a few books from your shelf, and you say, "This is the latest thing.
It's *agile development*.
"Immediately management gets it.
It's about getting more done faster.
What you don't tell them is that it's about keeping them out of your team's hair long enough to get *anything* done.Now if you can define a good set of requirements and keep the goalposts from moving for longer periods, that's even better.
Thirty days is a reasonable compromise for a sprint.
You want to measure progress in a detailed way at least that often anyway, and it provides ample time to get identifiable bits done and to even try and discard a few creative approaches.
But there's nothing magically necessary about changing priorities every thirty days.
If you can reasonably keep them constant for six months, that'd be even better.
But in *some* kinds of development that's not possible.When you are building software to support business functions, priorities shift based on the response to competition, assumptions in the business plan that don't pan out etc.
Even the software itself changes the requirements environment.
I've been in situations where I know that the organization needs B, but they can't *see* that need until they've seen A first.
So the quintessentially agile part of "agile" is  really indispensable on these kinds of "dynamic requirements" jobs.
The rest of it (unit testing etc.
) is just motherhood and apple pie engineering.Now as far as the game industry is concerned, everything I've heard about it makes it sound like a horror show.
I attribute this to two things.
First it is attractive to young folks enamored of the romance of creating the kind of games they love.
In other words people easy to exploit.
The other factor is bravado and immaturity of the company management.
In time as the people in the industry mature, maybe things will change.
But "methodology" isn't going to solve the problem of self-deluded and exploitative management.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069340</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069640</id>
	<title>Re:Staring blankly</title>
	<author>Anonymous</author>
	<datestamp>1265706660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It's a lot of project management nonsense.  Basically, there are a few different ways to manage a software project.  The idea is that much like building a house, you can assemble the house in many different ways, and some ways will produce a better house in less time.<br> <br>

Personally, I think it's all just a bunch of crap.  Any carpenter will tell you that you should assemble the walls before you put the roof on.  Any programmer will tell you that you need a filesystem driver before you need a resource management system (although there's really no reason that the two can't be done in parallel, if properly planned out).<br> <br>

In short, this topic reminds me of bickering over how whitespace should be formatted.  Completely useless 99\% of the time.<br> <br>

Disclaimer:  I work in the game industry as a systems programmer.  I honestly can't tell you what methodology we use.  Spiral maybe?  Our publisher wants tangible results, and every programmer is given tasks that are within their area of expertise.  We build up our game (which is a constantly shifting target) to the best of our ability.</htmltext>
<tokenext>It 's a lot of project management nonsense .
Basically , there are a few different ways to manage a software project .
The idea is that much like building a house , you can assemble the house in many different ways , and some ways will produce a better house in less time .
Personally , I think it 's all just a bunch of crap .
Any carpenter will tell you that you should assemble the walls before you put the roof on .
Any programmer will tell you that you need a filesystem driver before you need a resource management system ( although there 's really no reason that the two ca n't be done in parallel , if properly planned out ) .
In short , this topic reminds me of bickering over how whitespace should be formatted .
Completely useless 99 \ % of the time .
Disclaimer : I work in the game industry as a systems programmer .
I honestly ca n't tell you what methodology we use .
Spiral maybe ?
Our publisher wants tangible results , and every programmer is given tasks that are within their area of expertise .
We build up our game ( which is a constantly shifting target ) to the best of our ability .</tokentext>
<sentencetext>It's a lot of project management nonsense.
Basically, there are a few different ways to manage a software project.
The idea is that much like building a house, you can assemble the house in many different ways, and some ways will produce a better house in less time.
Personally, I think it's all just a bunch of crap.
Any carpenter will tell you that you should assemble the walls before you put the roof on.
Any programmer will tell you that you need a filesystem driver before you need a resource management system (although there's really no reason that the two can't be done in parallel, if properly planned out).
In short, this topic reminds me of bickering over how whitespace should be formatted.
Completely useless 99\% of the time.
Disclaimer:  I work in the game industry as a systems programmer.
I honestly can't tell you what methodology we use.
Spiral maybe?
Our publisher wants tangible results, and every programmer is given tasks that are within their area of expertise.
We build up our game (which is a constantly shifting target) to the best of our ability.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069584</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070784</id>
	<title>Re:Was it ever Agile?</title>
	<author>Anonymous</author>
	<datestamp>1265723340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I'm glad you pointed out that thing about bug fixes.  We're having that problem right now.  We're expected to fix any and all bugs that appear -as- they appear, but still keep our time-table for the sprint.  The bugs aren't even assigned to us or discussed, we're just supposed to each do a certain number of them.</p><p>I'll have to see if I can't find something online to send in so they'll see how deadly this is to the process.</p></htmltext>
<tokenext>I 'm glad you pointed out that thing about bug fixes .
We 're having that problem right now .
We 're expected to fix any and all bugs that appear -as- they appear , but still keep our time-table for the sprint .
The bugs are n't even assigned to us or discussed , we 're just supposed to each do a certain number of them.I 'll have to see if I ca n't find something online to send in so they 'll see how deadly this is to the process .</tokentext>
<sentencetext>I'm glad you pointed out that thing about bug fixes.
We're having that problem right now.
We're expected to fix any and all bugs that appear -as- they appear, but still keep our time-table for the sprint.
The bugs aren't even assigned to us or discussed, we're just supposed to each do a certain number of them.I'll have to see if I can't find something online to send in so they'll see how deadly this is to the process.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070254</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069744</id>
	<title>Perhaps...</title>
	<author>Anonymous</author>
	<datestamp>1265708640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>...if the programmers started eating less, exercising and losing weight they could be back on the track to being agile?</p></htmltext>
<tokenext>...if the programmers started eating less , exercising and losing weight they could be back on the track to being agile ?</tokentext>
<sentencetext>...if the programmers started eating less, exercising and losing weight they could be back on the track to being agile?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31072050</id>
	<title>Re:Conclusions</title>
	<author>johnlcallaway</author>
	<datestamp>1265731140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Agile programming as been around for decades<nobr> <wbr></nobr>.. someone just wrote a book about it and gave it a name and structure. Which of course, ruined it.</htmltext>
<tokenext>Agile programming as been around for decades .. someone just wrote a book about it and gave it a name and structure .
Which of course , ruined it .</tokentext>
<sentencetext>Agile programming as been around for decades .. someone just wrote a book about it and gave it a name and structure.
Which of course, ruined it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070732</id>
	<title>Re:Oh ... I did not know ...</title>
	<author>vacarul</author>
	<datestamp>1265722800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Project management is done with Excel Sheets, which are mailed around and edited/annotated by multiple persons.</p></div><p>
so true, I worked for a multinational company that used only Excel... for everything. For every type of report, they would send one Excel file to be filled and sent back every week. The receiver would get one file from every person and then compile some mega Excel file report. After a few weeks the mail came back. The Excel template was replaced with a new version so we had to fill in again the information but in the new file. Of course most of the information they requested was useless.<br>
<br>
I had this fantasy in which I would have the power to make Excel disappear and then watch how all the "managers" would run around, hitting their heads because they lost all the reports. <br>
<br>
oh... and their slogan was something about building the internet of tomorrow...</p></div>
	</htmltext>
<tokenext>Project management is done with Excel Sheets , which are mailed around and edited/annotated by multiple persons .
so true , I worked for a multinational company that used only Excel... for everything .
For every type of report , they would send one Excel file to be filled and sent back every week .
The receiver would get one file from every person and then compile some mega Excel file report .
After a few weeks the mail came back .
The Excel template was replaced with a new version so we had to fill in again the information but in the new file .
Of course most of the information they requested was useless .
I had this fantasy in which I would have the power to make Excel disappear and then watch how all the " managers " would run around , hitting their heads because they lost all the reports .
oh... and their slogan was something about building the internet of tomorrow.. .</tokentext>
<sentencetext>Project management is done with Excel Sheets, which are mailed around and edited/annotated by multiple persons.
so true, I worked for a multinational company that used only Excel... for everything.
For every type of report, they would send one Excel file to be filled and sent back every week.
The receiver would get one file from every person and then compile some mega Excel file report.
After a few weeks the mail came back.
The Excel template was replaced with a new version so we had to fill in again the information but in the new file.
Of course most of the information they requested was useless.
I had this fantasy in which I would have the power to make Excel disappear and then watch how all the "managers" would run around, hitting their heads because they lost all the reports.
oh... and their slogan was something about building the internet of tomorrow...
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069712</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069326</id>
	<title>Blame it on the waterfall</title>
	<author>Anonymous</author>
	<datestamp>1265658000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The key to successful development is the "Sally Jesse" method:  Lose the zeroes, hire some heroes.</p></htmltext>
<tokenext>The key to successful development is the " Sally Jesse " method : Lose the zeroes , hire some heroes .</tokentext>
<sentencetext>The key to successful development is the "Sally Jesse" method:  Lose the zeroes, hire some heroes.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069714</id>
	<title>Re:Conclusions</title>
	<author>alberion</author>
	<datestamp>1265708280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Not necessarily,</p><p>  I have been working with Agile software development for 3 years now. Delivering working software every 2 or 3 weeks and never had a single day of delay or extra cost. Got extremely satisfied clients.</p><p>Now, it is not a religion, it is not the only and best way to view software development. It is just one tool every project manager must have in his toolbox.</p><p>Always think, does this software that I am building looks more like a building a bridge or like writing a book?</p><p>If you are building a bridge, please use a process oriented methodology that will get you the correct specs. If you already know exactly what you want, why go for a methodology that is made to coupe with change?</p><p>If you are venturing into the unknown, and nobody has a clear idea of the final software, but has a vague initial definition. Go Agile</p></htmltext>
<tokenext>Not necessarily , I have been working with Agile software development for 3 years now .
Delivering working software every 2 or 3 weeks and never had a single day of delay or extra cost .
Got extremely satisfied clients.Now , it is not a religion , it is not the only and best way to view software development .
It is just one tool every project manager must have in his toolbox.Always think , does this software that I am building looks more like a building a bridge or like writing a book ? If you are building a bridge , please use a process oriented methodology that will get you the correct specs .
If you already know exactly what you want , why go for a methodology that is made to coupe with change ? If you are venturing into the unknown , and nobody has a clear idea of the final software , but has a vague initial definition .
Go Agile</tokentext>
<sentencetext>Not necessarily,  I have been working with Agile software development for 3 years now.
Delivering working software every 2 or 3 weeks and never had a single day of delay or extra cost.
Got extremely satisfied clients.Now, it is not a religion, it is not the only and best way to view software development.
It is just one tool every project manager must have in his toolbox.Always think, does this software that I am building looks more like a building a bridge or like writing a book?If you are building a bridge, please use a process oriented methodology that will get you the correct specs.
If you already know exactly what you want, why go for a methodology that is made to coupe with change?If you are venturing into the unknown, and nobody has a clear idea of the final software, but has a vague initial definition.
Go Agile</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069298</id>
	<title>Frosty Fucking Piss</title>
	<author>Anonymous</author>
	<datestamp>1265657340000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext>Insert Repetitive Slashdot Meme Here.  When It Gets Modded Up To +5 Funny, Pretend Like It Really Was Funny.  Thank You.</htmltext>
<tokenext>Insert Repetitive Slashdot Meme Here .
When It Gets Modded Up To + 5 Funny , Pretend Like It Really Was Funny .
Thank You .</tokentext>
<sentencetext>Insert Repetitive Slashdot Meme Here.
When It Gets Modded Up To +5 Funny, Pretend Like It Really Was Funny.
Thank You.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070144</id>
	<title>I only read the title</title>
	<author>Anonymous</author>
	<datestamp>1265715780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Agile does not seem like a very good choice for game development (with a few exceptions).</p><p>A better methodology for game development would be rapid application development, because:<br>You want to make a model of the system before implementing it.<br>You want to make prototypes.<br>You are not planning on "maintaining" the system for years to come, you want it to be done relatively fast.<br>Almost none of the benefits of agile apply to game development unless its some kind of constantly running, constantly changing MMO.</p><p>Other good methodologies:<br>
&nbsp; * Contract Driven Development<br>
&nbsp; * Model Driven Development</p></htmltext>
<tokenext>Agile does not seem like a very good choice for game development ( with a few exceptions ) .A better methodology for game development would be rapid application development , because : You want to make a model of the system before implementing it.You want to make prototypes.You are not planning on " maintaining " the system for years to come , you want it to be done relatively fast.Almost none of the benefits of agile apply to game development unless its some kind of constantly running , constantly changing MMO.Other good methodologies :   * Contract Driven Development   * Model Driven Development</tokentext>
<sentencetext>Agile does not seem like a very good choice for game development (with a few exceptions).A better methodology for game development would be rapid application development, because:You want to make a model of the system before implementing it.You want to make prototypes.You are not planning on "maintaining" the system for years to come, you want it to be done relatively fast.Almost none of the benefits of agile apply to game development unless its some kind of constantly running, constantly changing MMO.Other good methodologies:
  * Contract Driven Development
  * Model Driven Development</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070166</id>
	<title>process is something to tread carefully with</title>
	<author>jabjoe</author>
	<datestamp>1265716020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I can see some form of structure is useful, but people seem to always get carried away with it, which sets of a cascade of bad things.<br> <br>

Things take longer -&gt; enthusiasm drops away -&gt; it becomes just a job -&gt; people lose interest in talking and reading about the technology -&gt; their learning slows or even stops. <br> <br>

I believe process and structures should be applied very very carefully, and more often than not, sparingly. I believe chaos, common sense and "yeh that works for us" can combine to come up with simple processes and structures that work best. I don't doubt things can be learnt from other processes, but it is a slippery slope to walk on.</htmltext>
<tokenext>I can see some form of structure is useful , but people seem to always get carried away with it , which sets of a cascade of bad things .
Things take longer - &gt; enthusiasm drops away - &gt; it becomes just a job - &gt; people lose interest in talking and reading about the technology - &gt; their learning slows or even stops .
I believe process and structures should be applied very very carefully , and more often than not , sparingly .
I believe chaos , common sense and " yeh that works for us " can combine to come up with simple processes and structures that work best .
I do n't doubt things can be learnt from other processes , but it is a slippery slope to walk on .</tokentext>
<sentencetext>I can see some form of structure is useful, but people seem to always get carried away with it, which sets of a cascade of bad things.
Things take longer -&gt; enthusiasm drops away -&gt; it becomes just a job -&gt; people lose interest in talking and reading about the technology -&gt; their learning slows or even stops.
I believe process and structures should be applied very very carefully, and more often than not, sparingly.
I believe chaos, common sense and "yeh that works for us" can combine to come up with simple processes and structures that work best.
I don't doubt things can be learnt from other processes, but it is a slippery slope to walk on.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31079032</id>
	<title>Re:Conclusions</title>
	<author>Anonymous</author>
	<datestamp>1265714520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I have no mod points, but I would like to comment here so I can bookmark this comment for later. That's a very nice simile that I am going to steal!</p></htmltext>
<tokenext>I have no mod points , but I would like to comment here so I can bookmark this comment for later .
That 's a very nice simile that I am going to steal !</tokentext>
<sentencetext>I have no mod points, but I would like to comment here so I can bookmark this comment for later.
That's a very nice simile that I am going to steal!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069714</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073992</id>
	<title>Post-agile world?  What?</title>
	<author>MobyDisk</author>
	<datestamp>1265738640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Every year at GDC they have more and more Agile workshops.  Seems like every studio I know is using scrum.  I don't see any indication that agile is going away at all.  Certainly there are agile projects that have failed, as have waterfall projects.  But it really sounds like the author had some bad experiences with bad project management, and decided to blame the entire Agile methodology for it.</p><p>From what I've seen, game projects involve milestone deliverables based on the publisher requirements and events like GDC or Leipzeig.  Within those milestone timelines, they use agile methods to adapt to changes and keep on schedule.</p></htmltext>
<tokenext>Every year at GDC they have more and more Agile workshops .
Seems like every studio I know is using scrum .
I do n't see any indication that agile is going away at all .
Certainly there are agile projects that have failed , as have waterfall projects .
But it really sounds like the author had some bad experiences with bad project management , and decided to blame the entire Agile methodology for it.From what I 've seen , game projects involve milestone deliverables based on the publisher requirements and events like GDC or Leipzeig .
Within those milestone timelines , they use agile methods to adapt to changes and keep on schedule .</tokentext>
<sentencetext>Every year at GDC they have more and more Agile workshops.
Seems like every studio I know is using scrum.
I don't see any indication that agile is going away at all.
Certainly there are agile projects that have failed, as have waterfall projects.
But it really sounds like the author had some bad experiences with bad project management, and decided to blame the entire Agile methodology for it.From what I've seen, game projects involve milestone deliverables based on the publisher requirements and events like GDC or Leipzeig.
Within those milestone timelines, they use agile methods to adapt to changes and keep on schedule.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069464</id>
	<title>Any process is better then no process</title>
	<author>LordZardoz</author>
	<datestamp>1265747400000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Game development has lagged terribly behind traditional / non game programming industries in terms of its development practices. And the most recent projects I have worked on were using a Scrum / Agile hybrid. I will admit to not knowing exactly which is which. But the great thing that Agile/Scrum did was to put in place a process where every time someone asked for a feature change, it would be reflected on the development schedule. I have worked on projects where there was at best a vague checklist of what still needed to be done with no info on how long it was expected to take. In my experience, most milestone crunch work is due to people realizing too late that something that should be in the milestone was not going to get done in time.</p><p>The problem with any development practice is that if taken too far, it will cause more problems then it solves. You should not have to write a formal task card up, and put it on the board for trivial tasks. And if you break things down too much, you end up losing sight of the bigger picture.</p><p>I do not care what process you use to get things done. As long as someone on the project (probably the project lead), is keeping track of the following:</p><p>
&nbsp; &nbsp; - Break down the project into smaller tasks: This makes it at least possible to assign responsibility for specific things to specific people.</p><p>
&nbsp; &nbsp; - Task / Feature prioritization: When it comes time to make cuts, knowing what things are important is highly useful.</p><p>
&nbsp; &nbsp; - Task interdependency: You want to schedule your work load to make sure no one gets stuck waiting for something else, and it helps to have a list of alternate tasks you can move onto when you do get road blocked.</p><p>
&nbsp; &nbsp; - Making sure things are done mostly on time: It is never a good thing to only realize that a task is not going to be done on time 2 days before it needs to be done. If something is taking too long, you should know before hand</p><p>
&nbsp; &nbsp; - Making sure new features are checked against the schedule: No one wants to have a project become late because someone decided to add new features half way through the project but did not add time to it.</p><p>If you can track these things intelligently you can avoid the worst bits of milestone specific crunch. No process will prevent a deathmarch, or magically squeeze out an extra 6 months of effective development time. But it will avoid the nastiest surprises, and help create a realistic prediction of what a given development team can produce in a given time frame.</p><p>END COMMUNICATION</p></htmltext>
<tokenext>Game development has lagged terribly behind traditional / non game programming industries in terms of its development practices .
And the most recent projects I have worked on were using a Scrum / Agile hybrid .
I will admit to not knowing exactly which is which .
But the great thing that Agile/Scrum did was to put in place a process where every time someone asked for a feature change , it would be reflected on the development schedule .
I have worked on projects where there was at best a vague checklist of what still needed to be done with no info on how long it was expected to take .
In my experience , most milestone crunch work is due to people realizing too late that something that should be in the milestone was not going to get done in time.The problem with any development practice is that if taken too far , it will cause more problems then it solves .
You should not have to write a formal task card up , and put it on the board for trivial tasks .
And if you break things down too much , you end up losing sight of the bigger picture.I do not care what process you use to get things done .
As long as someone on the project ( probably the project lead ) , is keeping track of the following :     - Break down the project into smaller tasks : This makes it at least possible to assign responsibility for specific things to specific people .
    - Task / Feature prioritization : When it comes time to make cuts , knowing what things are important is highly useful .
    - Task interdependency : You want to schedule your work load to make sure no one gets stuck waiting for something else , and it helps to have a list of alternate tasks you can move onto when you do get road blocked .
    - Making sure things are done mostly on time : It is never a good thing to only realize that a task is not going to be done on time 2 days before it needs to be done .
If something is taking too long , you should know before hand     - Making sure new features are checked against the schedule : No one wants to have a project become late because someone decided to add new features half way through the project but did not add time to it.If you can track these things intelligently you can avoid the worst bits of milestone specific crunch .
No process will prevent a deathmarch , or magically squeeze out an extra 6 months of effective development time .
But it will avoid the nastiest surprises , and help create a realistic prediction of what a given development team can produce in a given time frame.END COMMUNICATION</tokentext>
<sentencetext>Game development has lagged terribly behind traditional / non game programming industries in terms of its development practices.
And the most recent projects I have worked on were using a Scrum / Agile hybrid.
I will admit to not knowing exactly which is which.
But the great thing that Agile/Scrum did was to put in place a process where every time someone asked for a feature change, it would be reflected on the development schedule.
I have worked on projects where there was at best a vague checklist of what still needed to be done with no info on how long it was expected to take.
In my experience, most milestone crunch work is due to people realizing too late that something that should be in the milestone was not going to get done in time.The problem with any development practice is that if taken too far, it will cause more problems then it solves.
You should not have to write a formal task card up, and put it on the board for trivial tasks.
And if you break things down too much, you end up losing sight of the bigger picture.I do not care what process you use to get things done.
As long as someone on the project (probably the project lead), is keeping track of the following:
    - Break down the project into smaller tasks: This makes it at least possible to assign responsibility for specific things to specific people.
    - Task / Feature prioritization: When it comes time to make cuts, knowing what things are important is highly useful.
    - Task interdependency: You want to schedule your work load to make sure no one gets stuck waiting for something else, and it helps to have a list of alternate tasks you can move onto when you do get road blocked.
    - Making sure things are done mostly on time: It is never a good thing to only realize that a task is not going to be done on time 2 days before it needs to be done.
If something is taking too long, you should know before hand
    - Making sure new features are checked against the schedule: No one wants to have a project become late because someone decided to add new features half way through the project but did not add time to it.If you can track these things intelligently you can avoid the worst bits of milestone specific crunch.
No process will prevent a deathmarch, or magically squeeze out an extra 6 months of effective development time.
But it will avoid the nastiest surprises, and help create a realistic prediction of what a given development team can produce in a given time frame.END COMMUNICATION</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31081976</id>
	<title>Fixed price</title>
	<author>mahadiga</author>
	<datestamp>1265735940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I'd recommend Agile to <a href="http://en.wikipedia.org/wiki/Fixed\_price" title="wikipedia.org" rel="nofollow">http://en.wikipedia.org/wiki/Fixed\_price</a> [wikipedia.org] projects.</htmltext>
<tokenext>I 'd recommend Agile to http : //en.wikipedia.org/wiki/Fixed \ _price [ wikipedia.org ] projects .</tokentext>
<sentencetext>I'd recommend Agile to http://en.wikipedia.org/wiki/Fixed\_price [wikipedia.org] projects.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069404</id>
	<title>"Agile" was just a PHB buzzword.</title>
	<author>Anonymous</author>
	<datestamp>1265745840000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><p>[For fun: Read it, as if Ricky Gervais were saying it.*<nobr> <wbr></nobr>;]</p><p>You know when your boss caught on to a new buzzsomething, storms into your room, and wants to play thought-experiments with him on what to change? Restructure the whole company? Because, oh god, it&rsquo;s <em>so</em> great. He just loves it. With glowing eyes..., like a child. And you hate to tell him, that everything he just told you, and everything you have &ldquo;planned&rdquo; in the last 3 hours (of &ldquo;water-cooler talk&rdquo;, mind you)<nobr> <wbr></nobr>...is a steaming pile of bollocks.<nobr> <wbr></nobr>;)</p><p>&ldquo;Agile&rdquo; is such a thing.<br>You know he loves it. But he&rsquo;s got no fuckin&rsquo; clue what he&rsquo;s talking about.<br>&ldquo;Yeah boss. Mmm-hmm. Great idea. Love it.... Say, you <em>did</em> hear that at the golf court, didn&rsquo;t you?&rdquo;</p><p>The thing is... everybody... and I mean every real software developer and project manager... knew that it could. not. work.<br>We were just sitting there, thinking to ourselves: &ldquo;You have finally found something that&rsquo;s even <em>more</em> unrealistic than the &ldquo;plan <em>everything</em>, then GO!&rdquo; waterfall model, haven&rsquo;t you,<nobr> <wbr></nobr>...you little <em>fucker</em>?&rdquo;</p><p>Did you know that the spiral model... was invented over twenty years ago? <em>Yeah</em>. That&rsquo;s how long you and I were sitting there, in our stinky cubicles... printing out everything remotely resembling fliers, and... casually placing them near your boss&rsquo;s room, so he miight pick one up, and you would not have to <em>beat him with that fuckin cluestick in your most beautiful algorithmic fashion, until he looks like a real flame-grilled burger king burger!</em></p><p>(Thankfully, not all of the industry is that bad. Most game development studios, from what I have heard, are actually implementing the spiral model in a very successful way. As am I. But it didn&rsquo;t help you much when you were working at EA now did it?<nobr> <wbr></nobr>;)<br>\_\_\_<br>* Please, if you want to rip me apart for not getting British English right, write me a e-mail in my native language and regional dialect... south-western Luxemburgish. You know, the one with the &ldquo;fro&rdquo;, not the &ldquo;fra&rdquo;.<nobr> <wbr></nobr>;)</p></htmltext>
<tokenext>[ For fun : Read it , as if Ricky Gervais were saying it .
* ; ] You know when your boss caught on to a new buzzsomething , storms into your room , and wants to play thought-experiments with him on what to change ?
Restructure the whole company ?
Because , oh god , it    s so great .
He just loves it .
With glowing eyes... , like a child .
And you hate to tell him , that everything he just told you , and everything you have    planned    in the last 3 hours ( of    water-cooler talk    , mind you ) ...is a steaming pile of bollocks .
; )    Agile    is such a thing.You know he loves it .
But he    s got no fuckin    clue what he    s talking about.    Yeah boss .
Mmm-hmm. Great idea .
Love it.... Say , you did hear that at the golf court , didn    t you ?    The thing is... everybody... and I mean every real software developer and project manager... knew that it could .
not. work.We were just sitting there , thinking to ourselves :    You have finally found something that    s even more unrealistic than the    plan everything , then GO !    waterfall model , haven    t you , ...you little fucker ?    Did you know that the spiral model... was invented over twenty years ago ?
Yeah. That    s how long you and I were sitting there , in our stinky cubicles... printing out everything remotely resembling fliers , and... casually placing them near your boss    s room , so he miight pick one up , and you would not have to beat him with that fuckin cluestick in your most beautiful algorithmic fashion , until he looks like a real flame-grilled burger king burger !
( Thankfully , not all of the industry is that bad .
Most game development studios , from what I have heard , are actually implementing the spiral model in a very successful way .
As am I. But it didn    t help you much when you were working at EA now did it ?
; ) \ _ \ _ \ _ * Please , if you want to rip me apart for not getting British English right , write me a e-mail in my native language and regional dialect... south-western Luxemburgish .
You know , the one with the    fro    , not the    fra    .
; )</tokentext>
<sentencetext>[For fun: Read it, as if Ricky Gervais were saying it.
* ;]You know when your boss caught on to a new buzzsomething, storms into your room, and wants to play thought-experiments with him on what to change?
Restructure the whole company?
Because, oh god, it’s so great.
He just loves it.
With glowing eyes..., like a child.
And you hate to tell him, that everything he just told you, and everything you have “planned” in the last 3 hours (of “water-cooler talk”, mind you) ...is a steaming pile of bollocks.
;)“Agile” is such a thing.You know he loves it.
But he’s got no fuckin’ clue what he’s talking about.“Yeah boss.
Mmm-hmm. Great idea.
Love it.... Say, you did hear that at the golf court, didn’t you?”The thing is... everybody... and I mean every real software developer and project manager... knew that it could.
not. work.We were just sitting there, thinking to ourselves: “You have finally found something that’s even more unrealistic than the “plan everything, then GO!” waterfall model, haven’t you, ...you little fucker?”Did you know that the spiral model... was invented over twenty years ago?
Yeah. That’s how long you and I were sitting there, in our stinky cubicles... printing out everything remotely resembling fliers, and... casually placing them near your boss’s room, so he miight pick one up, and you would not have to beat him with that fuckin cluestick in your most beautiful algorithmic fashion, until he looks like a real flame-grilled burger king burger!
(Thankfully, not all of the industry is that bad.
Most game development studios, from what I have heard, are actually implementing the spiral model in a very successful way.
As am I. But it didn’t help you much when you were working at EA now did it?
;)\_\_\_* Please, if you want to rip me apart for not getting British English right, write me a e-mail in my native language and regional dialect... south-western Luxemburgish.
You know, the one with the “fro”, not the “fra”.
;)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069976</id>
	<title>Zer0 Day gets closer</title>
	<author>Anonymous</author>
	<datestamp>1265712960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Microsoft has published empirical data that shows that the process overhead for TDD increases the development effort by 15\% - 35\%</p></htmltext>
<tokenext>Microsoft has published empirical data that shows that the process overhead for TDD increases the development effort by 15 \ % - 35 \ %</tokentext>
<sentencetext>Microsoft has published empirical data that shows that the process overhead for TDD increases the development effort by 15\% - 35\%</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073022</id>
	<title>Re:When to use "agile" methods.</title>
	<author>elrous0</author>
	<datestamp>1265735340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Sadly my less catchy "Let's just get together and build this motherfucker" design philosophy lacked the one-word or acronym-based approach needed to ever catch on as an industry  buzzword.</htmltext>
<tokenext>Sadly my less catchy " Let 's just get together and build this motherfucker " design philosophy lacked the one-word or acronym-based approach needed to ever catch on as an industry buzzword .</tokentext>
<sentencetext>Sadly my less catchy "Let's just get together and build this motherfucker" design philosophy lacked the one-word or acronym-based approach needed to ever catch on as an industry  buzzword.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070958</id>
	<title>Orientated.</title>
	<author>ericvids</author>
	<datestamp>1265724960000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>I stopped RTFB'ing when I read the word "orientated."</p><p>His choice of words betray his place in the <a href="http://www.askoxford.com/asktheexperts/faq/aboutgrammar/oriented" title="askoxford.com">hifalutin versus technical</a> [askoxford.com] continuum.</p><p>Oh crap I said "continuum", I'm turning into one of them droids!  I'm meltiiiiiiiiiing...</p></htmltext>
<tokenext>I stopped RTFB'ing when I read the word " orientated .
" His choice of words betray his place in the hifalutin versus technical [ askoxford.com ] continuum.Oh crap I said " continuum " , I 'm turning into one of them droids !
I 'm meltiiiiiiiiiing.. .</tokentext>
<sentencetext>I stopped RTFB'ing when I read the word "orientated.
"His choice of words betray his place in the hifalutin versus technical [askoxford.com] continuum.Oh crap I said "continuum", I'm turning into one of them droids!
I'm meltiiiiiiiiiing...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338</id>
	<title>Conclusions</title>
	<author>triorph</author>
	<datestamp>1265658300000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>Is the current conclusion these days that agile doesn't work? Its been what I've always thought but I am wondering whether this article is stating it for a fact when most of the software engineering discipline still believes in it.</htmltext>
<tokenext>Is the current conclusion these days that agile does n't work ?
Its been what I 've always thought but I am wondering whether this article is stating it for a fact when most of the software engineering discipline still believes in it .</tokentext>
<sentencetext>Is the current conclusion these days that agile doesn't work?
Its been what I've always thought but I am wondering whether this article is stating it for a fact when most of the software engineering discipline still believes in it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31071932</id>
	<title>Re:Was it ever Agile?</title>
	<author>Anonymous</author>
	<datestamp>1265730540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Game development is exceptionally prone to Mongolian Clusterfuck methodology.</p></div><p>Most big corporate business software development is exceptionally prone to Mongolian Clusterfuck methodology.<nobr> <wbr></nobr>/big corporate business software developer</p></div>
	</htmltext>
<tokenext>Game development is exceptionally prone to Mongolian Clusterfuck methodology.Most big corporate business software development is exceptionally prone to Mongolian Clusterfuck methodology .
/big corporate business software developer</tokentext>
<sentencetext>Game development is exceptionally prone to Mongolian Clusterfuck methodology.Most big corporate business software development is exceptionally prone to Mongolian Clusterfuck methodology.
/big corporate business software developer
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070254</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070052</id>
	<title>Re:Conclusions</title>
	<author>Angostura</author>
	<datestamp>1265714640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p> I am wondering whether this article is stating it for a fact</p></div></blockquote><p>A question that will be answered if you<nobr> <wbr></nobr>... read the article. Strangely enough the article sets out fairly clearly what the article sets out.</p><p>Madness, I know.</p></div>
	</htmltext>
<tokenext>I am wondering whether this article is stating it for a factA question that will be answered if you ... read the article .
Strangely enough the article sets out fairly clearly what the article sets out.Madness , I know .</tokentext>
<sentencetext> I am wondering whether this article is stating it for a factA question that will be answered if you ... read the article.
Strangely enough the article sets out fairly clearly what the article sets out.Madness, I know.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31072380</id>
	<title>Re:Was it ever Agile?</title>
	<author>fusiongyro</author>
	<datestamp>1265732700000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Everyone who is annoyed at this article seems to be claiming that the author hasn't experienced agile as it should be practiced.</p><p>I have some experience with another methodology, cleanroom software development. The idea behind is, you make a detailed specification, you implement all the code with copious annotations, explaining each line of code. Then you have a big code review, in which each line of code is viewed and the engineers all agree that it correctly implements exactly the specification of the line above it, and that each specification performs part of the overall goal of the program.</p><p>After you do all that, you compile and run the program for the first time, and start counting how many bugs you have.</p><p>The interesting thing is that cleanroom has been proven many times to produce an order of magnitude fewer bugs. Looking at the method, it's hard to imagine how it couldn't. It has a reputation for making the maintenance phase much lighter, because there are so few problems. Yet, when most people hear about the method, their reaction is revulsion at the overhead and the perceived costs (though in practice, it's been shown that the up-front cost may be higher, the overall cost of the project usually is lower.) Why could this be?</p><p>Perhaps these different methods exist because people are different and groups have different priorities. For many people, high turnaround is more important than the lowest bug count, and thus, they choose agile. I tried it and I found it was a poor fit for me. The other partners in my company couldn't stop telling the clients that we used this method, but we never found a client proactive enough to actually make it work. They were shitty clients, sure, but they were the ones we had.</p><p>Agile belongs to the class of things which can be disliked for what it is, even by people who know what it is supposed to be like.</p></htmltext>
<tokenext>Everyone who is annoyed at this article seems to be claiming that the author has n't experienced agile as it should be practiced.I have some experience with another methodology , cleanroom software development .
The idea behind is , you make a detailed specification , you implement all the code with copious annotations , explaining each line of code .
Then you have a big code review , in which each line of code is viewed and the engineers all agree that it correctly implements exactly the specification of the line above it , and that each specification performs part of the overall goal of the program.After you do all that , you compile and run the program for the first time , and start counting how many bugs you have.The interesting thing is that cleanroom has been proven many times to produce an order of magnitude fewer bugs .
Looking at the method , it 's hard to imagine how it could n't .
It has a reputation for making the maintenance phase much lighter , because there are so few problems .
Yet , when most people hear about the method , their reaction is revulsion at the overhead and the perceived costs ( though in practice , it 's been shown that the up-front cost may be higher , the overall cost of the project usually is lower .
) Why could this be ? Perhaps these different methods exist because people are different and groups have different priorities .
For many people , high turnaround is more important than the lowest bug count , and thus , they choose agile .
I tried it and I found it was a poor fit for me .
The other partners in my company could n't stop telling the clients that we used this method , but we never found a client proactive enough to actually make it work .
They were shitty clients , sure , but they were the ones we had.Agile belongs to the class of things which can be disliked for what it is , even by people who know what it is supposed to be like .</tokentext>
<sentencetext>Everyone who is annoyed at this article seems to be claiming that the author hasn't experienced agile as it should be practiced.I have some experience with another methodology, cleanroom software development.
The idea behind is, you make a detailed specification, you implement all the code with copious annotations, explaining each line of code.
Then you have a big code review, in which each line of code is viewed and the engineers all agree that it correctly implements exactly the specification of the line above it, and that each specification performs part of the overall goal of the program.After you do all that, you compile and run the program for the first time, and start counting how many bugs you have.The interesting thing is that cleanroom has been proven many times to produce an order of magnitude fewer bugs.
Looking at the method, it's hard to imagine how it couldn't.
It has a reputation for making the maintenance phase much lighter, because there are so few problems.
Yet, when most people hear about the method, their reaction is revulsion at the overhead and the perceived costs (though in practice, it's been shown that the up-front cost may be higher, the overall cost of the project usually is lower.
) Why could this be?Perhaps these different methods exist because people are different and groups have different priorities.
For many people, high turnaround is more important than the lowest bug count, and thus, they choose agile.
I tried it and I found it was a poor fit for me.
The other partners in my company couldn't stop telling the clients that we used this method, but we never found a client proactive enough to actually make it work.
They were shitty clients, sure, but they were the ones we had.Agile belongs to the class of things which can be disliked for what it is, even by people who know what it is supposed to be like.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070254</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070178</id>
	<title>Re:I am a game developer.</title>
	<author>Tim C</author>
	<datestamp>1265716260000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p><i>Do people in management at large corporations actually talk like this?</i></p><p>No, the programmers do.</p><p>Agile is all about breaking the project down into small, more-or-less self-contained (sets of) features, and getting the users involved in the process. The aim is the same, to go from a set of requirements to a finished product, but it's supposed to be more flexible, more able to cope with changes along the way, etc (hence, "agile").</p><p>It differs from the traditional waterfall method in that it allows for coding of one (set of) requirement(s) to start, while the next set is being specced out; it also allows (in fact, requires) that testing of the last set of delivered functionality is performed while the current set is being developed. Thus it runs several separate workstreams in parallel. If that testing reveals any bugs that need to be fixed now, then the fixes can be worked into the next sprint as required (which yes, may well push features out, either to a later date or completely out of the project).</p><p>Agile suits some projects better than others, some customers better than others, and some project teams better than others. When it works well, it can work really well; similarly when it's poorly managed or people have unrealistic expectations, it can crash and burn like any other method. (And similarly, of course, other methods of running software projects can work very well too - use the right tool for the right job...)</p></htmltext>
<tokenext>Do people in management at large corporations actually talk like this ? No , the programmers do.Agile is all about breaking the project down into small , more-or-less self-contained ( sets of ) features , and getting the users involved in the process .
The aim is the same , to go from a set of requirements to a finished product , but it 's supposed to be more flexible , more able to cope with changes along the way , etc ( hence , " agile " ) .It differs from the traditional waterfall method in that it allows for coding of one ( set of ) requirement ( s ) to start , while the next set is being specced out ; it also allows ( in fact , requires ) that testing of the last set of delivered functionality is performed while the current set is being developed .
Thus it runs several separate workstreams in parallel .
If that testing reveals any bugs that need to be fixed now , then the fixes can be worked into the next sprint as required ( which yes , may well push features out , either to a later date or completely out of the project ) .Agile suits some projects better than others , some customers better than others , and some project teams better than others .
When it works well , it can work really well ; similarly when it 's poorly managed or people have unrealistic expectations , it can crash and burn like any other method .
( And similarly , of course , other methods of running software projects can work very well too - use the right tool for the right job... )</tokentext>
<sentencetext>Do people in management at large corporations actually talk like this?No, the programmers do.Agile is all about breaking the project down into small, more-or-less self-contained (sets of) features, and getting the users involved in the process.
The aim is the same, to go from a set of requirements to a finished product, but it's supposed to be more flexible, more able to cope with changes along the way, etc (hence, "agile").It differs from the traditional waterfall method in that it allows for coding of one (set of) requirement(s) to start, while the next set is being specced out; it also allows (in fact, requires) that testing of the last set of delivered functionality is performed while the current set is being developed.
Thus it runs several separate workstreams in parallel.
If that testing reveals any bugs that need to be fixed now, then the fixes can be worked into the next sprint as required (which yes, may well push features out, either to a later date or completely out of the project).Agile suits some projects better than others, some customers better than others, and some project teams better than others.
When it works well, it can work really well; similarly when it's poorly managed or people have unrealistic expectations, it can crash and burn like any other method.
(And similarly, of course, other methods of running software projects can work very well too - use the right tool for the right job...)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069488</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31071152</id>
	<title>Re:When to use "agile" methods.</title>
	<author>Anonymous</author>
	<datestamp>1265726160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Big-budget moviemaking today involves going from script to storyboard to previsualization (making a low-end animated version as a planning tool) to production. That's very much a waterfall process.</p></div><p> It may start as something resembling to a waterfall just like formulation of a request of proposal for a software project might look, but turns quickly into an agile process as the movie gets its final look. The all digital production enables even more liberty by spreading the agile part of the movie making all the way to the storyboarding and concept development levels. This way the production process increasingly supports the act of story telling which the movie making should be all about.</p></div>
	</htmltext>
<tokenext>Big-budget moviemaking today involves going from script to storyboard to previsualization ( making a low-end animated version as a planning tool ) to production .
That 's very much a waterfall process .
It may start as something resembling to a waterfall just like formulation of a request of proposal for a software project might look , but turns quickly into an agile process as the movie gets its final look .
The all digital production enables even more liberty by spreading the agile part of the movie making all the way to the storyboarding and concept development levels .
This way the production process increasingly supports the act of story telling which the movie making should be all about .</tokentext>
<sentencetext>Big-budget moviemaking today involves going from script to storyboard to previsualization (making a low-end animated version as a planning tool) to production.
That's very much a waterfall process.
It may start as something resembling to a waterfall just like formulation of a request of proposal for a software project might look, but turns quickly into an agile process as the movie gets its final look.
The all digital production enables even more liberty by spreading the agile part of the movie making all the way to the storyboarding and concept development levels.
This way the production process increasingly supports the act of story telling which the movie making should be all about.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31086304</id>
	<title>Re:Not sure how Agile helps game development</title>
	<author>ukyoCE</author>
	<datestamp>1265042640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Iterative style development? Maybe that might work for an MMO where the customers don't mind being permanent beta testers.</p></div><p>MMOs are definitely a strong case for Agile.  MMO worlds and features are always evolving.  You can't waterfall a feature for a year, toss it out the door, and then ignore it when it's a flop with the users.</p><p>Using an agile methodology doesn't mean your end-users are beta testers either.  The point isn't to implement broken features and test+fix them later, it's to add and improve working features in a timely fashion.  If a feature isn't ready for the deadline, you drop that feature and go ahead with your deadline.</p><p>MMO development is a lot like website development.  Your users need to see continued improvement to stay interested, and to keep your product comparable to the competition.  And you're getting continuous feedback from the end users on what they like and don't like, and can do something about it quickly in the next release.  With a single-launch product you're stuck with focus groups and testers, crossing your fingers that the real world bears out their feedback.</p></div>
	</htmltext>
<tokenext>Iterative style development ?
Maybe that might work for an MMO where the customers do n't mind being permanent beta testers.MMOs are definitely a strong case for Agile .
MMO worlds and features are always evolving .
You ca n't waterfall a feature for a year , toss it out the door , and then ignore it when it 's a flop with the users.Using an agile methodology does n't mean your end-users are beta testers either .
The point is n't to implement broken features and test + fix them later , it 's to add and improve working features in a timely fashion .
If a feature is n't ready for the deadline , you drop that feature and go ahead with your deadline.MMO development is a lot like website development .
Your users need to see continued improvement to stay interested , and to keep your product comparable to the competition .
And you 're getting continuous feedback from the end users on what they like and do n't like , and can do something about it quickly in the next release .
With a single-launch product you 're stuck with focus groups and testers , crossing your fingers that the real world bears out their feedback .</tokentext>
<sentencetext>Iterative style development?
Maybe that might work for an MMO where the customers don't mind being permanent beta testers.MMOs are definitely a strong case for Agile.
MMO worlds and features are always evolving.
You can't waterfall a feature for a year, toss it out the door, and then ignore it when it's a flop with the users.Using an agile methodology doesn't mean your end-users are beta testers either.
The point isn't to implement broken features and test+fix them later, it's to add and improve working features in a timely fashion.
If a feature isn't ready for the deadline, you drop that feature and go ahead with your deadline.MMO development is a lot like website development.
Your users need to see continued improvement to stay interested, and to keep your product comparable to the competition.
And you're getting continuous feedback from the end users on what they like and don't like, and can do something about it quickly in the next release.
With a single-launch product you're stuck with focus groups and testers, crossing your fingers that the real world bears out their feedback.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069340</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31074604</id>
	<title>Agile clearly means something else than I thought</title>
	<author>tsa</author>
	<datestamp>1265741040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>How cool is that: a whole article of which I didn't understand one word because I thought it was about making games for people who are not so agile anymore as they used to be, so they need games that rely on wit and intelligence rather than fast reactions.</p></htmltext>
<tokenext>How cool is that : a whole article of which I did n't understand one word because I thought it was about making games for people who are not so agile anymore as they used to be , so they need games that rely on wit and intelligence rather than fast reactions .</tokentext>
<sentencetext>How cool is that: a whole article of which I didn't understand one word because I thought it was about making games for people who are not so agile anymore as they used to be, so they need games that rely on wit and intelligence rather than fast reactions.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31071634</id>
	<title>Re:When to use "agile" methods.</title>
	<author>b4dc0d3r</author>
	<datestamp>1265728680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Since you're going all general on us... A company I worked for used to tell its customers it was an "Agile" company.  It announced "Agility Alliance" partners intended to speed time to market, and develop solutions quickly.</p><p>Internally, a new development process was rolled out that everyone had to follow.  It was classic Waterfall with everything renamed.  Then they addressed the shortcomings of Waterfall by adding additional planning, documentation, gate reviews, and I forgot what else.</p><p>We're agile, and we just changed our development model to prove it.  Yay!</p><p>*sigh*</p></htmltext>
<tokenext>Since you 're going all general on us... A company I worked for used to tell its customers it was an " Agile " company .
It announced " Agility Alliance " partners intended to speed time to market , and develop solutions quickly.Internally , a new development process was rolled out that everyone had to follow .
It was classic Waterfall with everything renamed .
Then they addressed the shortcomings of Waterfall by adding additional planning , documentation , gate reviews , and I forgot what else.We 're agile , and we just changed our development model to prove it .
Yay ! * sigh *</tokentext>
<sentencetext>Since you're going all general on us... A company I worked for used to tell its customers it was an "Agile" company.
It announced "Agility Alliance" partners intended to speed time to market, and develop solutions quickly.Internally, a new development process was rolled out that everyone had to follow.
It was classic Waterfall with everything renamed.
Then they addressed the shortcomings of Waterfall by adding additional planning, documentation, gate reviews, and I forgot what else.We're agile, and we just changed our development model to prove it.
Yay!*sigh*</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069656</id>
	<title>Re:Staring blankly</title>
	<author>trapnest</author>
	<datestamp>1265707020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I am with this guy. Are you people even speaking english?</htmltext>
<tokenext>I am with this guy .
Are you people even speaking english ?</tokentext>
<sentencetext>I am with this guy.
Are you people even speaking english?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069584</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070316</id>
	<title>Re:"Agile" was just a PHB buzzword.</title>
	<author>goose-incarnated</author>
	<datestamp>1265717880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Golf Court?
<br> <br>
(Maybe he heard it at the squash course?)</htmltext>
<tokenext>Golf Court ?
( Maybe he heard it at the squash course ?
)</tokentext>
<sentencetext>Golf Court?
(Maybe he heard it at the squash course?
)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069404</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069822</id>
	<title>Re:Agile is dead?</title>
	<author>Anonymous</author>
	<datestamp>1265710380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Where in the summary or article does it say dead?</p></htmltext>
<tokenext>Where in the summary or article does it say dead ?</tokentext>
<sentencetext>Where in the summary or article does it say dead?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069530</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073814</id>
	<title>Re:When to use "agile" methods.</title>
	<author>recharged95</author>
	<datestamp>1265737980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>"<i>Or, in fact, much programming which involves using an existing "framework". </i>"
<br>
<br>
<br>
Ding ding. If you are using a existing framework, then getting 'experienced' folks (intelligent is subjective and misleading) will have the domain knowledge, hence design is a lower priority from requirements/user stories. And then an Agile process used as a guideline will work out fine as along as management does the due-diligence in planning and getting clear test/success cases from the dev teams.
<br>
<br>
Of course all that can easily fall apart if the stakeholders don't want to spend the time (a lot of their time that is)... And chances are they don't want to spend the time in planning meetings and scrums.</htmltext>
<tokenext>" Or , in fact , much programming which involves using an existing " framework " .
" Ding ding .
If you are using a existing framework , then getting 'experienced ' folks ( intelligent is subjective and misleading ) will have the domain knowledge , hence design is a lower priority from requirements/user stories .
And then an Agile process used as a guideline will work out fine as along as management does the due-diligence in planning and getting clear test/success cases from the dev teams .
Of course all that can easily fall apart if the stakeholders do n't want to spend the time ( a lot of their time that is ) ... And chances are they do n't want to spend the time in planning meetings and scrums .</tokentext>
<sentencetext>"Or, in fact, much programming which involves using an existing "framework".
"



Ding ding.
If you are using a existing framework, then getting 'experienced' folks (intelligent is subjective and misleading) will have the domain knowledge, hence design is a lower priority from requirements/user stories.
And then an Agile process used as a guideline will work out fine as along as management does the due-diligence in planning and getting clear test/success cases from the dev teams.
Of course all that can easily fall apart if the stakeholders don't want to spend the time (a lot of their time that is)... And chances are they don't want to spend the time in planning meetings and scrums.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31071842</id>
	<title>Excellent article against Agile</title>
	<author>Anonymous</author>
	<datestamp>1265730000000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p><a href="http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile\_27.html" title="blogspot.com">Good Agile, Bad Agile</a> [blogspot.com] by Steve Yegge at Google is an excellent article on the pros and (mostly) cons of Agile development.</p><p>Personally my single biggest problem with Agile is that it specifically de-emphases code ownership (mental ownership, not economic).  In my experience as a developer, the only way you get people to go the extra mile on a project (working nights, weekends, whenever and whatever it takes) is when they feel like that code is <i>theirs</i>.</p><p>The other big problem I have is that whenever I see someone talking about Agile development it always feels like they're trying to sell me Amway products.  It has the same, almost proselytizing tone that a Born-Again preacher takes when they're holding out the money-jar.</p></htmltext>
<tokenext>Good Agile , Bad Agile [ blogspot.com ] by Steve Yegge at Google is an excellent article on the pros and ( mostly ) cons of Agile development.Personally my single biggest problem with Agile is that it specifically de-emphases code ownership ( mental ownership , not economic ) .
In my experience as a developer , the only way you get people to go the extra mile on a project ( working nights , weekends , whenever and whatever it takes ) is when they feel like that code is theirs.The other big problem I have is that whenever I see someone talking about Agile development it always feels like they 're trying to sell me Amway products .
It has the same , almost proselytizing tone that a Born-Again preacher takes when they 're holding out the money-jar .</tokentext>
<sentencetext>Good Agile, Bad Agile [blogspot.com] by Steve Yegge at Google is an excellent article on the pros and (mostly) cons of Agile development.Personally my single biggest problem with Agile is that it specifically de-emphases code ownership (mental ownership, not economic).
In my experience as a developer, the only way you get people to go the extra mile on a project (working nights, weekends, whenever and whatever it takes) is when they feel like that code is theirs.The other big problem I have is that whenever I see someone talking about Agile development it always feels like they're trying to sell me Amway products.
It has the same, almost proselytizing tone that a Born-Again preacher takes when they're holding out the money-jar.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448</id>
	<title>When to use "agile" methods.</title>
	<author>Animats</author>
	<datestamp>1265746980000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>
"Agile" methodologies are most appropriate when the project consists of a large number of loosely coupled user-oriented features with no major architectural or technical innovations.  Like PHP-based web sites.  Or, in fact, much programming which involves using an existing "framework".   Someone else has already figured out what the different parts of the system need to say to each other and roughly how they will say it.  Development is mostly filling in the blanks.
</p><p>
Trying to use "agile" on a hard, tightly-coupled problem with no predefined structural framework, like an optimizing compiler or a database engine, is likely to result in a disaster.
</p><p>
A game can fall into either category.  If the game requires new technology, especially something hard, (advanced AI, a new physics engine, a very large seamless world, etc.) a very front-end design-driven approach may be necessary.  On the other hand, if most of the game consists of developing content for different areas of the game world, an
"agile" methodology could work fine.   Second Life is probably the most extreme example of this.
</p><p>
It's interesting to note that movie-making has become very much a waterfall model business.  A few decades ago, moviemaking was much more "agile", and most directors came from a theatrical background.  For a theatrical director, there's a debugging phase involving actors on a bare stage, and the content may change considerably during development.  Big-budget moviemaking today involves going from script to storyboard to previsualization (making a low-end animated version as a planning tool) to production.  That's very much a waterfall process.</p></htmltext>
<tokenext>" Agile " methodologies are most appropriate when the project consists of a large number of loosely coupled user-oriented features with no major architectural or technical innovations .
Like PHP-based web sites .
Or , in fact , much programming which involves using an existing " framework " .
Someone else has already figured out what the different parts of the system need to say to each other and roughly how they will say it .
Development is mostly filling in the blanks .
Trying to use " agile " on a hard , tightly-coupled problem with no predefined structural framework , like an optimizing compiler or a database engine , is likely to result in a disaster .
A game can fall into either category .
If the game requires new technology , especially something hard , ( advanced AI , a new physics engine , a very large seamless world , etc .
) a very front-end design-driven approach may be necessary .
On the other hand , if most of the game consists of developing content for different areas of the game world , an " agile " methodology could work fine .
Second Life is probably the most extreme example of this .
It 's interesting to note that movie-making has become very much a waterfall model business .
A few decades ago , moviemaking was much more " agile " , and most directors came from a theatrical background .
For a theatrical director , there 's a debugging phase involving actors on a bare stage , and the content may change considerably during development .
Big-budget moviemaking today involves going from script to storyboard to previsualization ( making a low-end animated version as a planning tool ) to production .
That 's very much a waterfall process .</tokentext>
<sentencetext>
"Agile" methodologies are most appropriate when the project consists of a large number of loosely coupled user-oriented features with no major architectural or technical innovations.
Like PHP-based web sites.
Or, in fact, much programming which involves using an existing "framework".
Someone else has already figured out what the different parts of the system need to say to each other and roughly how they will say it.
Development is mostly filling in the blanks.
Trying to use "agile" on a hard, tightly-coupled problem with no predefined structural framework, like an optimizing compiler or a database engine, is likely to result in a disaster.
A game can fall into either category.
If the game requires new technology, especially something hard, (advanced AI, a new physics engine, a very large seamless world, etc.
) a very front-end design-driven approach may be necessary.
On the other hand, if most of the game consists of developing content for different areas of the game world, an
"agile" methodology could work fine.
Second Life is probably the most extreme example of this.
It's interesting to note that movie-making has become very much a waterfall model business.
A few decades ago, moviemaking was much more "agile", and most directors came from a theatrical background.
For a theatrical director, there's a debugging phase involving actors on a bare stage, and the content may change considerably during development.
Big-budget moviemaking today involves going from script to storyboard to previsualization (making a low-end animated version as a planning tool) to production.
That's very much a waterfall process.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069982</id>
	<title>Re:When to use "agile" methods.</title>
	<author>Anonymous</author>
	<datestamp>1265713140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>PostgreSQL *is* a database engine, and successfully runs with something pretty close to Agile methodology. New features are fairly small-grained, and are released to the test community fairly frequently. Feedback on the design and implementation then affects development on that feature (including possibly dropping it).</p><p>The Linux kernel development process is also similar to Agile methodology, and seems to work fairly well, despite regularly having major architectural or technical innovations.</p><p>Where these projects differ from games, however, is that there are no deadlines as there are no marketing people waiting for the next release. In addition, each new feature is useful independently while a game may be unplayable unless a set of features are all functioning together. Movies have a similar issue: time-based releases aren't an option; a film without scenes 4, 7, 84 and 103 just isn't watchable.</p></htmltext>
<tokenext>PostgreSQL * is * a database engine , and successfully runs with something pretty close to Agile methodology .
New features are fairly small-grained , and are released to the test community fairly frequently .
Feedback on the design and implementation then affects development on that feature ( including possibly dropping it ) .The Linux kernel development process is also similar to Agile methodology , and seems to work fairly well , despite regularly having major architectural or technical innovations.Where these projects differ from games , however , is that there are no deadlines as there are no marketing people waiting for the next release .
In addition , each new feature is useful independently while a game may be unplayable unless a set of features are all functioning together .
Movies have a similar issue : time-based releases are n't an option ; a film without scenes 4 , 7 , 84 and 103 just is n't watchable .</tokentext>
<sentencetext>PostgreSQL *is* a database engine, and successfully runs with something pretty close to Agile methodology.
New features are fairly small-grained, and are released to the test community fairly frequently.
Feedback on the design and implementation then affects development on that feature (including possibly dropping it).The Linux kernel development process is also similar to Agile methodology, and seems to work fairly well, despite regularly having major architectural or technical innovations.Where these projects differ from games, however, is that there are no deadlines as there are no marketing people waiting for the next release.
In addition, each new feature is useful independently while a game may be unplayable unless a set of features are all functioning together.
Movies have a similar issue: time-based releases aren't an option; a film without scenes 4, 7, 84 and 103 just isn't watchable.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070400</id>
	<title>Re:When to use "agile" methods.</title>
	<author>eulernet</author>
	<datestamp>1265719140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>It's interesting to note that movie-making has become very much a waterfall model business.  A few decades ago, moviemaking was much more "agile", and most directors came from a theatrical background.  For a theatrical director, there's a debugging phase involving actors on a bare stage, and the content may change considerably during development.  Big-budget moviemaking today involves going from script to storyboard to previsualization (making a low-end animated version as a planning tool) to production.  That's very much a waterfall process.</p></div><p>Yes, you are right.<br>When a sector becomes mature, a process can be defined.<br>But this is because making a movie is very expensive, and much more than creating a video game.<br>On the very few games costing more than 10 millions, there is a lot of procedures.</p><p><div class="quote"><p>"Agile" methodologies are most appropriate when the project consists of a large number of loosely coupled user-oriented features with no major architectural or technical innovations.  Like PHP-based web sites.  Or, in fact, much programming which involves using an existing "framework".   Someone else has already figured out what the different parts of the system need to say to each other and roughly how they will say it.  Development is mostly filling in the blanks.</p></div><p>Hum, as an ex-game programmer and a current agile developer, I have to say that you are wrong.</p><p>Writing a game now requires using lots of frameworks (3D engine, controller input, and in some cases AI).</p><p>Using frameworks has nothing to do with agile programming. Note also that programming nowadays has become like playing with Legos: you use the pieces that you bought, and you never build your own pieces.</p><p>As the article states, <b>using agile will slow down your progress by at least 15\%</b>, but you'll have an average of <b>60\% less bugs</b> (quality might not be an important factor in a game).</p><p>Although I use agile methodologies, I know that some of them don't work with everybody.<br><b>Pair programming is the typical example that won't work in game programming</b>.<br>Why ? Simply because you cannot afford to write every line of code by two programmers when you write a game.</p><p>What works in agile are:</p><p>1) <b>TDD</b> (test-driven development): writing tests before or at least covering your code with tests.<br>2) <b>Tasks splitting</b>: split your project in small tasks, and define what you expect from every task (we use cards for that).<br>3) <b>Pair committing</b>: every commit must be reviewed by two programmers. This reduces the obvious bugs.<br>4) <b>Minimal effort</b>: always write the smallest amount of code to write a task. Don't start building a skyscraper when you need a home.<br>5) <b>Daily standup meeting</b>: all the team stand up and talk about their progress during one minute per person<br>6) <b>Iterative process</b>: define small 'milestones' named iterations, for example every two weeks. At the beginning of the iteration, you define what tasks you want to be done. At the end, you check what has been done.<br>7) <b>Continuous integration</b>: when you commit, a build is launched and the tests are executed. If you break the build, you fix it immediately.<br>8) <b>Retrospective</b>: at the end of every iteration, take some hours (one hour per week is enough) to analyze what went right and what went wrong. It's like a post-mortem (check Gamasutra's post-mortems), and allows you to better react when there are problems.</p><p><b>As agile processes are people-centric, every team should have its own rules.</b></p></div>
	</htmltext>
<tokenext>It 's interesting to note that movie-making has become very much a waterfall model business .
A few decades ago , moviemaking was much more " agile " , and most directors came from a theatrical background .
For a theatrical director , there 's a debugging phase involving actors on a bare stage , and the content may change considerably during development .
Big-budget moviemaking today involves going from script to storyboard to previsualization ( making a low-end animated version as a planning tool ) to production .
That 's very much a waterfall process.Yes , you are right.When a sector becomes mature , a process can be defined.But this is because making a movie is very expensive , and much more than creating a video game.On the very few games costing more than 10 millions , there is a lot of procedures .
" Agile " methodologies are most appropriate when the project consists of a large number of loosely coupled user-oriented features with no major architectural or technical innovations .
Like PHP-based web sites .
Or , in fact , much programming which involves using an existing " framework " .
Someone else has already figured out what the different parts of the system need to say to each other and roughly how they will say it .
Development is mostly filling in the blanks.Hum , as an ex-game programmer and a current agile developer , I have to say that you are wrong.Writing a game now requires using lots of frameworks ( 3D engine , controller input , and in some cases AI ) .Using frameworks has nothing to do with agile programming .
Note also that programming nowadays has become like playing with Legos : you use the pieces that you bought , and you never build your own pieces.As the article states , using agile will slow down your progress by at least 15 \ % , but you 'll have an average of 60 \ % less bugs ( quality might not be an important factor in a game ) .Although I use agile methodologies , I know that some of them do n't work with everybody.Pair programming is the typical example that wo n't work in game programming.Why ?
Simply because you can not afford to write every line of code by two programmers when you write a game.What works in agile are : 1 ) TDD ( test-driven development ) : writing tests before or at least covering your code with tests.2 ) Tasks splitting : split your project in small tasks , and define what you expect from every task ( we use cards for that ) .3 ) Pair committing : every commit must be reviewed by two programmers .
This reduces the obvious bugs.4 ) Minimal effort : always write the smallest amount of code to write a task .
Do n't start building a skyscraper when you need a home.5 ) Daily standup meeting : all the team stand up and talk about their progress during one minute per person6 ) Iterative process : define small 'milestones ' named iterations , for example every two weeks .
At the beginning of the iteration , you define what tasks you want to be done .
At the end , you check what has been done.7 ) Continuous integration : when you commit , a build is launched and the tests are executed .
If you break the build , you fix it immediately.8 ) Retrospective : at the end of every iteration , take some hours ( one hour per week is enough ) to analyze what went right and what went wrong .
It 's like a post-mortem ( check Gamasutra 's post-mortems ) , and allows you to better react when there are problems.As agile processes are people-centric , every team should have its own rules .</tokentext>
<sentencetext>It's interesting to note that movie-making has become very much a waterfall model business.
A few decades ago, moviemaking was much more "agile", and most directors came from a theatrical background.
For a theatrical director, there's a debugging phase involving actors on a bare stage, and the content may change considerably during development.
Big-budget moviemaking today involves going from script to storyboard to previsualization (making a low-end animated version as a planning tool) to production.
That's very much a waterfall process.Yes, you are right.When a sector becomes mature, a process can be defined.But this is because making a movie is very expensive, and much more than creating a video game.On the very few games costing more than 10 millions, there is a lot of procedures.
"Agile" methodologies are most appropriate when the project consists of a large number of loosely coupled user-oriented features with no major architectural or technical innovations.
Like PHP-based web sites.
Or, in fact, much programming which involves using an existing "framework".
Someone else has already figured out what the different parts of the system need to say to each other and roughly how they will say it.
Development is mostly filling in the blanks.Hum, as an ex-game programmer and a current agile developer, I have to say that you are wrong.Writing a game now requires using lots of frameworks (3D engine, controller input, and in some cases AI).Using frameworks has nothing to do with agile programming.
Note also that programming nowadays has become like playing with Legos: you use the pieces that you bought, and you never build your own pieces.As the article states, using agile will slow down your progress by at least 15\%, but you'll have an average of 60\% less bugs (quality might not be an important factor in a game).Although I use agile methodologies, I know that some of them don't work with everybody.Pair programming is the typical example that won't work in game programming.Why ?
Simply because you cannot afford to write every line of code by two programmers when you write a game.What works in agile are:1) TDD (test-driven development): writing tests before or at least covering your code with tests.2) Tasks splitting: split your project in small tasks, and define what you expect from every task (we use cards for that).3) Pair committing: every commit must be reviewed by two programmers.
This reduces the obvious bugs.4) Minimal effort: always write the smallest amount of code to write a task.
Don't start building a skyscraper when you need a home.5) Daily standup meeting: all the team stand up and talk about their progress during one minute per person6) Iterative process: define small 'milestones' named iterations, for example every two weeks.
At the beginning of the iteration, you define what tasks you want to be done.
At the end, you check what has been done.7) Continuous integration: when you commit, a build is launched and the tests are executed.
If you break the build, you fix it immediately.8) Retrospective: at the end of every iteration, take some hours (one hour per week is enough) to analyze what went right and what went wrong.
It's like a post-mortem (check Gamasutra's post-mortems), and allows you to better react when there are problems.As agile processes are people-centric, every team should have its own rules.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069540</id>
	<title>Too long</title>
	<author>istartedi</author>
	<datestamp>1265748660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Did TFA have "Mary had a little lamb" in the middle of it?
Nobody knows, and nobody ever will.  Bonus points for unfalsifiable assertions
in the first paragraph.</p></htmltext>
<tokenext>Did TFA have " Mary had a little lamb " in the middle of it ?
Nobody knows , and nobody ever will .
Bonus points for unfalsifiable assertions in the first paragraph .</tokentext>
<sentencetext>Did TFA have "Mary had a little lamb" in the middle of it?
Nobody knows, and nobody ever will.
Bonus points for unfalsifiable assertions
in the first paragraph.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069676</id>
	<title>Re:Conclusions</title>
	<author>91degrees</author>
	<datestamp>1265707500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Well, most of the games industry is in love with Scrum.  I have met Gwaredd though.  He's one of the few people I've met who actually knows about design methdologies.</htmltext>
<tokenext>Well , most of the games industry is in love with Scrum .
I have met Gwaredd though .
He 's one of the few people I 've met who actually knows about design methdologies .</tokentext>
<sentencetext>Well, most of the games industry is in love with Scrum.
I have met Gwaredd though.
He's one of the few people I've met who actually knows about design methdologies.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069354</id>
	<title>Great article.</title>
	<author>Anonymous</author>
	<datestamp>1265658540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Funny name. Smart guy.</htmltext>
<tokenext>Funny name .
Smart guy .</tokentext>
<sentencetext>Funny name.
Smart guy.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070004</id>
	<title>Re:When to use "agile" methods.</title>
	<author>Anonymous</author>
	<datestamp>1265713620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I don't know what your experience is that led you to say that moviemaking has become more waterfall, but my sources in the industry, who have been in the industry a little over ten years, describe precisely the opposite of what you're describing.  Ten years ago, there was reasonable art direction, a reasonable process, and the hope that a quality shot would at some point be called "done" so they could move on.  Today, even though the script-&gt;storyboard-&gt;previz-&gt;production process provides more structure, the actual process of a moviemaker's development is much more like iterative prototyping than it is a waterfall. The increased flexibility of computer graphics has led directors to expect they can make changes at any point in the process and use CG to fix it up - everything from little things like not reshooting bad footage to completely reworking the ending of a movie or changing its plotline - all of things which have happened to my sources, particularly on "I Am Legend," where massive changes had to be made the further and further they went in the moviemaking - and this is with a lot of it plotted out and prevized.</p><p>Your mileage may vary - if you have a really good director, this does not apply.</p></htmltext>
<tokenext>I do n't know what your experience is that led you to say that moviemaking has become more waterfall , but my sources in the industry , who have been in the industry a little over ten years , describe precisely the opposite of what you 're describing .
Ten years ago , there was reasonable art direction , a reasonable process , and the hope that a quality shot would at some point be called " done " so they could move on .
Today , even though the script- &gt; storyboard- &gt; previz- &gt; production process provides more structure , the actual process of a moviemaker 's development is much more like iterative prototyping than it is a waterfall .
The increased flexibility of computer graphics has led directors to expect they can make changes at any point in the process and use CG to fix it up - everything from little things like not reshooting bad footage to completely reworking the ending of a movie or changing its plotline - all of things which have happened to my sources , particularly on " I Am Legend , " where massive changes had to be made the further and further they went in the moviemaking - and this is with a lot of it plotted out and prevized.Your mileage may vary - if you have a really good director , this does not apply .</tokentext>
<sentencetext>I don't know what your experience is that led you to say that moviemaking has become more waterfall, but my sources in the industry, who have been in the industry a little over ten years, describe precisely the opposite of what you're describing.
Ten years ago, there was reasonable art direction, a reasonable process, and the hope that a quality shot would at some point be called "done" so they could move on.
Today, even though the script-&gt;storyboard-&gt;previz-&gt;production process provides more structure, the actual process of a moviemaker's development is much more like iterative prototyping than it is a waterfall.
The increased flexibility of computer graphics has led directors to expect they can make changes at any point in the process and use CG to fix it up - everything from little things like not reshooting bad footage to completely reworking the ending of a movie or changing its plotline - all of things which have happened to my sources, particularly on "I Am Legend," where massive changes had to be made the further and further they went in the moviemaking - and this is with a lot of it plotted out and prevized.Your mileage may vary - if you have a really good director, this does not apply.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069530</id>
	<title>Agile is dead?</title>
	<author>matunos</author>
	<datestamp>1265748360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>That's news to me. I don't know anything about the gaming industry or their development process (though in some cases it seems to be "work your devs to the bone, and then go bankrupt"). But I can assure you that agile methodologies are alive and well in the corner of the industry in which I work (e-commerce).<br><br>But Agile is a broad term, encompassing many different ideas. Do you mean specifically XP? Scrum? Agile design? I would say elements of all of these things continue to thrive, while in my experience none of them exist in their pure theoretical form (which is appropriate, because it wouldn't be very "agile" to be dogmatic about process).<br><br>While I can't imagine a game being released in an iterative fashion (aside from bug fixes and the occasional add-on content), I can imagine an agile, iterative model being used in-house, at least for some parts. I mean, do you really want to risk having nothing to show for your work for 6 or more months? Surely something could be "released" (in-house) for downstream dependencies to start work, and some basic feedback to feed into your development.<br><br>Who knows, as I say, I don't have any experience with game development itself. But the risk one faces with too long of an iteration is arriving at your iteration end-point way behind schedule, behind in technology, and with components that may work great in a design made a year ago, but can no longer fulfill the new requirements that have cropped up.</htmltext>
<tokenext>That 's news to me .
I do n't know anything about the gaming industry or their development process ( though in some cases it seems to be " work your devs to the bone , and then go bankrupt " ) .
But I can assure you that agile methodologies are alive and well in the corner of the industry in which I work ( e-commerce ) .But Agile is a broad term , encompassing many different ideas .
Do you mean specifically XP ?
Scrum ? Agile design ?
I would say elements of all of these things continue to thrive , while in my experience none of them exist in their pure theoretical form ( which is appropriate , because it would n't be very " agile " to be dogmatic about process ) .While I ca n't imagine a game being released in an iterative fashion ( aside from bug fixes and the occasional add-on content ) , I can imagine an agile , iterative model being used in-house , at least for some parts .
I mean , do you really want to risk having nothing to show for your work for 6 or more months ?
Surely something could be " released " ( in-house ) for downstream dependencies to start work , and some basic feedback to feed into your development.Who knows , as I say , I do n't have any experience with game development itself .
But the risk one faces with too long of an iteration is arriving at your iteration end-point way behind schedule , behind in technology , and with components that may work great in a design made a year ago , but can no longer fulfill the new requirements that have cropped up .</tokentext>
<sentencetext>That's news to me.
I don't know anything about the gaming industry or their development process (though in some cases it seems to be "work your devs to the bone, and then go bankrupt").
But I can assure you that agile methodologies are alive and well in the corner of the industry in which I work (e-commerce).But Agile is a broad term, encompassing many different ideas.
Do you mean specifically XP?
Scrum? Agile design?
I would say elements of all of these things continue to thrive, while in my experience none of them exist in their pure theoretical form (which is appropriate, because it wouldn't be very "agile" to be dogmatic about process).While I can't imagine a game being released in an iterative fashion (aside from bug fixes and the occasional add-on content), I can imagine an agile, iterative model being used in-house, at least for some parts.
I mean, do you really want to risk having nothing to show for your work for 6 or more months?
Surely something could be "released" (in-house) for downstream dependencies to start work, and some basic feedback to feed into your development.Who knows, as I say, I don't have any experience with game development itself.
But the risk one faces with too long of an iteration is arriving at your iteration end-point way behind schedule, behind in technology, and with components that may work great in a design made a year ago, but can no longer fulfill the new requirements that have cropped up.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069924</id>
	<title>Unit testing in C++</title>
	<author>nanogiga</author>
	<datestamp>1265711880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Maybe not so related to the story, but anyway:</p><p>Game developers typically use C or C++ (at least the ones that create processing heavy 3D games), and it doesn't help that the open source frameworks for unit testing in C++ are not too great. The problem is that there are about 40 of them (see <a href="http://en.wikipedia.org/wiki/List\_of\_unit\_testing\_frameworks#C.2B.2B" title="wikipedia.org" rel="nofollow">http://en.wikipedia.org/wiki/List\_of\_unit\_testing\_frameworks#C.2B.2B</a> [wikipedia.org]), many developers spreading their talent over their own creation instead of working together on something good. We use UnitTest++ at work, and it hurts to see that the mailinglist is about dead, with interesting proposals getting no answer, and no updates since 2008. GTest seems better, but we can't switch just like that.</p><p>Contrast this to Java, where you basically have JUnit and TestNG in healthy competition.</p><p>There are commercial options, like UquoniTest (see <a href="http://www.q-mentum.com/uquonitest.php" title="q-mentum.com" rel="nofollow">http://www.q-mentum.com/uquonitest.php</a> [q-mentum.com]) which has great features, but I'd rather wait until they're compatible with UnitTest++ (as they promise on their blog), and Cantata++ (see <a href="http://www.ipl.com/products/tools/pt400.uk.php" title="ipl.com" rel="nofollow">http://www.ipl.com/products/tools/pt400.uk.php</a> [ipl.com]) which has code coverage.</p></htmltext>
<tokenext>Maybe not so related to the story , but anyway : Game developers typically use C or C + + ( at least the ones that create processing heavy 3D games ) , and it does n't help that the open source frameworks for unit testing in C + + are not too great .
The problem is that there are about 40 of them ( see http : //en.wikipedia.org/wiki/List \ _of \ _unit \ _testing \ _frameworks # C.2B.2B [ wikipedia.org ] ) , many developers spreading their talent over their own creation instead of working together on something good .
We use UnitTest + + at work , and it hurts to see that the mailinglist is about dead , with interesting proposals getting no answer , and no updates since 2008 .
GTest seems better , but we ca n't switch just like that.Contrast this to Java , where you basically have JUnit and TestNG in healthy competition.There are commercial options , like UquoniTest ( see http : //www.q-mentum.com/uquonitest.php [ q-mentum.com ] ) which has great features , but I 'd rather wait until they 're compatible with UnitTest + + ( as they promise on their blog ) , and Cantata + + ( see http : //www.ipl.com/products/tools/pt400.uk.php [ ipl.com ] ) which has code coverage .</tokentext>
<sentencetext>Maybe not so related to the story, but anyway:Game developers typically use C or C++ (at least the ones that create processing heavy 3D games), and it doesn't help that the open source frameworks for unit testing in C++ are not too great.
The problem is that there are about 40 of them (see http://en.wikipedia.org/wiki/List\_of\_unit\_testing\_frameworks#C.2B.2B [wikipedia.org]), many developers spreading their talent over their own creation instead of working together on something good.
We use UnitTest++ at work, and it hurts to see that the mailinglist is about dead, with interesting proposals getting no answer, and no updates since 2008.
GTest seems better, but we can't switch just like that.Contrast this to Java, where you basically have JUnit and TestNG in healthy competition.There are commercial options, like UquoniTest (see http://www.q-mentum.com/uquonitest.php [q-mentum.com]) which has great features, but I'd rather wait until they're compatible with UnitTest++ (as they promise on their blog), and Cantata++ (see http://www.ipl.com/products/tools/pt400.uk.php [ipl.com]) which has code coverage.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069888</id>
	<title>methodology for noobs</title>
	<author>Anonymous</author>
	<datestamp>1265711400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>When noobs don't know what to do and can't define the problem they break out the Agile card.<br> <br>Problem is managers and CEOs lap up the Agile mantra especially when from a slick salesman. Agile sounds sexy. Waterfall methodology is what stale dinosaurs use.</htmltext>
<tokenext>When noobs do n't know what to do and ca n't define the problem they break out the Agile card .
Problem is managers and CEOs lap up the Agile mantra especially when from a slick salesman .
Agile sounds sexy .
Waterfall methodology is what stale dinosaurs use .</tokentext>
<sentencetext>When noobs don't know what to do and can't define the problem they break out the Agile card.
Problem is managers and CEOs lap up the Agile mantra especially when from a slick salesman.
Agile sounds sexy.
Waterfall methodology is what stale dinosaurs use.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073262</id>
	<title>Re:Conclusions</title>
	<author>lena\_10326</author>
	<datestamp>1265736180000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>I've used scrum for over a year now, so my opinion is colored by that. It's my opinion that scrum works quite well in terms of productivity but it has two major problems. It takes most the fun out of development and turns IT work into a daily grind of task processing fed from an infinite treadmill. The second is it kills inventiveness.</p><p>Why do I say that? Well, scrum prioritizes tasks by importance and not by tasks you're interested in working on. On teams I was on the task priority was simplistic and based on three things: 1) the seniority and level of the requestor, 2) the number of systems impacted by the bug, and lastly 3) the nature of a feature enhancement. #1 is usually turns out to be a waste of time (I call it the boss tax.) #2 is usually very hard and quite monotonous. #3 is the source of fun tasks. Since operations work always ends up trumping enhancement work, feature requests get pushed into the future so you're always chasing the day when you actually get to do interesting work. It doesn't come often.</p><p>Scrum is a team collaboration effort so stories added to the board must be justified. It's not enough to justify a task with "<em>...because I want to work on it and I have cool ideas to try out...</em>" or "<em>the code base needs refactoring and I have some ideas how to craft it better</em>". It will be summarily rejected by your teammates because they will chant "<em>we must stick to the priorities</em>". That is the precise moment when scrum kills invention.</p><p>Sometimes we need a mental Scoobie snack and need to work on interesting things in order to prevent burn out. I don't think it's to the team's advantage to ignore that. All the great ideas were developed by those interested in the particular problem and many were developed by those who momentarily ignored their peers and the bureaucratic system of control.</p><p>What I described is classic thread starvation problem due to a simplistic scheduler implementation. We have 3 threads but each is given different priority. In our example, it's thread 3 that never gets CPU time. The way you break free to give yourself time to innovate is to ignore the system and show your work <em>after</em> your prototype is complete. This may mean locking yourself away for a few days until your work is done. It may mean getting a negative review or worse getting fired. If the system of managing software development penalizes you for developing innovation, then the system is the problem.</p><p>As I said earlier scrum works well but only when metered and executed properly but who pulls that off? For example the schedule must allocate time between sprints for the sprints to be effective. The in-between time is critical for performing non-scheduled activities. Of course that lasts until a manager sees the schedule and says "<em>hey why is there all this idle time between sprints?</em>" which inevitably results with the "brilliant" observation that butting sprints against each other will "boost productivity". Sprints are a great idea so why not make every day a sprint day right? </p><p>Over the year we got a <em>lot</em> done so on paper we were very effective and productive, but it came with a cost--never ending recruitment and over taxed, under staffed teams. In the last 18 months my team has experienced 50\% turnover. One teammate moved to another team and 2 others left the company. From what I can gather the story was the same during the previous 18 month block of time. You have to understand this is a big deal because in this company 100 resumes results in 1 phone screen; 100 phone screens result in 1 offer. It will take 6 to 9 months to replace the missing three so the remaining 3 teammates are facing those months of supporting 3 very large complex systems while simultaneously trying to do new development while on pager duty. For one of those 3 systems no one understands it because it requires specific technology experience and the 2 domain experts left. When the new hires come on of course there will more time wasted on training.</p></htmltext>
<tokenext>I 've used scrum for over a year now , so my opinion is colored by that .
It 's my opinion that scrum works quite well in terms of productivity but it has two major problems .
It takes most the fun out of development and turns IT work into a daily grind of task processing fed from an infinite treadmill .
The second is it kills inventiveness.Why do I say that ?
Well , scrum prioritizes tasks by importance and not by tasks you 're interested in working on .
On teams I was on the task priority was simplistic and based on three things : 1 ) the seniority and level of the requestor , 2 ) the number of systems impacted by the bug , and lastly 3 ) the nature of a feature enhancement .
# 1 is usually turns out to be a waste of time ( I call it the boss tax .
) # 2 is usually very hard and quite monotonous .
# 3 is the source of fun tasks .
Since operations work always ends up trumping enhancement work , feature requests get pushed into the future so you 're always chasing the day when you actually get to do interesting work .
It does n't come often.Scrum is a team collaboration effort so stories added to the board must be justified .
It 's not enough to justify a task with " ...because I want to work on it and I have cool ideas to try out... " or " the code base needs refactoring and I have some ideas how to craft it better " .
It will be summarily rejected by your teammates because they will chant " we must stick to the priorities " .
That is the precise moment when scrum kills invention.Sometimes we need a mental Scoobie snack and need to work on interesting things in order to prevent burn out .
I do n't think it 's to the team 's advantage to ignore that .
All the great ideas were developed by those interested in the particular problem and many were developed by those who momentarily ignored their peers and the bureaucratic system of control.What I described is classic thread starvation problem due to a simplistic scheduler implementation .
We have 3 threads but each is given different priority .
In our example , it 's thread 3 that never gets CPU time .
The way you break free to give yourself time to innovate is to ignore the system and show your work after your prototype is complete .
This may mean locking yourself away for a few days until your work is done .
It may mean getting a negative review or worse getting fired .
If the system of managing software development penalizes you for developing innovation , then the system is the problem.As I said earlier scrum works well but only when metered and executed properly but who pulls that off ?
For example the schedule must allocate time between sprints for the sprints to be effective .
The in-between time is critical for performing non-scheduled activities .
Of course that lasts until a manager sees the schedule and says " hey why is there all this idle time between sprints ?
" which inevitably results with the " brilliant " observation that butting sprints against each other will " boost productivity " .
Sprints are a great idea so why not make every day a sprint day right ?
Over the year we got a lot done so on paper we were very effective and productive , but it came with a cost--never ending recruitment and over taxed , under staffed teams .
In the last 18 months my team has experienced 50 \ % turnover .
One teammate moved to another team and 2 others left the company .
From what I can gather the story was the same during the previous 18 month block of time .
You have to understand this is a big deal because in this company 100 resumes results in 1 phone screen ; 100 phone screens result in 1 offer .
It will take 6 to 9 months to replace the missing three so the remaining 3 teammates are facing those months of supporting 3 very large complex systems while simultaneously trying to do new development while on pager duty .
For one of those 3 systems no one understands it because it requires specific technology experience and the 2 domain experts left .
When the new hires come on of course there will more time wasted on training .</tokentext>
<sentencetext>I've used scrum for over a year now, so my opinion is colored by that.
It's my opinion that scrum works quite well in terms of productivity but it has two major problems.
It takes most the fun out of development and turns IT work into a daily grind of task processing fed from an infinite treadmill.
The second is it kills inventiveness.Why do I say that?
Well, scrum prioritizes tasks by importance and not by tasks you're interested in working on.
On teams I was on the task priority was simplistic and based on three things: 1) the seniority and level of the requestor, 2) the number of systems impacted by the bug, and lastly 3) the nature of a feature enhancement.
#1 is usually turns out to be a waste of time (I call it the boss tax.
) #2 is usually very hard and quite monotonous.
#3 is the source of fun tasks.
Since operations work always ends up trumping enhancement work, feature requests get pushed into the future so you're always chasing the day when you actually get to do interesting work.
It doesn't come often.Scrum is a team collaboration effort so stories added to the board must be justified.
It's not enough to justify a task with "...because I want to work on it and I have cool ideas to try out..." or "the code base needs refactoring and I have some ideas how to craft it better".
It will be summarily rejected by your teammates because they will chant "we must stick to the priorities".
That is the precise moment when scrum kills invention.Sometimes we need a mental Scoobie snack and need to work on interesting things in order to prevent burn out.
I don't think it's to the team's advantage to ignore that.
All the great ideas were developed by those interested in the particular problem and many were developed by those who momentarily ignored their peers and the bureaucratic system of control.What I described is classic thread starvation problem due to a simplistic scheduler implementation.
We have 3 threads but each is given different priority.
In our example, it's thread 3 that never gets CPU time.
The way you break free to give yourself time to innovate is to ignore the system and show your work after your prototype is complete.
This may mean locking yourself away for a few days until your work is done.
It may mean getting a negative review or worse getting fired.
If the system of managing software development penalizes you for developing innovation, then the system is the problem.As I said earlier scrum works well but only when metered and executed properly but who pulls that off?
For example the schedule must allocate time between sprints for the sprints to be effective.
The in-between time is critical for performing non-scheduled activities.
Of course that lasts until a manager sees the schedule and says "hey why is there all this idle time between sprints?
" which inevitably results with the "brilliant" observation that butting sprints against each other will "boost productivity".
Sprints are a great idea so why not make every day a sprint day right?
Over the year we got a lot done so on paper we were very effective and productive, but it came with a cost--never ending recruitment and over taxed, under staffed teams.
In the last 18 months my team has experienced 50\% turnover.
One teammate moved to another team and 2 others left the company.
From what I can gather the story was the same during the previous 18 month block of time.
You have to understand this is a big deal because in this company 100 resumes results in 1 phone screen; 100 phone screens result in 1 offer.
It will take 6 to 9 months to replace the missing three so the remaining 3 teammates are facing those months of supporting 3 very large complex systems while simultaneously trying to do new development while on pager duty.
For one of those 3 systems no one understands it because it requires specific technology experience and the 2 domain experts left.
When the new hires come on of course there will more time wasted on training.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069796</id>
	<title>Re:When to use "agile" methods.</title>
	<author>sourcerror</author>
	<datestamp>1265709660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"Trying to use "agile" on a hard, tightly-coupled problem with no predefined structural framework, like an optimizing compiler or a database engine, is likely to result in a disaster."</p><p>Last time I did visit the CS department, they weren't busy drawing UML diagrams. I mean, a lot of things can't be expressed well with an UML diagram. (So you'll use pseudocode, some "non-standard" diagram, maybe - oh the horror - natural language.)</p><p>In my experience the people who are the most fond of UML diagrams are the people who make software for beancounters.</p></htmltext>
<tokenext>" Trying to use " agile " on a hard , tightly-coupled problem with no predefined structural framework , like an optimizing compiler or a database engine , is likely to result in a disaster .
" Last time I did visit the CS department , they were n't busy drawing UML diagrams .
I mean , a lot of things ca n't be expressed well with an UML diagram .
( So you 'll use pseudocode , some " non-standard " diagram , maybe - oh the horror - natural language .
) In my experience the people who are the most fond of UML diagrams are the people who make software for beancounters .</tokentext>
<sentencetext>"Trying to use "agile" on a hard, tightly-coupled problem with no predefined structural framework, like an optimizing compiler or a database engine, is likely to result in a disaster.
"Last time I did visit the CS department, they weren't busy drawing UML diagrams.
I mean, a lot of things can't be expressed well with an UML diagram.
(So you'll use pseudocode, some "non-standard" diagram, maybe - oh the horror - natural language.
)In my experience the people who are the most fond of UML diagrams are the people who make software for beancounters.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070358</id>
	<title>Re:Conclusions</title>
	<author>mcvos</author>
	<datestamp>1265718600000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>TFA starts out sounding like idiot drivel with strong anti-agile prejudices caused by bad experiences with bas, expensive consultants. Later on it gets very informative, however. It's not the Agile doesn't work. It's that, depending on your situation, it might not work for you.</p><p>Agile gives programmers freedom. If you've got good programmers, that's a good idea. If your programmers are crap, you're better off restricting their creativity. At least, that's the gist I'm getting from the first half of the article.</p></htmltext>
<tokenext>TFA starts out sounding like idiot drivel with strong anti-agile prejudices caused by bad experiences with bas , expensive consultants .
Later on it gets very informative , however .
It 's not the Agile does n't work .
It 's that , depending on your situation , it might not work for you.Agile gives programmers freedom .
If you 've got good programmers , that 's a good idea .
If your programmers are crap , you 're better off restricting their creativity .
At least , that 's the gist I 'm getting from the first half of the article .</tokentext>
<sentencetext>TFA starts out sounding like idiot drivel with strong anti-agile prejudices caused by bad experiences with bas, expensive consultants.
Later on it gets very informative, however.
It's not the Agile doesn't work.
It's that, depending on your situation, it might not work for you.Agile gives programmers freedom.
If you've got good programmers, that's a good idea.
If your programmers are crap, you're better off restricting their creativity.
At least, that's the gist I'm getting from the first half of the article.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069994</id>
	<title>dumber than rocks?</title>
	<author>Anonymous</author>
	<datestamp>1265713440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I have to say I'm amazed at how many idiots there are here. Has anyone on here <i>really</i> implemented or participated in a well-run agile process? Yes I said process because that's what it is.</p><p>The article comes across as thoughtful and presenting a well formulated view but completely misses some of the fundamental tenets of the agile manifesto. For example, valuing interactions over process does not mean you create a chaotic, wild-west environment. It simply means you do not rely on process to strictly guide you but expect people to talk through problems and quickly identify solutions rather than apply process for the sake of process.</p><p>An agile development environment, whether Scrum, XP, or a customized hybrid approach (truly taking agile concept to heart) creates a repeatable framework for delivering quality results quickly. A good agile environment will have a cadence that let's developers focus on technical solutions. It give managers a consistent window to see how work is progressing, to ensure requirements are met, and to quickly and easily adjust based on review, feedback, testing, etc.</p><p>I'd also point out that the writer of the article said the following in his article, very clearly <i>NOT</i> stating that agile was the cause of the problem:<br>Developing software is hard and developing games is particularly tough. We only have to look at the software development landscape to see the rotting corpses of failed projects as evidence of this fact."</p><p>The key responsibility of management is to help prioritize what gets developed when. If you don't capture and prioritize the development of fundamental systems (read: game play mechanics and physics) early on then this sounds to me like piss-poor management. You let high-risk items sit until late in the process. The more tightly coupled various elements are, the more critical the prioritization process.</p><p>I've actually heard some state that "it should not be a random walk". No shit? Thanks brainiac. Anyone that thinks that is what an agile process entails has no idea how to manage. Now please step aside so the team can work on incrementally delivering on the long-term product strategy and goals I've prioritized and roughly mapped-out (with their help).</p><p>Oh, did I mention I come at this from slightly outside the development team in a product manager role? And it <i>STILL</i> makes sense to me and helps me be more effective in my role.</p></htmltext>
<tokenext>I have to say I 'm amazed at how many idiots there are here .
Has anyone on here really implemented or participated in a well-run agile process ?
Yes I said process because that 's what it is.The article comes across as thoughtful and presenting a well formulated view but completely misses some of the fundamental tenets of the agile manifesto .
For example , valuing interactions over process does not mean you create a chaotic , wild-west environment .
It simply means you do not rely on process to strictly guide you but expect people to talk through problems and quickly identify solutions rather than apply process for the sake of process.An agile development environment , whether Scrum , XP , or a customized hybrid approach ( truly taking agile concept to heart ) creates a repeatable framework for delivering quality results quickly .
A good agile environment will have a cadence that let 's developers focus on technical solutions .
It give managers a consistent window to see how work is progressing , to ensure requirements are met , and to quickly and easily adjust based on review , feedback , testing , etc.I 'd also point out that the writer of the article said the following in his article , very clearly NOT stating that agile was the cause of the problem : Developing software is hard and developing games is particularly tough .
We only have to look at the software development landscape to see the rotting corpses of failed projects as evidence of this fact .
" The key responsibility of management is to help prioritize what gets developed when .
If you do n't capture and prioritize the development of fundamental systems ( read : game play mechanics and physics ) early on then this sounds to me like piss-poor management .
You let high-risk items sit until late in the process .
The more tightly coupled various elements are , the more critical the prioritization process.I 've actually heard some state that " it should not be a random walk " .
No shit ?
Thanks brainiac .
Anyone that thinks that is what an agile process entails has no idea how to manage .
Now please step aside so the team can work on incrementally delivering on the long-term product strategy and goals I 've prioritized and roughly mapped-out ( with their help ) .Oh , did I mention I come at this from slightly outside the development team in a product manager role ?
And it STILL makes sense to me and helps me be more effective in my role .</tokentext>
<sentencetext>I have to say I'm amazed at how many idiots there are here.
Has anyone on here really implemented or participated in a well-run agile process?
Yes I said process because that's what it is.The article comes across as thoughtful and presenting a well formulated view but completely misses some of the fundamental tenets of the agile manifesto.
For example, valuing interactions over process does not mean you create a chaotic, wild-west environment.
It simply means you do not rely on process to strictly guide you but expect people to talk through problems and quickly identify solutions rather than apply process for the sake of process.An agile development environment, whether Scrum, XP, or a customized hybrid approach (truly taking agile concept to heart) creates a repeatable framework for delivering quality results quickly.
A good agile environment will have a cadence that let's developers focus on technical solutions.
It give managers a consistent window to see how work is progressing, to ensure requirements are met, and to quickly and easily adjust based on review, feedback, testing, etc.I'd also point out that the writer of the article said the following in his article, very clearly NOT stating that agile was the cause of the problem:Developing software is hard and developing games is particularly tough.
We only have to look at the software development landscape to see the rotting corpses of failed projects as evidence of this fact.
"The key responsibility of management is to help prioritize what gets developed when.
If you don't capture and prioritize the development of fundamental systems (read: game play mechanics and physics) early on then this sounds to me like piss-poor management.
You let high-risk items sit until late in the process.
The more tightly coupled various elements are, the more critical the prioritization process.I've actually heard some state that "it should not be a random walk".
No shit?
Thanks brainiac.
Anyone that thinks that is what an agile process entails has no idea how to manage.
Now please step aside so the team can work on incrementally delivering on the long-term product strategy and goals I've prioritized and roughly mapped-out (with their help).Oh, did I mention I come at this from slightly outside the development team in a product manager role?
And it STILL makes sense to me and helps me be more effective in my role.</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069444
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070732
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069712
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073022
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070178
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069488
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070784
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070254
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31071152
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073814
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070052
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31071932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070254
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070358
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069640
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069584
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070400
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073544
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069340
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069822
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069530
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073788
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069340
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31079032
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069714
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070924
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069712
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31071634
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31072964
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069712
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069676
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070084
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069796
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31081324
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31071842
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31072050
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069538
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069488
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070316
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069404
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31072380
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070254
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069946
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069340
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069982
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070004
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069496
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069340
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069656
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069584
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31086304
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069340
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073262
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_0551202_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069688
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069584
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069642
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069468
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069488
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070178
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069538
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069584
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069656
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069640
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069688
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069976
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069340
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069946
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073544
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073788
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069496
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31086304
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070024
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069326
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069448
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070400
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069982
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070004
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073022
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31071634
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069796
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073814
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31071152
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070084
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069338
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31072050
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31073262
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069444
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070052
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070358
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069714
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31079032
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069676
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31071842
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31081324
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069404
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070316
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070958
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069888
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069744
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069530
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069822
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069540
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070166
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070254
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31071932
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31072380
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070784
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_0551202.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31069712
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31072964
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070924
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_0551202.31070732
</commentlist>
</conversation>
