dev methods

[dwindlehop]

http://www.shacknews.com/featuredarticle.x?id=621
http://en.wikipedia.org/wiki/Scrum_(development) - for the non programmer

Are Agile methodologies common in the industry? There's been rumblings in my office about scrum and I am now hypersensitive to any mention of it whatsoever. Scrum seems tailor made for games because the definitions of the requirements and finished product are prone to shifting.

Anybody with any experience in this area, either positive or negative?

fixed link - Samwise

[Samwise]

I'm going to move this over to Game Development.

Without reading the article, I'm guessing this is the latest version of "Extreme Programming"?  My experience with that is that it's a buzzword used by software contractors as an excuse not to provide specs and goals up front so that they can milk their clients for all they're worth without ever delivering anything useful.

Like Communism, it all works great IN THEORY.

[dwindlehop]

I didn't even realize this forum existed. Thanks!

Extreme programming can be used in conjunction with scrum, or not. Scrum is a project level of abstraction. The article says the World of Darkness MMOG will be created by multiple small teams of about four people "developing a fixed aspect of the game on a two to four week development cycle." I read in between the lines and saw, "scrum."

[Samwise]

Okay, I just read the Wikipedia article.  It sounds like a load of horseshit.  Half the stuff they describe is common sense, and the other half sounds entirely counterproductive.  (Pointless status meetings are the bane of goddamn getting any work done.)  Also, many of the words used in that article are not real words.  What's "genuinity"?

Please add "genuinity" to the spell checker.  Not.

[Prospero]

I'm certain that is one of Stephen Colbert's. Did you see "truthiness" in there anywhere?

[dwindlehop]

The Wikipedia article has changed since I last read it. I should produce better links.

The explanation I got in my office is that the daily status meeting lasts 10 or 15 minutes and boils down to, "What is keeping you from finishing the sprint?" This would replace the handful of weekly one hour staff meetings I have now. I haven't tried it myself.

The contrasting project management is Alice owns foozles, Bob owns barwons, and Carol owns baznits. Each programmer works in her own area and knows nothing about the other areas. The idea I got from the scrum intro I sat through is that the team does a foozle sprint with all programmers working together, then a barwon sprint next month, and a baznit sprint the next month. And then perhaps the team cycles back to foozles.

I know in my workplace knowledge segmentation means only a very few souls are conversant with any particular hunk of code. We're not producing software as a product, so work tends to require multiple throwaway edits to the same sections as we try different things. These edits are serialized through the same one or two guys right now. Work in a particular area slows or stops when vacations happen. Sometimes I think if it weren't for sabbaticals large-scale knowledge transfer would never happen at all. 

Perhaps knowledge segmentation is fine for games development, though? A friend of mine in defense contracting claimed they were trying to use it to combat turnover, which may be more relevant.

[Samwise]

The explanation I got in my office is that the daily status meeting lasts 10 or 15 minutes and boils down to, "What is keeping you from finishing the sprint?" This would replace the handful of weekly one hour staff meetings I have now. I haven't tried it myself.

