Slashdot Mirror

Seems that could be an interesting solution to your problem. More info here:

http://www.agilealliance.com/ (see the article library and the Agile Manifesto for more info).

It ofcourse does depend on what type of projects you are in, I would not recommend this if you make critical applications that could endanger lives - but seeing your post I think you don't have that restriction :)

Hmm, I'm not a producer-type, so I wouldn't count myself as any sort of spokesperson for this stuff. Wikipedia's article has a fair number of links, though many of them seem to be simply to conference abstracts. Agile Alliance might be a better resource: they have user stories. Most of the success stories and case studies I've read have been in books about Scrum, specifically the first two on this page.

Personally, I've had varying degrees of success. A friend at a 10-person startup is having a lot of success with daily 15-minute standups and 30 day cycles, but then, how much does it really stretch your process when you only have 10 people? We successfully used some XP methods at Homestead, but I don't know whether we'd be counted as agile, overall. TDD didn't work out for us very well. Short cycles worked really well in some cases. I don't think anyone from there wrote an article on our experiences, though it would have been useful.

Regarding game-specific success stories, I don't have anything for you. Does Valve's cabal system count as agile? Does it count as a success? The most successful games I can think of pretty much all shipped horribly late. Also problematic: the largest, most formalized efforts to improve software development methodologies have taken place outside of games, and the products are different enough that straight ports don't seem to work. It feels like we're having some successes and some failures with the Scrum adaptation we're using right now, but it's too early to tell-- it can't be counted as a success if we haven't shipped.

Hmm, I'm not a producer-type, so I wouldn't count myself as any sort of spokesperson for this stuff. Wikipedia's article has a fair number of links, though many of them seem to be simply to conference abstracts. Agile Alliance might be a better resource: they have user stories. Most of the success stories and case studies I've read have been in books about Scrum, specifically the first two on this page.

Personally, I've had varying degrees of success. A friend at a 10-person startup is having a lot of success with daily 15-minute standups and 30 day cycles, but then, how much does it really stretch your process when you only have 10 people? We successfully used some XP methods at Homestead, but I don't know whether we'd be counted as agile, overall. TDD didn't work out for us very well. Short cycles worked really well in some cases. I don't think anyone from there wrote an article on our experiences, though it would have been useful.

Regarding game-specific success stories, I don't have anything for you. Does Valve's cabal system count as agile? Does it count as a success? The most successful games I can think of pretty much all shipped horribly late. Also problematic: the largest, most formalized efforts to improve software development methodologies have taken place outside of games, and the products are different enough that straight ports don't seem to work. It feels like we're having some successes and some failures with the Scrum adaptation we're using right now, but it's too early to tell-- it can't be counted as a success if we haven't shipped.

Not surprisingly, that's why Agile approaches (XP, Scrum, ...) work more efficiently than more traditional, dead-tree oriented approaches. They emphasize compressing that long end-to-end chain, as much as possible, as well as focusing on actually solving the problem through co-operation.

• Hire a hard-ass financial controller. Make sure someone asks all the hard questions about how growth gets funded - don't rely on the customer-facing folk, their job is to be gung-ho.
  
• Start out with a scaleable development process; I'd recommend something like Scrum or eXtreme Programming. The point is that when it comes time to scale up the development team, you don't want to find out that the old ways of getting stuff done don't work anymore, and you have to invent a bunch of new processes at the same time as getting your new team members up to speed.
  
• Start acting like a big company in other ways. Make sure you've thought about (and written down) the things that non-owners tend to care about - how you reward people, how you measure their contribution, what your standards are for performance and contribution.
  

• Hire a hard-ass financial controller. Make sure someone asks all the hard questions about how growth gets funded - don't rely on the customer-facing folk, their job is to be gung-ho.
  
• Start out with a scaleable development process; I'd recommend something like Scrum or eXtreme Programming. The point is that when it comes time to scale up the development team, you don't want to find out that the old ways of getting stuff done don't work anymore, and you have to invent a bunch of new processes at the same time as getting your new team members up to speed.
  
• Start acting like a big company in other ways. Make sure you've thought about (and written down) the things that non-owners tend to care about - how you reward people, how you measure their contribution, what your standards are for performance and contribution.
  

How the heck can I write good when I am hardly told what the application is supposed to do? So I write something, it doesn't take into account the missing details that I asked about. Those get defined two weeks after the thing is supposed to be done. The app turns out terrible and then the powers that be want to know why it has problems. It is incredibly frustrating.

Requirements change. Users don't know how to specify things. They often don't want what they think they want, and even when they do it may be obsolete or of secondary importance before you're done implementing it.

Your #1 job as a programmer is to write useful code--code that helps your customer/business/department--which usually (in my experience) means that your skill in determining requirements and working with the customer to refine them is far more important than your actual programming chops. Relying on an external project manager to gather requirements and define scope is usually disastrous.

This is a major part of the XP ethos and especially the agile programming philosophy ("Welcome changing requirements, even late in development" is one of their primary principles...). The sooner you develop softare practices that realize this and plan for it, the better off you'll be.

see e.g. the Agile Alliance article repository for stuff to think about.

Sumner