Post-Agile world?
-
Rage wrote:
There is nowhere mentioned that people driving projects must be skilled people in the article.
Article:
Experience also plays a factor. For example, I would be prepared to take my best programmer, unleash him on some thorny technical problem, give him everything he needs, sit back and wait for the magic to happen. However, I would be less willing to extend that courtesy to a fresh faced graduate straight out of university. Most juniors need guidance, mentoring and structure until they find their feet.
There are a few points where he talks about experience. And the entire article is really about how some newbies apply techniques based on what is in vogue rather than using experience to decide what techniques (aka, methodologies) are appropriate given a specific circumstance.
Rage wrote:
The scale is also not mentioned. A project with, say, less than 5 people has more chance to succeed in a rather "people" oriented environment. A project with 100 people has not a single chance without processes.
Article:
Product portfolio is another aspect to consider, a large studio may have one project to "pay the rent" (production focused) and a second to increase the prestige of the studio (creatively focused). Understanding the business context is important in assessing the capacity and ambition for each game and ergo, the best way to run it.
Scale is discussed, and scale is obviously an important factor. I think, though, that scale is something that can be managed to a degree. Like the article talks about, some parts of a project can be split (e.g., art asset creation), while others may not benefit from dumping a bunch of people on it (e.g., programming). At one level, you might apply process (the splitting up and managing of teams), while at lower levels "people" may be a more appropriate focus (e.g., giving them high level tasks and letting them do their thing). Overall, I'd say the author is saying there is no single technique to apply to a given project. But the article does present factors to consider when deciding which solution to go with. It seems this article is more for critical thinkers rather than those looking for a blueprint to follow to ensure success.
aspdotnetdev wrote:
There are a few points where he talks about experience. And the entire article is really about how some newbies apply techniques based on what is in vogue rather than using experience to decide what techniques (aka, methodologies) are appropriate given a specific circumstance.
I was talking about _project management_ skills. And I don't think you can limit it to newbies, the article is as well intended to managers, bosses, and so on. Well, project management ;)
aspdotnetdev wrote:
a blueprint to follow to ensure success
Just in case you come across that, let me know.
-
aspdotnetdev wrote:
There are a few points where he talks about experience. And the entire article is really about how some newbies apply techniques based on what is in vogue rather than using experience to decide what techniques (aka, methodologies) are appropriate given a specific circumstance.
I was talking about _project management_ skills. And I don't think you can limit it to newbies, the article is as well intended to managers, bosses, and so on. Well, project management ;)
aspdotnetdev wrote:
a blueprint to follow to ensure success
Just in case you come across that, let me know.
Rage wrote:
in case you come across that, let me know
The trick is to eliminate the competition with an SQL injection attack.
Rage wrote:
I don't think you can limit it to newbies, the article is as well intended to managers, bosses
Every manager and boss is "new" to the job when they first start it.
-
Got this from /. this morning. A long article, but an interesting read from a guy who has to ship products in the real world. I found the use of the term post-agile interesting. If indeed that's where we are, make way for yet another design religion to follow. Nature abhors a vacuum (I'll leave it to you to make the obvious "why xyz sucks" puns). The hype and dogma of Agile evangelists has left in its wake a trail of broken projects, ruined businesses and misguided neophytes bleating the tired doctrines of their long departed prophets. The games industry was no exception, with many swept up in the phantasmagoria from which we are only now beginning to witness the debris. Game Development in a Post-Agile World[^]
Christopher Duncan www.PracticalUSA.com Author of The Career Programmer and Unite the Tribes Copywriting Services
-
Rage wrote:
in case you come across that, let me know
The trick is to eliminate the competition with an SQL injection attack.
Rage wrote:
I don't think you can limit it to newbies, the article is as well intended to managers, bosses
Every manager and boss is "new" to the job when they first start it.
-
I am sorry but I fail to see a main point in the article. The article simply restates what I have read in several project management books including those in books about agile development. The problem is that most people claim their chaotic development as Agile development. Managers love it because the word Agile sounds cool. Programmers love it because they think they can excuse their chaotic programming as Agile development. Having shipped at least 6 products in the last 10 years, some timely and successful where as others not so timely and not so successful, I can say following :- 1. Whenever I worked closely with customer(end-users) the product has been a success. 2. Working software is always a better thing than a concept explained in a document. People do not read documents nor they can comprehend something just by reading it whereas when they see something working, not only they can understand how things work but the also provide good and useful feedback. 3. Change is inevitable. You better change according to what customer likes rather than be rigid and be rigid and develop something which he does not like. Things you assumed in the beginning may not even be true when the software is deployed in the real world. This is especially true with performance. This is where automated tests also come into picture. More automated tests are, the better change management you can do. I have always found that developing iteratively with close involvement of the customer or an interested party is always better than developing something and involving someone very late. If you look closely these are the principles in Agile manifesto. The things about Agile is flexibility and one method in one team/culture may not suite other team/culture.
-
Got this from /. this morning. A long article, but an interesting read from a guy who has to ship products in the real world. I found the use of the term post-agile interesting. If indeed that's where we are, make way for yet another design religion to follow. Nature abhors a vacuum (I'll leave it to you to make the obvious "why xyz sucks" puns). The hype and dogma of Agile evangelists has left in its wake a trail of broken projects, ruined businesses and misguided neophytes bleating the tired doctrines of their long departed prophets. The games industry was no exception, with many swept up in the phantasmagoria from which we are only now beginning to witness the debris. Game Development in a Post-Agile World[^]
Christopher Duncan www.PracticalUSA.com Author of The Career Programmer and Unite the Tribes Copywriting Services
Christopher Duncan wrote:
If indeed that's where we are, make way for yet another design religion to follow
After Agile we will move to Clumsy, then Brittle, and finally Senile. Authors -- get to work.
-
I am sorry but I fail to see a main point in the article. The article simply restates what I have read in several project management books including those in books about agile development. The problem is that most people claim their chaotic development as Agile development. Managers love it because the word Agile sounds cool. Programmers love it because they think they can excuse their chaotic programming as Agile development. Having shipped at least 6 products in the last 10 years, some timely and successful where as others not so timely and not so successful, I can say following :- 1. Whenever I worked closely with customer(end-users) the product has been a success. 2. Working software is always a better thing than a concept explained in a document. People do not read documents nor they can comprehend something just by reading it whereas when they see something working, not only they can understand how things work but the also provide good and useful feedback. 3. Change is inevitable. You better change according to what customer likes rather than be rigid and be rigid and develop something which he does not like. Things you assumed in the beginning may not even be true when the software is deployed in the real world. This is especially true with performance. This is where automated tests also come into picture. More automated tests are, the better change management you can do. I have always found that developing iteratively with close involvement of the customer or an interested party is always better than developing something and involving someone very late. If you look closely these are the principles in Agile manifesto. The things about Agile is flexibility and one method in one team/culture may not suite other team/culture.
My experience is similar to yours. I observed in the 1980s when I first began programming that software development is an iterative process. This is true with just about any invention (which is why architects often build models) but much faster. I've since observed that agile, scrum, extreme programming, etc. took that small known and threw in a whole bunch of nonsense around it to make them look better (and to ensure they could charge a consulting fee.) I've also observed that the names of these ideas matter. Engineers like to think they are agile or extreme. Scrum sounds ironic and so forth. My own experience is that embracing these concepts made things worse since all management was really doing was adopting the name while still doing things the same way--meaning meetings and making up crap. (And automated testing can be a trap. All too often developers write to the tests, not to the requirements. They balk at some features because the testing can't be automated. Worse, if a major change requires all the automated tests be junked, management balks at the cost and developers at the effort. In the end, the project ceases to be customer centered, but testing centered.)
-
“Hokey religions and ancient weapons are no match for a good blaster at your side, kid.” Some people insist on practicing one methodology or another with almost religious furor. Agile was clearly never meant for some projects which is equally true of the waterfall method or any other methodology. Sometimes our industry is taken-by-storm with one idea or another. Management types and academics seem to like to take these ideas and turn them into religions of sorts. Blaming the failure on the methodology used is crazy. Blame the people involved, they are the ones at fault, not the methodology. We like to put the blame on the technology, or the methodology because it allows us to not blame ourselves. Personally, I work with a very small team (2 programmers). For this situation and my employers business model, Agile techniques work well. We certainly don't follow every agile rule or guideline, though. We take what works from Agile, Waterfall, etc and throw away the rest. Every project is different, so some projects may get more agile and less waterfall while others may get less agile. I'd have to guess that most failed projects fail for one of three reasons: 1) overly ambitious goals, 2) lack of real goals, 3) lack of talented management and/or programmers. The bottom line is without talented programmers and management, most projects are doomed to fail. If they succeed, it will be because of luck. Even with talented people some projects will still fail. I think people sometimes forget that some software (games in particular) are often trying to do new things that haven't really been done before. Just like early pioneers often died while trying to make their way across the continent (North America), pioneers in our industry are also going to fail. Some will succeed, though and make a way for the next group. When I read articles like this I'm always a little afraid of what management types and academic types will do with this information. There is a place for controlled, planned, methodical execution of software development and there is equally a place for creative, exploration driven, pure research methodologies. Each have their place and neither replaces the other.
Matt Gullett wrote:
“Hokey religions and ancient weapons are no match for a good blaster at your side, kid.”
:laugh: 5!
Christopher Duncan www.PracticalUSA.com Author of The Career Programmer and Unite the Tribes Copywriting Services
-
“Hokey religions and ancient weapons are no match for a good blaster at your side, kid.” Some people insist on practicing one methodology or another with almost religious furor. Agile was clearly never meant for some projects which is equally true of the waterfall method or any other methodology. Sometimes our industry is taken-by-storm with one idea or another. Management types and academics seem to like to take these ideas and turn them into religions of sorts. Blaming the failure on the methodology used is crazy. Blame the people involved, they are the ones at fault, not the methodology. We like to put the blame on the technology, or the methodology because it allows us to not blame ourselves. Personally, I work with a very small team (2 programmers). For this situation and my employers business model, Agile techniques work well. We certainly don't follow every agile rule or guideline, though. We take what works from Agile, Waterfall, etc and throw away the rest. Every project is different, so some projects may get more agile and less waterfall while others may get less agile. I'd have to guess that most failed projects fail for one of three reasons: 1) overly ambitious goals, 2) lack of real goals, 3) lack of talented management and/or programmers. The bottom line is without talented programmers and management, most projects are doomed to fail. If they succeed, it will be because of luck. Even with talented people some projects will still fail. I think people sometimes forget that some software (games in particular) are often trying to do new things that haven't really been done before. Just like early pioneers often died while trying to make their way across the continent (North America), pioneers in our industry are also going to fail. Some will succeed, though and make a way for the next group. When I read articles like this I'm always a little afraid of what management types and academic types will do with this information. There is a place for controlled, planned, methodical execution of software development and there is equally a place for creative, exploration driven, pure research methodologies. Each have their place and neither replaces the other.
-
I was using all these "methodologies" before they were given stylish names.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001I once replied similarly to a Design Patterns question in an interview. Got rejected because I didn't seem inclined to learn design patterns
"It was when I found out I could make mistakes that I knew I was on to something." -Ornette Coleman "Philosophy is a study that lets us be unhappy more intelligently." -Anon.
-
I once replied similarly to a Design Patterns question in an interview. Got rejected because I didn't seem inclined to learn design patterns
"It was when I found out I could make mistakes that I knew I was on to something." -Ornette Coleman "Philosophy is a study that lets us be unhappy more intelligently." -Anon.
Despite the fact that you in fact *had* learned them... That really sucks, and I've been there, too...
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