A ten minute status meeting generally has about the same effect on productivity as an hour of lost work.  There have been studies on this stuff.  Above and beyond the time lost to the meeting (which is always going to be more than ten minutes because some people are late, somebody else was in the meeting room, someone needs to teleconference in and people can't figure out how to work the phone, someone throws a tantrum and the entire team needs to calm them down), it tends to throw people off their stride and/or decrease morale because it feels like a waste of time.  This all ends up adding up to more than ten minutes of lost work.

The contrasting project management is Alice owns foozles, Bob owns barwons, and Carol owns baznits. Each programmer works in her own area and knows nothing about the other areas. The idea I got from the scrum intro I sat through is that the team does a foozle sprint with all programmers working together, then a barwon sprint next month, and a baznit sprint the next month. And then perhaps the team cycles back to foozles.

If coding was like shovelling sand into piles, that would be great.  Four people can shovel sand into a pile four times faster than one, and four people working on four piles are no faster than four people working on one pile.  However, it is not.  Throwing more people at a project does not make work happen proportionately faster.  Instead of having one really competent coder working on each piece all of the time, you now have four semi-competent people working on each piece one fourth of the time.  And probably getting in each others' way.

To put it another way: imagine a classy restaurant where there are ten good cooks, and twenty good servers.  Now imagine that their manager steps in and dictates that they all have to share all the jobs equally, so you end up with the cooks spending most of their time waiting tables while the servers burn the food.  Sound like a good plan?  Eventually, of course, the servers will learn how to cook and instead of burned food you'll have mediocre food, but that's a best-case scenario.

If you want to avoid the "Bob goes on vacation and the barwons go to shit" scenario, make sure each person has one knowledgeable backup, for insurance against such a situation.  Throwing the entire team at it is overkill, though.

[Prospero]

The problem I've seen with having generalists is that the coders don't seem to get attached to the project. When any bugs you create just go into a hopper and get doled out to the next person who has time there's much less incentive to write bullet-proof code, and I think these is less sense of ownership. If you're lucky your coders will become attached to the overall project and still work to write bullet-proof code, but in experience coders tend to be fairly territorial creatures who don't share territory well.

[Stephen Zepp]

Sorry Samwise, don't mean to be rude, but you have no idea how successful agile/SCRUM development can be when done properly. It obviously doesn't apply to all types of product development, but successfully executed, it can work wonders.

Here's a link describing just how successful it can be when used properly (and by that I mean rapid prototyping to test the validity of an idea before it's too expensive to drop something that's destined to fail) : lessons from Miyamoto, the joy of failing fast and the benefits of using Stage Gate-type processes

That's not the title of the article, but a quote from the summary paragraph--the title would cause nay-sayers to immediately fail to read the rest of the article accurately, since it's called "lessons about failure". One of the key points of an agile/spiral/SCRUM style development process is that you want to fail as quickly as you can, so you can stop chasing bad ideas with more and more money.

For the record, GG is using a Spiral/iterative development model for our next generation engine development. We also use it for internally developed games, and stress it very strongly as the most successful indy game development strategy.

[Samwise]

See, this is why I say stuff like this always comes off to me as half common sense and half craziness.  Tossing bad ideas before you've sunk too much money into them?  Common sense.  Saying that you need to get all your pigs and chickens working on every piece of code at the same time?  Craziness.  I don't see the connection between these things.



Also, "iterative development" is great until it's used as an excuse to flail about wildly without any direction.  We don't need to gather requirements, we're ITERATING!  If we spend a month on something that turns out to have no relation whatsoever to the problem we're supposed to solve, who cares?  We might get it right next month!  Or the month after that!  They're not "failures", they're "milestones!"  Iterating for the sake of improvement rather than for the sake of iteration seems obvious, but people can get so caught up in hopping around and being "agile" that they forget that they're supposed to be moving in a vaguely forward-ish direction instead of from side to side.

Obviously my experiences with agile development and its proponents have been less positive than yours.    More power to the folks who are able to make this "genuinity" stuff work for them, though.

(edit: needed more chart)

[Stephen Zepp]

Heh...like I said, it doesn't work for all projects ;)

With specific regard to game development however, it can be amazing how quickly you can figure out if a particular idea or mechanic is actually fun (at least at some level), as opposed to "sounds cool", but 50 resource-years and 20 million bucks later isn't nearly as fun as it sounded.

One of the key success factors for both GG and myself personally has been the idea of a living design document--why spend weeks making a document describing what a game might look like, when you can spend those two weeks making the game, and actually see it?

From there you can continue to spiral out, or spend a sprint cycle doing formal design documentation/requirements gathering, or drop the idea and move to the next.

[Samwise]

One of the key success factors for both GG and myself personally has been the idea of a living design document--why spend weeks making a document describing what a game might look like, when you can spend those two weeks making the game, and actually see it?

That certainly makes sense, but conversely, why spend a year building a working version of a bad idea that you can shoot down by spending a day sketching out on paper?  (Yes, I have seen this done in the name of "agility".)

I agree that failing fast is a good thing, but coding first and designing second is not always the best way to accomplish that, which is what the proponents of "agility" tend to suggest.  Then again, some ideas are easier to implement than to explain, and for those a code prototype might make more sense.  As you say, it depends on the project.

[Jobu]

We transitioned to Scrum recently where I work. It has it's bonuses.

I personally like the daily meetings. They keep you informed of what everyone on your team is doing. You are allowed to sit in on the meetings of other teams too, so you can get a sense for the direction of your whole project much easier. You feel more integrated and informed in general.

The hardest part we have so far is truly abandoning the old waterfall methods. It's so entrenched in some people's minds, you really really have to hammer in that they are breaking the development pipeline by not following along. If you can't get everyone on board for the new method, it's not going to work well.

Overall, I prefer it. It cuts down on rework, it cuts down on managers asking you to do useless things, it reduces overtime/time wasting, it improves team communication, and in my own sense it improves morale a bit by not feeling like a useless cog so much.

[Morat20]

I could see it working -- with the right people. Heck, I've been involved in agile before -- and it worked, because we had the right people. But I've worked in the industry (software dev, not game dev) to know most people aren't the right people.

Right developers, right managers, right technical leads -- solid, fast, quick to innovate and adjust. Average developers, average managers, average leads? Catastrophe in the making.

I'm of the opinioin that software processes need to be tailored to project goal and to the project workers.

I think our "big project" uses something that's half agile, half evolutionary (call it iterative on speed -- half the deliverable is "Must meet some very rigorous and specific requirements" and the other half is "Doing so in a useful way, where 'useful' is left undefined because the customer isn't sure what he wants). The other small ones use pure agile -- monthly deliveries, highly responsive to customer demands, that sort of thing. But we have small teams, a concentrated knowledge base, a lot of crossover expertise between products, and a very solid test suite built ages ago in the "Cover every use case possible" mode for our biggest project.

