Post-Agile world?
-
Indeed: I was there before someone invented the word 'methodologies'. Although, of course, the best one is RTFM... :-)
RTFM was day 1 training when I started way back when
Panic, Chaos, Destruction. My work here is done. or "Drink. Get drunk. Fall over." - P O'H
-
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
Article states:
Process is an instrument of authority. A process is a statement of what to do, how we should do it and in what order. Process is conservative, hierarchical and formal. Process upholds the status quo.
That was true maybe still a decade ago. But things have changed. Most of the problems he describes can be handle by requirement and risk management. These are the two pillars of project management; and this is a skill. There is nowhere mentioned that people driving projects must be skilled people in the article. But that is how it is. Those of you who claim they have been applying agile or scrum or whatever method before even the name existed were clever enough to figure out by themselves how to achieve good project management. For a lot of us, it is a plain use of common sense. 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.
-
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, 2001John Simmons / outlaw programmer wrote:
I was using all these "methodologies" before they were given stylish names.
You were using your brain and common sense? :) We had all kinds of roadmaps that 'guarantee' the best endproduct in the smallest amount of time. Some people follow the instructions blindly, others learn to navigate. And there's some who make a living out of selling those roadmaps.
I are Troll :suss:
-
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
-
Article states:
Process is an instrument of authority. A process is a statement of what to do, how we should do it and in what order. Process is conservative, hierarchical and formal. Process upholds the status quo.
That was true maybe still a decade ago. But things have changed. Most of the problems he describes can be handle by requirement and risk management. These are the two pillars of project management; and this is a skill. There is nowhere mentioned that people driving projects must be skilled people in the article. But that is how it is. Those of you who claim they have been applying agile or scrum or whatever method before even the name existed were clever enough to figure out by themselves how to achieve good project management. For a lot of us, it is a plain use of common sense. 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.
[system theory mode] Where Agile and it's ilk have succeeded is moving software production away from the machine metaphor so loved by corporate bureaucracies and replaced it with a more flexible organic structure. Except in the most trivial case, it is very difficult to know the final outcome of a project at the outset. By breaking up the project and replacing the goal orientated approach of a waterfall life-cycle with the evolution and survival in built into the iterative cycle, we get a more flexible product that will probably meet the client's requirements. [/system theory mode]
Panic, Chaos, Destruction. My work here is done. or "Drink. Get drunk. Fall over." - P O'H
-
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
The problem isn't Agile (or RAD, waterfall, whatever); the problem is one or more of: - The academic world gets hold of the ideas, and plots every possible activity in minute and rigid detail (and writes books), despite the fact that the propounders have little or no real-world experience. - Second-rate devs ("them as can, do", remember) teach private courses (and write books), that have the same "Thou Shalt...!" attitude -- usually basing most arguments on the "Hey, it worked great for a company that's nothing whatsoever like yours!" premise. - N00bs come out of Uni or off courses, convinced that a nit-picking adherence to the aforementioned minute details is more important that getting the work done. - Perfectly good devs follow the lead of the nit-pickers, because it all sounds like it makes sense, and they don't have time to properly look into the methodology themselves (because they're up to their eyeballs doing the actual work!) And the whole thing ends up, as you say, as a "design religion", which is more important than actually producing good work on time. The only "minute detail" that's left by the wayside is that the real priority is, and always should be, spending as much time as possible on producing good code.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Article states:
Process is an instrument of authority. A process is a statement of what to do, how we should do it and in what order. Process is conservative, hierarchical and formal. Process upholds the status quo.
That was true maybe still a decade ago. But things have changed. Most of the problems he describes can be handle by requirement and risk management. These are the two pillars of project management; and this is a skill. There is nowhere mentioned that people driving projects must be skilled people in the article. But that is how it is. Those of you who claim they have been applying agile or scrum or whatever method before even the name existed were clever enough to figure out by themselves how to achieve good project management. For a lot of us, it is a plain use of common sense. 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.
Good points. :thumbsup: People often even forget that saying: "OOP is better than structured programming" make no sense without considering project's scale. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
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
“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.
-
Article states:
Process is an instrument of authority. A process is a statement of what to do, how we should do it and in what order. Process is conservative, hierarchical and formal. Process upholds the status quo.
That was true maybe still a decade ago. But things have changed. Most of the problems he describes can be handle by requirement and risk management. These are the two pillars of project management; and this is a skill. There is nowhere mentioned that people driving projects must be skilled people in the article. But that is how it is. Those of you who claim they have been applying agile or scrum or whatever method before even the name existed were clever enough to figure out by themselves how to achieve good project management. For a lot of us, it is a plain use of common sense. 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.
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.
-
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
This was my favorite part: "No two projects are the same, well - unless you make racing games." :D
-
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
After reading the article in detail: It's a good read, thanks for posting. I've always wondered how "truly agile" fits into traditional business expectations that care about dollars and dates. I've never seen any variant of agile that defined interfaces to "classic" sales and marketing - or at the very least acknowledged that these interfaces exist. I've rarely seen a discussion how to create a revenue stream on many small updates, and how to work with conservative customers - or even acknowledgement that customers might be totally disinterested in downburning scrum sprints. As for your topic, I don't think we are in a post-agile world yet. The hype is over, the first results are in, and the earth shattering change was a coconut leaving a dent on a sunny beach.
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server. -
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
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.
-
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
