Agile development sucks ass

[dpidcoe]

XIf you have a bunch of quality devs and a supportive business, you get a lot done because there's less bullshit.

If you don't, then you will crash and burn faster without the tedious checks and balances that are designed to prevent fuckups from escalating.

Pretty much this.

At best, FOTM processes and standards like this are the result of some well meaning idiots attempt to articulate something that worked well for their team (but probably is nowhere near a one size fits all solution). At worst they're just a moneygrab by whoever publishes the standards.

The worst part about the whole thing though is that bads will take the process and run with it, then start throwing up piles of roadblocking bureaucracy, use that to justify hiring more people just to deal with the BS, then use those people to start building their own private empires ("you can't fire me, then who's going to manage all those people I've been managing?") and further mask their incompetence. leave it alone long enough and eventually you end up with an entrenched bureaucracy that does nothing but hassle the people actually making a product for no reason other than to justify their own existence.

[Sponk]

Life Cycle of a Silver Bullet.pdf (3 pages long)

Phase 1: Fresh Start
Envision a little pig in a suit, wiping a bunch of architectural drawings and books off a table.

Phase 2: Executive Dedication and Openness
Envision a little pig constructing a house made of bricks.

Phase 3: Success

Phase 4: Publicity
Envision a little pig proudly holding a book showing a house of bricks on the cover. The book’s title is “The Balle-Argentee Method.”

Phase 5: Momentum

Phase 6: First Replication
Envision two or three other little pigs constructing house of wood.

Phase 7: Confirmation
Envision a collection of books with houses of wood on the cover.

Phase 8: Proceduralization
Envision an entire village of houses made of straw.

Phase 9: Diminished Returns
Envision the village of straw houses starting to crumble, propped up by sticks and invaded by mice.

Phase 10: Blaming the Method
Envision the big bad wolf blowing down the village of straw houses.

Phase 11: Starting Fresh
Envision a different little pig wiping a bunch of books and drawings off his desk. One of the books has a picture of a house of bricks on the cover.

[Yankunytjatjara]

Nice read.

[Frug]

a highly-performing team doesn't need the ceremony surrounding scrum; it has the proficiency to work out something better that works for them.

I love you.

[DaDutchDude]

I love how people go on about "good developers" as if it is something unlimited. The reality is that only 20% of developers are good at what they do, if that. At the same time, demand for for software grows much faster then the number of developers, let alone the number of good developers. The result is that a lot of software development needs to be done by mediocre to bad developers. And that is why the following holds true: "Heroic programming is not a sustainable business practice."

The thing is that the 20/80 rule holds true for most skilled professions. However, a lot of other professions have learned to work around it, where there is still a mysticism, a geek elitism about "the good programmer", where everybody images they fit in that category and if only they were given a chance, if only "management" and / or "the client" wasn't so terrible they would create "good software". It's just a myth, something people need to believe in so they get out of bed and go to work in the morning. The reality is that most developers are crap and in a state of denial about it, and as long as we depend on developers to be good for good software development, the average quality of software will remain crap.

[Mithfindel]

(Sensible stuff.)

There's an anecdote that 60% of drivers estimate that they are better than average. While the mathematician in me notes that this is actually possible depending on how you calculate the average, specially if the rest are simply horrible, one of the problems identified by some authors is similar. The coders are "professionals" who do not need "overhead" to "constrict" their "creativity". Very few real-world projects are small enough to be completed without documentation, and regardless of the method of project management, unless "making documentation" is listed an action item and work is allocated to complete it, documentation is not going to happen. There's a wealth of examples of this using the traditional models (such as waterfall and especially the "code cowboy" methods of jumping on the saddle and hacking away).

It usually doesn't help that the client (in CCP's case would be game designer) doesn't exactly know what s/he wants, can't explain it to the guy whose job is to communicate it to the developers. And that the guy who wrote down what should be done doesn't explain exactly the same thing that was told to him to the software design. The design then adds cool features and sets the coders to work. The coders, of course, have usually never done exactly the same thing, so they need to improvise and as the result of this game of broken telephone we're supposed to have something called "quality software". Where agile jumps in is that there's a built-in procedure to change what is being done in the fly, but this doesn't really change the fact that the more of the software is completed, the more expensive it is to make any fundamental changes. Of course, if the goal is moved constantly, the result is just as bad as if the software was developed using wrong specs to begin with.