[Soln]

I worked for 3-4 years in a real agile dev shop, and then 3-4 years in a fake agile dev shop.  The difference was the former was fast, small teams with responsibility, working to a high ethic, and the latter was when we were "formally" deemed agile and executives starting coveting the title.  There were some other problems, but essentially "agile" don't well is when individuals have responsibility and authority, and it goes poorly when people start worrying about certification.  Black Belts != Scrum Master, unless it's just the title people want.

[Sauced]

Samwise, is your job title "business analyst" by chance?

[Samwise]

No, I'm just a curmudgeon speaking from his own firsthand experience.

I think Soln pretty much hit it on the head.  Competent people with a strong work ethic can make agile development work.  Then again, if your team is made up of nothing but those people, they probably don't need to be told whether they're pigs or chickens in order to get their work done efficiently.

[Sauced]

Just sounds to me like either you've been doing it wrong, or you're in a job that would be marginalized by doing it right.

Honestly, I've tried leading a team that was a little heavy on the types who needed a 200-page requirements document.  They were incapable of solving problems or asking appropriate questions, and it was a horrible disaster.  It doesn't always work, and I stopped being evangelical about it years ago - I just will not work anywhere that it isn't an accepted and encouraged practice and will not hire anyone who doesn't agree.  Simple!

[Samwise]

Just sounds to me like either you've been doing it wrong, or you're in a job that would be marginalized by doing it right.

Neither -- I've been seeing other people do it wrong.  And causing me lots of headaches in the process. 

I've also seen first-hand the value of some things that agile developers decry -- to take an example from this thread, code ownership.  My experience is that code which has one or two "owners" rather than being owned by the entire group tends to get its bugs fixed a lot faster, and to have fewer bugs in the first place.  Partly because you've got someone who knows that code inside and out and can zero in on bugs faster than a team of generalists could, and partly because there's a greater sense of responsibility for things that go wrong in that area.  Code that's owned by everyone and no one tends to have bugs that nobody can track down, unmaintainable hacks, inconsistent coding style, and lots of blame-shuffling.

Now, if your team of generalists is each able to be as familiar with each piece of code as the current specialists are, AND they aren't going to use the distributed ownership as a way to shirk responsibility, that's great.  I suspect that agile development "done right" could be a marvelous thing, but I think doing it right is a lot tougher than its big proponents let on (or even fully understand).

[Sauced]

