Anachronic wrote:This whole thing with the DHH has got me wondering about the best organizational structure for a successful indie dev studio.

This is an extremely interesting topic you raise, and I suspect that the answer may vary somewhat from project to project. If you're curious, I can give a bit more insight into how Voyager Games works, although I'm a little bit too sleepy to write very much tonight. But if you're curious, I'd be glad to share what has worked well for us on this particular project!

I'm starting to think that a team where everyone contributes to all aspects of the game's development (including marketing, development, testing, maybe even art and sound/music) is the most likely to succeed.

Your instincts serve you very well here. Everyone has a specialized role on the Voyager Games org chart, but it's of paramount importance to keep everyone pulling in the same direction with respect to the project as a whole. In our case, there's a ton of specific communication that goes on between individuals regarding their specific jobs and responsibilities. For example, I have plenty of one-on-one email chains with Torvus about specific aspects of Outer Colony's lore, and similar email chains with Brian that are all about sound effects.

It's very important, though, that everyone understands what the game is all about, both from a stylistic perspective and with regard to our overarching objectives. We all have to be pulling in the same direction when it comes to the game's "feel", so there are regular email threads that are distributed team wide. Our specific team consists of a bunch of specialists, rather than generalists, so it would be tricky for all of us to contribute on all fronts. This is to say that I can't produce any art myself, and I've got to rely on Jericho and Jennifer define the game's visuals. But defining the character of the game, which is one of its most important aspects, is very much a joint effort to which everyone contributes, and this is why it's so important to keep everyone on the same page at the higher levels of the project.

It's not just a matter of me drawing up specifications and having robots implement components that satisfy the stated requirements, but it's really a joint sort of effort. Torvus, Imperator, and Brian can probably tell more about this from their perspectives, but I try to give them all a great deal of autonomy to complete tasks the way they deem best. I think that this is how you can best utilize someone's skill set in a creative environment.

It's a bit of a departure from the Agile team formula although I'd really love to work in an Agile environment... kinda like having a core team of 2-4 scrum masters/generalists. Not really sure how that would work out could lead to some serious conflict.