[Bartholomeus Crane]

(inb4 Barth wall'o'text)

Vagina

  Spoiler:

There is no silver bullet. Any software development method can work. Any software development method can fail. All dependent on the people who implement it. No method is fool-proof. Or in this particular case, moron-proof.

(edit: I was pointed to this thread. Someone here still actually plays this game?)

[Evelgrivion]

(inb4 Barth wall'o'text)

Vagina

  Spoiler:

There is no silver bullet. Any software development method can work. Any software development method can fail. All dependent on the people who implement it. No method is fool-proof. Or in this particular case, moron-proof.

(edit: I was pointed to this thread. Someone here still actually plays this game?)

Here as in participating in the discussion, or just reading? If the former, I don't know if anyone complaining about Agile is still playing the game. At this point, there's little purpose in talking about CCP's past, death-spin inducing practices unless they relate to the current state of organizational processes at CCP.

[Waagaa]

Seen on slashdot:

http://developers.slashdot.org/story...-for-lazy-devs

We recently got a copy of a new Voke analyst report on Agile, and the firm basically blasts the movement from top to bottom. Some highlights: 'The Agile movement is designed to sell services. ... Out of over 200 survey participants, we received only four detailed comments describing success with Agile.' 'Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance. ... Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.' So did the analysts just talk to the wrong 200 people?

So is this one of the reasons that CCP managed to fail to redevelop old shit for years and years.



(inb4 Barth wall'o'text)

No, shit devs will create shit, doesn't matter which method you use.
Development methods differ in ways in which they keep the business (customers) in the loop. In that regard, Agile (Scrum) is way better at managing and delivering customer/business expectations than other methods.

[Waagaa]

XP is termed a 'self-reinforcing system'.

aka 'house of cards'.

If you have a bunch of quality devs and a supportive business, you get a lot done because there's less bullshit.

If you don't, then you will crash and burn faster without the tedious checks and balances that are designed to prevent fuckups from escalating.

In that regard, agile is very much like Ruby and other languages of its ilk, compared to statically-typed verbose languages like Java. If you're good, it increases productivity. If you aren't, it impedes it.

IMO, a lot of the recent issues with XP is due to mainstream acceptance (with attendant mouth breathers) highlighting resiliency issues that self-selecting early adopters avoid because they're not terrible anyway.

The existence of Scrum is actually a telltale sign - a highly-performing team doesn't need the ceremony surrounding scrum; it has the proficiency to work out something better that works for them.

tldr; scrum is for teams full of bad people who aren't good enough to do agile properly without strict rules.

Meh, 15 minutes a day isn't a huge investment and it's a good ritual. It's also fun, even for devs who are communicative by themselves (RARE!) and don't need to be told to tell what they're doing.
I have a pretty ace team going atmo and our scrum rituals (standup, planning, estimation, retros) are hardly needed, but they're also fun! And fun is important too. And even then sometimes the 15 minutes / day saves us 2 hrs/week because we happen to hear something that we didn't because someone had a day off orso. That's the investment paid back instantly.

[Waagaa]

Then again, TDD is a much more important method than Scrum.
And without TDD, agile is a bad method.
I'm pretty sure CCP doesn't even know what TDD is, judging by quite a few years of EVE patch experience.

[florestan]

Discussions on agile development always come down to "no true scotsman" arguments - every failure of agile is attributed to the business in question not having implemented agile correctly, while every success of a business that has lifted some ideas from agile is attributed to the methodology.

[the_phage]

So I once worked for a large SaaS company a few years ago before, during, and after its wholesale conversion to Scrum/Agile. The tech side of this company had 3 major and fairly typical departments - the Devs who worked on the software platform, the QA department, and Operations, which was the part I was a member of and this held the systems (my forte), networking, data center, and DBA guys. All in all about 250 people constituted these entities.