I've also seen first-hand the value of some things that agile developers decry -- to take an example from this thread, code ownership.  My experience is that code which has one or two "owners" rather than being owned by the entire group tends to get its bugs fixed a lot faster, and to have fewer bugs in the first place.  Partly because you've got someone who knows that code inside and out and can zero in on bugs faster than a team of generalists could, and partly because there's a greater sense of responsibility for things that go wrong in that area.  Code that's owned by everyone and no one tends to have bugs that nobody can track down, unmaintainable hacks, inconsistent coding style, and lots of blame-shuffling.

See, this is where the conversation gets funny.  In my 10 years in the field, my experience has been almost the exact opposite.  Code ownership always leads to more bugs and an unacceptable level of blame-shuffling.  If you don't have code ownership, no one gets to say "I didn't work on that, Samwise did.  Leave me alone.".  When one or two developers are solely responsible for code, if they are not in compliance with team standards and methods, they will create unmaintainable and buggy code.  And as soon as you narrow resposibility, you open to door to a lot of issues that become problems down the road - attrition due to boredom over being siloed, a god complex due to becoming Lord of the Silo, or just having to deal with "vacation/illness/hit by bus" scenarios that cost time and money.

Now, if your team of generalists is each able to be as familiar with each piece of code as the current specialists are, AND they aren't going to use the distributed ownership as a way to shirk responsibility, that's great.  I suspect that agile development "done right" could be a marvelous thing, but I think doing it right is a lot tougher than its big proponents let on (or even fully understand).

It also depends on the software.  I mean, I'd like to have a specialist working on drivers for a surgical laser, I guess.  I work in corporate IT, where in 10 years I've encountered nothing, in Banking, Healthcare, or what I'm doing now ( ) that requires a "specialist" of any kind.

[Samwise]

If you don't have code ownership, no one gets to say "I didn't work on that, Samwise did.  Leave me alone."

See, my experience is that they still do.  The difference is that Samwise (we'll pretend this is some other Samwise entirely, not me, because I am awesome) will then say "It was broken long before I got there.  Go talk to Sauced."  (We'll pretend this is also some other Sauced.)  Then you go ask Sauced about it and he says "I was working with Jobu on that, he knows it better than I do."  Then you get to Jobu and he points you back at Samwise, who has used the precious time afforded by his clever diversion to flee the country.

[Sauced]

See, in your scenario, regardless of what your dev process is... any one who consistently displays that behavior gets reassigned to QA. 

[Samwise]

God, if only.

[Sauced]

I've pulled it off once, when we had a severe shortage in QA at my last job, and I offered a candidate, complete with a cvs log that showed no commits for 3 weeks.

[Margalis]

We've re-assigned a couple of people to QA...

I am a bit suspicious of dev methods in general, just as I am of various business methods that go in and out of fashion, or NFL coaches who are "system guys." There is no one-size-fits-all.

That said, there are certainly some things that work better than others, especially depending on the people involved. Rules of thumb and such.

[Morat20]

I've also seen first-hand the value of some things that agile developers decry -- to take an example from this thread, code ownership.  My experience is that code which has one or two "owners" rather than being owned by the entire group tends to get its bugs fixed a lot faster, and to have fewer bugs in the first place.  Partly because you've got someone who knows that code inside and out and can zero in on bugs faster than a team of generalists could, and partly because there's a greater sense of responsibility for things that go wrong in that area.  Code that's owned by everyone and no one tends to have bugs that nobody can track down, unmaintainable hacks, inconsistent coding style, and lots of blame-shuffling.

That's how it is where I work, because if a bug pops up in what's obviously your code, everyone's basic reaction is 'Oh shit, that's my bug!" -- immediate responsibility and quick and solid fixes. But that's mostly because anyone who didn't have that attitude (who wanted to play 'pass the buck') got shuffled off to another job, that didn't involve development.

Not that anyone "owns" a certain section of code, but we pretty much know who wrote what -- or who was the last person to muck around there, if the author is long gone.

[Sauced]

Keep in mind, as well, that when I say I believe in "no code ownership", that doesn't mean that I don't annotate crappy code and call people on it, and expect to be treated the same way.  If a bug falls in someone's lap that's my fault, I want to be told so I can build better unit and integrations tests and fix it myself.

No methodology replaces a professional work ethic.

[Jobu]

No methodology replaces a professional work ethic.

I need a shirt and a banner that's about 400 ft. long with that on it. Or maybe just a searing hot brand for... certain people.