Ooooooooo, agile and scrum. I could write a bunch more on these topics, but I specifically avoid these terms when defining our process at Voyager Games. I do incorporate some aspects of agile development (and there are even a few principles of scrum that are sorta' a part of what we do), but I've seen agile processes and scrum done wrong, to the detriment of an organization, more often than I've seen them done right. Maybe I'm old school, but I'm not afraid to embrace a classical, heavyweight methodology, especially on a project like Outer Colony. Ironically, agile methodologies are the ones that are the hardest to pull off and require the most discipline and expertise on a team. They're very hard to do right, and I think they only work well in a team that's comprised entirely of highly experienced experts.

Administrator wrote:Ooooooooo, agile and scrum. I could write a bunch more on these topics, but I specifically avoid these terms when defining our process at Voyager Games. I do incorporate some aspects of agile development (and there are even a few principles of scrum that are sorta' a part of what we do), but I've seen agile processes and scrum done wrong, to the detriment of an organization, more often than I've seen them done right. Maybe I'm old school, but I'm not afraid to embrace a classical, heavyweight methodology, especially on a project like Outer Colony. Ironically, agile methodologies are the ones that are the hardest to pull off and require the most discipline and expertise on a team. They're very hard to do right, and I think they only work well in a team that's comprised entirely of highly experienced experts.

It sounds like you've got a good system going with the OC team! Sorry for my long absence from the forums. I'd be interested in any examples or lessons you have about Agile going wrong. I took an Agile class right at the end of getting an associate's certificate in software dev from BCIT, and it was the funnest class of the whole program. My previous classes had touched on Agile a little bit but seemed more rooted in Waterfall, so it was kinda sad to be introduced to something pitched as a far superior system right at the end. Knowing what I know now, if I could do it again, I would probably have taken that class first.

I'll admit to using a less formal method for my personal projects though; mostly just notepad docs with lists written as features/requirements rather than user stories, and without story points assigned. I made a formal design doc for my first game but never again. Plus I don't hold Scrum meetings with myself... When I first talked to the folk at the DHH they said they were using Waterfall but were interested in Agile, and now that the lead has been hired I guess he has started the switch to Agile. I think that's probably a good thing, but it looks like walking into a shop in transition so there might be some hiccups. Part of my pitch for hiring the coop student as well was to have a more complete Agile team (Scrum Master, Product Owner, Tester). Considering that I have just informal game dev experience and the other guy is a student, we're certainly not going to be a team of highly experience experts so maybe your experience could help us avoid a few pitfalls...

Anachronic wrote:I'd be interested in any examples or lessons you have about Agile going wrong. I took an Agile class right at the end of getting an associate's certificate in software dev from BCIT, and it was the funnest class of the whole program. My previous classes had touched on Agile a little bit but seemed more rooted in Waterfall, so it was kinda sad to be introduced to something pitched as a far superior system right at the end. Knowing what I know now, if I could do it again, I would probably have taken that class first.

This is a topic I would absolutely love to discuss in tons of specifics, but I don't know if I want to start writing too thorough a reply, since I suspect that I'll be asleep soon.

I've worked in 3 outfits that were self-proclaimed "agile" shops. What these lead engineers really meant when they said they adhered to an agile process, though, was that they had no process at all, and everything was just wackyshack. Any agile methodology done correctly is not everyone doing whatever they want whenever and however they want to do it. It's not code whatever you feel like and jam it into production whenever. The problem I've seen most is that many developers think that this free-form madness is agile, and the term "agile" is just used as a code word for undisciplined and incompetent.

The whole point of agile processes is to ease some of onerous constraints imposed by heavyweight methodologies, and to shorten the amount of time between releases, so an organization can better adapt to changing business needs. It's about reasonable shortcuts that can make for more efficient operations on certain types of projects and with certain types of teams. As such, even when done right, agile processes need experienced, talented personnel to work properly.

What most software teams don't realize is that agile actually requires much more discipline, much more experience, and much more talent to pull off than heavyweight methodologies. Responsibility for doing things right is shifted away from compliance with formal mandates and is placed in the hands of individual developers. If any of your individual developers are idiots, screw-ups, or just inexperienced, it's not going to work, because they're not going to handle things correctly themselves, and they're going to produce poor results. Heavyweight processes are actually far better for teams with junior personnel or less-than-elite talent bases, because they impose the discipline. They keep everything on track. They provide the framework that rank and file developers need to be productive. When that framework is removed, only the best kinds of software engineers can keep their heads above water.

Furthermore, lots of "things" that people call "agile development methodolgies" are not, I repeat, absolutely are not software development methodologies. Scrum is a prime example of this. If you ask a chief engineer about their software engineering methodology and they start talking about scrum, you've got a problem. Scrum is a project management framework. It's a mechanism for managing personnel, keeping track of what they're doing, and facilitating communication on teams - it's content agnostic, and has nothing to do with building software. Employing scrum is not imposing any kind of order or framework for building software. It's tangentially related, but that's as close as it comes. Scrum has nothing to do with determining technical designs or articulating business requirements or QA'ing new releases.

I worked in precisely such a place, where management would say, "We use scrum. We're agile software developers!" Meanwhile, there's no method for scoping sets of deliverables, I never saw a single formal, business requirement, no one designs anything beyond thinking about it as they code it, and you generally just had a disorganized gaggle of coders hanging around their cubicles, coding whatever, moving it to production whenever, without any practical oversight of engineering framework to govern what was going on. Needless to say, it was a dumpster fire. The codebase was an embarrassment, virtually nothing worked, every minor feature took ten times longer than it should've to implement, the architecture was a byzantine, incomprehensible nightmare-mess. It was a really difficult environment to navigate.

But we were having our daily standup meetings! We were spending hours on Fridays delivering our weekly work presentations! We were checking all the scrum boxes, doing an A-OK great job! No, we weren't, because the end product was a disaster, everyone was fighting everyone all the time, the environment was bitterly toxic (because of nothing working, leading to negligible sales, leading to management freak-outs, leading to inordinate stress, leading to more childish behavior) - we were doing scrum, alright, but that has nothing to do with building good software.

Management, of course, was up in arms at all times about the problems that they were experiencing, but when a consultant would try to discuss the fundamental nature of the problems the organization had (the lack of any engineering control), it would be me with a statement like, "We are using scrum. That is never going to change." I'm not talking about abandoning scrum for project management - I'm talking about imposing engineering rigor. I'm talking about basic code reviews. I'm talking about formalized designs. I'm talking about no more single developers doing completely unchecked releases on their own.

The whole point of this example is just to convey that "agile", when it's used as a code word for no engineering rigor at all, is a recipe for disaster. Whenever you have a middle manager that just attends a scrum course and is then put in charge of a software shop, this is going to be the result. And this is what a lot of agile is, out in the world.

I find it really funny that waterfall is used as a dirty word, among educators especially, when it comes to software engineering. Whether a team embraces it or not, you cannot build software without waterfall. You can't write code without figuring out a design. You can't figure out a design without understanding how the system needs to work. You can't figure out how a system needs to work without understanding its requirements. You can't understand its requirements without having a general idea of what you're aiming to make.

As such, nearly all methodologies are, themselves, running through all the waterfall steps! The only difference is that they're doing it in smaller iterations. I kinda' hate the term agile, because it's such a corporate-y sort of buzz word. It's inherently good, because of the word's general meaning. Of course you want to be agile! Why the hell wouldn't you? What kind of idiot wouldn't want to be agile? Any argument against agile immediately sounds dumb, and the middle manager that doesn't know anything other than what his 3 week agile seminar told him retorts with a variety of straw man arguments about team cohesion and other stupid lunacy.

Nearly all practical implementations of agile should just be called "iterative waterfall with less formality", because that's what they really are. If we called them that, instead of agile, it'd be much easier to have frank and sensible conversations about the merits of agile and BDUF approaches on different projects and different environments. Sometimes agile is the right way to go! Sometimes BDUF is. Every experienced engineer I've worked with in a BDUF environments acknowledges that, for some sorts of projects, agile approaches yield benefits. But the standard bearers on the agile side present their approach as infallible and universally applicable. It's just because they can sell more seminar sessions that way.

So, that's my nutshell take on real world experiences involving agile shops. So many of the people who are talking agile vs. heavyweight don't even understand what the two terms mean with respect to software engineering, and these people are often the senior management making the decisions, which is a recipe for disaster. Ultimately, organizations are about personnel. They need talented personnel making decisions they understand, and they need senior VPs who, despite their titles and salaries, can sometimes acknowledge that they don't know about a domain and can delegate decision making authority to someone who does. If that basic criterion isn't satisfied, little else really matters.

Now, I don't want this to sound bitter, here! Quite the opposite. The kinds of situations described above are what software engineering consultants are made for, and these are the environments where the biggest, most positive impacts can be made! And you only need two things to turn the worst disaster into a technical success -1. An organization that's willing to improve.2. The right consultant.

So I got into some territory that sits conceptually above the agile vs. heavyweight discussion, just to highlight what an organization needs to understand this decision, and how many outfits go off the rails. Above all else, when considering agile vs. heavyweight for a project, understand what it is you're deciding on, because you'd be shocked how many industry professionals with 6 figure salaries really have no idea what agile means with respect to software development.

Anachronic wrote:So I got into some territory that sits conceptually above the agile vs. heavyweight discussion, just to highlight what an organization needs to understand this decision, and how many outfits go off the rails. Above all else, when considering agile vs. heavyweight for a project, understand what it is you're deciding on, because you'd be shocked how many industry professionals with 6 figure salaries really have no idea what agile means with respect to software development.

Thanks! That's very useful information. I never really thought about the distinction between SCRUM as a project management methodology and the need for a separate development methodology... cause I'm a rookie. One of my profs did describe Agile as a series of mini-waterfalls... like what you describe with the term iterative waterfall. I definitely seems like it helps to have a set (formal) process in place for how feature requests, or user stories, or business requirements, or whatever anybody wants to call them, actually get implemented into new releases. Despite being a rookie I can at least see how certain informal processes could be disastrous... like not writing things down. What's that, you're gathering all your QA feedback via Skype calls? NOOOOOOOOOOOOO Maybe I'm in the wrong here and please correct me if I'm being stupid but like, mock up a basic Word form or make a forum, or at least something geez.

Anachronic wrote:Despite being a rookie I can at least see how certain informal processes could be disastrous... like not writing things down. What's that, you're gathering all your QA feedback via Skype calls? NOOOOOOOOOOOOO Maybe I'm in the wrong here and please correct me if I'm being stupid but like, mock up a basic Word form or make a forum, or at least something geez.

Right on, man! Your insights serve you well, and those sorts of smarts and perceptiveness are at the core of any good developer. Being new to the office environment is not a problem at all! You know a hundred times more than I did when I stumbled into my first cubicle, and there are oodles of things you know right now that I don't. For example, publishing software to an app store? I have no idea how to do that, but you do.

Anybody can accrue specific sorts of experience, and everyone does over the course of their career. But it's the smarts at a person's core - that's the piece that doesn't change, and that's the cap on how good an engineer one can become. The capacity to learn new things and to intelligently assess situations - that's the most valuable part of a team member, and I really tried to convey that when acting as a reference for you, just because I've seen it from you plenty of times in our interactions.

This is a prime example - you immediately get what I mean when I describe the difference between a project management framework and a framework for building software. The two things are often related, but not the same. Three quarters of the professionals I've encountered can't even engage in this sort of conversation. I either get furrowed brows, consternation, and incoherent (yet obstinate) disagreement, or I get a passive nod without any real understanding.

And writing stuff down is most always useful, and not even for the most intuitive reason - having a record, having documentation is nice, and even if a design becomes outmoded, the written record of how / why it was created always remains useful. I don't buy the agile argument that all documentation quickly becomes outmoded and useless, because I've used old designs to figure out code several times in my journey.

The best thing about writing something down, however, is the need to fully articulate the thoughts and conveying them to the rest of the team. Having an idea in your head is nice, but often, what might seem clear in my head doesn't make as much sense when I try to actually write it down. The act of writing something down forces it to be realized and considered more thoroughly than just having it in your head. Simply by writing something down myself, 95% of the time I can immediately tell if it's going to pass muster when reviewed by other engineers. The act of writing things down just formalizes whatever you're doing, and it forces you to create something that's structured and coherent.

That alone goes a long way toward keeping yourself and your project on track!