Each major area of our SaaS platform was divided into their own Product Scrum teams, with their own Product Owner. So UI was its own team. Core was its own. There was one for the API, another for the distributed filesystem, and so on. Any given dev/ops/QA dude could be involved in multiple of these Scrum Teams (for example, prior to my leaving I was concurrently on 4 teams and Scrum Lead for 2 of them, each with their own 15 minute daily stand-up meeting and monthly Scrum Reviews (so a sprint for us was 1 month long)

When the conversion to Scrum started, everyone looked at it like it was a pile of fetid elephant diarrhea. As you can imagine, any kind of bureaucracy is an anathema to most techies, especially for operations-oriented ones who tend to fight unscheduled fires most of the time. But orders were orders and we had to adhere.

The first months were a disaster. People were not very committed to it and everyone soon figured out that if Scrum was good for anything, it was a great way to sandbag issues. For example, I found a pretty big issue with how a certain, latency-sensitive part of our app was reading files (8 bytes per call to read() on multi-MB files.) This tanked file retrieval performance in a very user-visible way, as well as caused undue stress on our storage. When I went back to the Scrum team responsible for this section of code and politely asked that they fix this fast, their reply that the task needed to be put on their backlog as a "story" and they will decide whether to act on it during their next Scrum Review, three weeks away.

Prior to Scrum, I'd find a dev and we'd spend a few hours figuring out how to fix something and commit a change to be tested and passed on to the daily QA cycle, and then to a nightly code update. Fixing issues (which was my department's raison d'être after all) became a cumbersome process of waiting and cajoling. Devs, for the most part, stopped wanting to deal with fires and developed a desire make their Scrum Teams as visible as possible to management by belting out new features. Bug fixing became secondary at best. Shit had to be major broke (ie, customers threatening to leave or applying pressure to management directly) for a problem to be addressed.

So as I have watched CCP, I see signatures of the issues I observed at this old company I worked for. It would appear that CCP has gotten better over the past year and certainly in the past half-year, but it really does take active management to keep the balance between break/fix and product development. I hope they can continue to manage it.

/T

[W0lf Crendraven]

Totally not understanding what you guys are talking about! Can someone sumarize what is beeing talked about for someone without any idea of programming or developing new software and assorted computer stuff (i know how to operate windows which for me is enough )?

[Sponk]

http://en.wikipedia.org/wiki/Agile_software_development

http://www.agile-process.org/

I have talked to four of the authors of the Agile Manifesto. Nice guys.

[Bartholomeus Crane]

Someone here still actually plays this game?

Here as in participating in the discussion, or just reading? If the former, I don't know if anyone complaining about Agile is still playing the game. At this point, there's little purpose in talking about CCP's past, death-spin inducing practices unless they relate to the current state of organizational processes at CCP.

Here as in FHC obviously.

I don't care enough about it anymore to talk about CCP's past (or present for that matter). But wasn't it you who said that EVE was all about the stories? EVE would be dead without the stories?

Well, whenever I stop by in the EVE segment of FHC I find some quack threads and a lot of old stuff with some +1 movement. So who cares about CCP's current state of organizational processes, agile or not. Where are the stories?

Meh ...

[Evelgrivion]

Someone here still actually plays this game?

Here as in participating in the discussion, or just reading? If the former, I don't know if anyone complaining about Agile is still playing the game. At this point, there's little purpose in talking about CCP's past, death-spin inducing practices unless they relate to the current state of organizational processes at CCP.

Here as in FHC obviously.

I don't care enough about it anymore to talk about CCP's past (or present for that matter). But wasn't it you who said that EVE was all about the stories? EVE would be dead without the stories?

Well, whenever I stop by in the EVE segment of FHC I find some quack threads and a lot of old stuff with some +1 movement. So who cares about CCP's current state of organizational processes, agile or not. Where are the stories?

Meh ...

There's some entertaining propaganda warfare going between the 0.0 guys, but truthfully, the fundamental game design problems with 0.0 remain; there is no meaningful activity between solo work, the occasional forced Incursion distraction, and sovereignty warfare; it's very much a scenario where you bring everyone, or you bring no one. The sheer throw-weight of capitals, combined with the lopsided distribution of ISK, are major contributors towards the gestation of today's, fundamentally boring, nullsec combat sandbox. There are plenty of battle reports, plenty of dead capitals, and plenty of dead super capitals. There are thefts, there are wheelings and dealings, there is treachery and there is deceit; aside from the ever evolving propaganda meta-game, there's essentially nothing going on that we haven't seen before.

Worse yet, an increase in scale is not viable; CCP game designed themselves into a corner once before, and it's less than advisable to do it again.

[Bartholomeus Crane]

Someone here still actually plays this game?

Here as in participating in the discussion, or just reading? If the former, I don't know if anyone complaining about Agile is still playing the game. At this point, there's little purpose in talking about CCP's past, death-spin inducing practices unless they relate to the current state of organizational processes at CCP.

Here as in FHC obviously.

I don't care enough about it anymore to talk about CCP's past (or present for that matter). But wasn't it you who said that EVE was all about the stories? EVE would be dead without the stories?

Well, whenever I stop by in the EVE segment of FHC I find some quack threads and a lot of old stuff with some +1 movement. So who cares about CCP's current state of organizational processes, agile or not. Where are the stories?

Meh ...

There's some entertaining propaganda warfare going between the 0.0 guys, but truthfully, the fundamental game design problems with 0.0 remain; there is no meaningful activity between solo work, the occasional forced Incursion distraction, and sovereignty warfare; it's very much a scenario where you bring everyone, or you bring no one. The sheer throw-weight of capitals, combined with the lopsided distribution of ISK, are major contributors towards the gestation of today's, fundamentally boring, nullsec combat sandbox. There are plenty of battle reports, plenty of dead capitals, and plenty of dead super capitals. There are thefts, there are wheelings and dealings, there is treachery and there is deceit; aside from the ever evolving propaganda meta-game, there's essentially nothing going on that we haven't seen before.

Worse yet, an increase in scale is not viable; CCP game designed themselves into a corner once before, and it's less than advisable to do it again.

Thanks for the update.

So, I guess, fundamentally, nothing has changed on the game design/gameplay front then. It just looks a bit better now. CCP still tinkering along the edges, concentrating on the presentation, with the heart of the gameplay still the same old boring stalemate as before. Sounds like no real change for one, two, even three years: blob, blob, blob. But I guess some of the remaining aspies crowing about how much they won or lost during yet another inconsequential blob battle no one really cares about is what goes for 'stories' now. OK.

Whatever. Seems to me the picture is still the same: CCP created this massive fundamental game design problem for themselves, and they haven't got a clue on how to deal with it. Or indeed, seem to have much inclination to do so. Still much easier to just add more shiny stuff, some MT swag, and more crud to complicate things even further. Agile or not agile, who cares, as long as it is short-term and looks good in a video. Couple of non-committal dev-blogs about some vague ideas for the far far future, and then there's no need to withdraw further funds from the myriad of things CCP is really interested in.

Fine, you lot have fun with that then ...

[ry ry]

http://en.wikipedia.org/wiki/Agile_software_development

http://www.agile-process.org/

I have talked to four of the authors of the Agile Manifesto. Nice guys.

I proposed to my employers that if they put me up in Aspen for a month, i could come up with a better programming methodology.

they declined

[Evelgrivion]

Thanks for the update.

So, I guess, fundamentally, nothing has changed on the game design/gameplay front then. It just looks a bit better now. CCP still tinkering along the edges, concentrating on the presentation, with the heart of the gameplay still the same old boring stalemate as before. Sounds like no real change for one, two, even three years: blob, blob, blob. But I guess some of the remaining aspies crowing about how much they won or lost during yet another inconsequential blob battle no one really cares about is what goes for 'stories' now. OK.

Whatever. Seems to me the picture is still the same: CCP created this massive fundamental game design problem for themselves, and they haven't got a clue on how to deal with it. Or indeed, seem to have much inclination to do so. Still much easier to just add more shiny stuff, some MT swag, and more crud to complicate things even further. Agile or not agile, who cares, as long as it is short-term and looks good in a video. Couple of non-committal dev-blogs about some vague ideas for the far far future, and then there's no need to withdraw further funds from the myriad of things CCP is really interested in.

Fine, you lot have fun with that then ...

It remains to be said that my posts are nothing more than my opinion; I remain open to counterclaims from those who are actually playing in 0.0, especially if they are having fun.