Agile development or other methods for project organization?

Alex_J

Hey guys, I'm asking for a lot here.

You people who have worked in game or software dev professionally, can you give a rundown of Agile development (or whatever your methodology is) in absolute moron plain english? Just the big principles -- no details -- and how it applies to game development in general?

Anybody using trello to take care of this? What's your boards look like? What's your standing orders for different departments?

Also, any art directors/leads got advice for ensuring punctual and correct delivery of content from subordinates? How to mitigate low-performance or incorrect work? (just practical methods, not soft-skill stuff)

Any links and resource is much appreciated. It's a big, vague question -- any advice is gold for me.

Thanks thanks thanks!

Eric Chadwick

Agile is great. I've been in a few different flavors of it, all were helpful.

Game developers (and most software devs to be honest) think they know better, and try to only adopt the bits of Agile they like. But it's a very solid well-developed system that's weathered a lot of tough dev cycles.

Look it up, it's not hard to find, or to grasp.

For example, searching "agile game development" this is one of the first links
https://marionettestudio.com/agile-game-development-quick-overview/

As for leadership skills, lots has been written already. Hope you find this useful!

http://polycount.com/discussion/134325/leadership-in-the-games-industry

http://wiki.polycount.com/wiki/Game_Industry#Being_a_Developer

Alex_J

Eric Chadwick said:

Agile is great. I've been in a few different flavors of it, all were helpful.

Thanks @Eric Chadwick , great links.

Eric Chadwick

You're welcome.

And you've stumbled across why we don't like spaces in names. To get around this, type the at symbol then put the name in quotes.

@"Eric Chadwick" 

Alex_J

Very illuminating reads.

One thing I am unsure about because I haven't worked with many other people in games is, lots of discussion about keeping plenty of work for people to choose from so they don't get bored. Some mention they tried not to have subordinates doing something repetitive for like, a full week. 

Makes me wonder, what is the average attention span? I know of course its different for everybody, but especially if you work on remote team you kinda need to have some gauge on this? How do you know if somebody is just a lazy-ass or just a normal 3d artist? People I worked with in the past I thought were kind of lazy and infantile in that they constantly needed some motivation to keep going (even afer only a few weeks of work.) But is that just normal? I imagined most the professionals here put in a solid 4-6 hours daily of high focus work and just do that day in day out regardless of their motivation about the work... because it's work and you gotta eat. Is that unrealistic expectation? 

Eric Chadwick

Not unrealistic. Sounds like you might be working with people who are inexperienced.

That kind of crew can work, but not remotely in my experience. You need everyone co-located to build team culture and work ethic, and to train newbies on what it means to be a professional.

We deal with this a bit here, we hire completely inexperienced entry-level artists, some straight out of school, some who have never held a regular job yet. We've realized it requires a three-month intensive training course, immersive in the company, with assigned mentors, team crits, and regular reviews.

Even then people still need coaching on how to perform at a professional level. It's a tough slog for some. But it pays off in the end. We've developed a large crew of very strong talent this way. We couldn't find these people anywhere, we had to invest in developing them ourselves.

I know this may not be a direct solution for you. But you might be in for a world of hurt if you don't buckle down and lay out ground rules, with clear-cut consequences, and then follow through.

Alex_J

yeah makes sense. Something I got to seriously consider and have a plan for before hiring anybody. Thanks for sharing your experience, Eric.

Biomag

I actually made a really bad experience with scrum. It ended up being a chasing the magic-scrum-dragon, where any problem suddenly should be solved with more scrum and scrum training and us talking about scrum instead of the project we were working on - it broke the team and the project failed miserably.

At the end of the day bad decision don't necessarily get prevented by using agile methods, it just becomes a team issue instead of responsability of individuals to make the final call. Basically what Sokrates said about democracy and monarchy applies here as well as people tend to idealize scrum ignoring the human part of teams and group behavior.  And scrum comes with hours and hours of meetings and overhead for everybody. The very same team mentioned before afterwards finished a project on time and overproduced once it in part switched to waterfall planning and individuals organizing parts of the pipeline project. Keep in mind some people don`t want to be responsible or part of the organizational part or planning. They prefer just to work on their specific tasks. Some others just don`t communicate well in groups. And sometimes individuals can faster organize something than going through a group discussion (doesn`t mean they should ask for advice or opinions, but it does not always need a team decision).

It can work great if you are in a responsible team that communicates well - but honestly those teams can make everything work, even bad management decisions. At the end of the day for me any organization method is just a tool and should fit the team & project and not the other way around. So in my humble opinion recognize the strenghts and weaknesses of your team and pick something that helps you deal with it, don`t try to fit everything in a single solution.

Alex_J

yeah that makes sense. I wonder about the application of something like this in a larger studio. I think the work methodology has to fit the environment at large. Kind like introducing some new form of transport into an old city... very hard to do because people are already entrenched in their routines.

it would seem you definitely need people who understand the ideology and are ready to commit to it to make something like this work. And I think it would just be a big pain in the dick to try to force lower-motivation people to put-out in a system that requires heavy communication. But if you are just starting out that's probably the time to really consider what kind of framework you want to design from.

poopipe

You tend to get resistance to scrum/similar methodologies from management teams that are used to working for major publishers.  They're used to having to provide a set list of complete features at set intervals (vertical slices etc.) which is completely at odds with agile development strategy. 
In situations like that it completely falls apart cos you need to commit to agile to make it work.

Fwiw, in my experience (which is pretty extensive in this regard) Level design, code, system design etc. Are all valid cases for agile development but asset/prop production isn't. 

Why?

 You have a very clear goal, the tasks are relatively self contained and don't tend to generate dependencies. 
This is straight up production line stuff, work can be timeboxed pretty reliably and there's really very few surprises.