shivver | You're doing it all wrong... (Reply)

You know, I really like my main project at work. It's a little game and it actually works pretty well. It's nothing revolutionary or anything. An alpha version has been released so that we can watch how the players use it, and that's pretty cool. Thing is, I'm getting really fed up with working on this project. The processes and people are a complete mess.

Whining cut below...

My company is a small studio that does development work for outside clients. Rather than doing the traditional "you pay us, we write code" client/dev relationship, our company sets up a closer relationship with the client company, partnering with them so that both will sink or swim. One of the perks of this is that the teams are supposed to work together more, rather than going with the "they're the client, so we do whatever they tell us, no matter how stupid it is" attitude.

This whole setup is just not working, and it's not just the client's fault. The ideal setup would be that the client has a firm idea of what they want to make and they provide detailed descriptions of what to create in a timely manner, and we take that and create what they want. In practice in most places I've worked, the client kinda knows what they want and they wave their hands at us and describe it, and we ask questions until we figure out what it is they want, and then we write that down and create it. Not a great process, but we get there eventually.

We're not even at that point with this client.

The main game designers have no idea what they're doing. They change focus week-to-week, and ask for small bits of not-yet-finished systems, rather than design the whole thing. They hold feature kickoff meetings, which is where they're supposed to bring in the finished specs and mockups and say, "This is the thing we want to make", but they come in and go, "Well, we kinda want players to play more, so we thought maybe we should do X, what do you think?" When they finally decide what they want, they provide two-sentence descriptions of things and an image, and we're left to invent the details ourselves.

Their UI designer is amazingly inept. In addition to having no idea how people actually use software (for example, half the controls in the game have hover-over tooltip help, the other half have popups appear when you click the item, but only when it's disabled), he only produces happy-path mockups. For example, he needed to design a fill bar that displays a timer and empties as it counts down. His mockup was the filled bar - so we had no idea what a half-filled bar would look like, or what the time display looked like.

Then we've got problems on our side.

The engineering manager has two set-in-stone rules. One: Developers work in their own groups, with no cross-training on related systems. This means that the frontend devs (the ones that make the game that you see) have no idea how the backend (the server and database) works, and the backend devs create their systems without any concern about how the frontend will use them. Two: Developers must work nose-to-the-grindstone as much as possible, minimizing meetings and other "distractions", as he calls them, as much as possible.

What this means is that the devs have no idea what the big picture is, or even how individual parts fit together, and no one talks to each other or asks questions. If a mockup comes from the UI guy with a "10" in a spot on the screen, the devs will put a 10 there, even if it's obviously a placeholder number - because they have no idea why that number's there and they won't ask.

Then there's the project manager. He tries to distill the trash we get from the designers into something the devs can work with - unless he's fed up (which is often) and then will just barf whatever he feels like. He makes little effort to improve the product or the process, preferring instead to do exactly what the client asks in order to prove to them with the final results how bad the idea was.

So, in a nutshell, this is our typical feature development process:

Day 1: Ten-day sprint starts, during which the feature is supposed to be developed, tested, and released.
Day 2: Designers calls a meeting to start the feature, to tell us what the feature will be and how it will look. They tell us they're hoping to do X and want ideas on how to do it, then ignore most of what we suggest in favor of their pet ideas. Meeting ends with three or four possible paths.
Day 3: Project manager creates a set of slips with vague instructions on what to create, and sends them to the dev.
Day 4: Project manager asks designers for specs and mockups, because they won't make them if he doesn't remind them.
Day 5: Hastily-created, inaccurate mockup arrives. You really expected a spec - or even just a feature summary - to ever be written?
Day 6: Backend half of the feature arrives. Our backend devs are really good, and they don't need mockups to do their work.
Day 7: Frontend half of the feature arrives. I test it, and return it because it's buggy and it does what the mockup shows but not what was actually intended (since the intentions were never defined).
Day 8: Frontend half arrives again. I test it. It usually works at this point, but the shortcomings of the original design are now painfully obvious. Project manager shrugs and says, "That's what they wanted."
Day 9: Testing for release. Designers look at the finished feature and say that really doesn't do what they wanted it to do. Slips are written for the work of changing the feature to do what they want.
Day 10: Update is released to the public. Designers start thinking about the next thing they want to do. Slips written on the previous day are never looked at again.

I think the most frustrating part of this whole thing is Day 7, because it is entirely preventable. My company prides itself on its Agile development methodology when its process isn't Agile in the least bit and this whole thing proves it. If we were following Agile, designs would be written and reviewed by the entire team, refined and estimated for amount of effort, and ready for the sprint on Day 1. Everyone on the team would know what the feature is, how it works, and how their bit fits into the whole. The devs wouldn't be putting placeholder text in as real text, because they'd know that the 10 is representing the monster's HP and is a variable number.

The problem, of course, isn't with the client. Well, a lot of it is, but our people are not training them to work with us. The project manager isn't teaching them how to design and how to work to the sprint schedule. The engineering manager is adamant that the devs should only see the trees and ignore the rest of the forest.

The worst part is that at my previous job, we worked with an actual Agile process - not textbook Agile, but, as is expected, adapted to our team dynamics and pretty damn close - and it was beautiful. The designer came to each sprint start meeting with complete specs that the devs could refine and estimate, and each sprint, we produced exactly what was asked, both in terms of functionality and in terms of the deadline, with no late nights and weekend work (which is becoming all too common now). And when we tell the engineering manager about this, he tells us that no, that can't possibly work, that the only way to work is constantly and that we'll always have to work nights and weekends.

The old company keeps in touch with me, saying they want to hire me back when they have headcount and I am available. If they ever ask, I'm jumping.