Twitter  Facebook  YouTube  E-Mail  RSS
The One Man MMO Project
The story of a lone developer's quest to build an online world :: MMO programming, design, and industry commentary
Let's Talk about Hansoft
By Robert Basler on 2013-09-23 13:16:54
Homepage: email:one at onemanmmo dot com

I read this post on AltDevBlogADay which made me decide to finally post this:

I was approached by a fresh-faced rep from Hansoft at Game Developers Conference a couple years ago. She asked me if I used project management tools, and after replying that I used their software, she was really excited and asked me what I thought of it. I told her I had never seen a product so thoroughly designed to make people feel bad about their work. She stared at me blank faced, then handed over one of every tchotchke they had in their booth.

The toys didn't make me feel any better about Hansoft. Do you have a happy team? Hansoft may well drive it into the ground.

From a manager's perspective Hansoft is great. Everyone can see how the team is progressing. Developers know their assignments. It comes with charts. It has regular meetings to facilitate communication. It makes developers analyze their tasks, makes them more "predictable." Concrete, measurable performance results are available at the touch of a button. All good things, yet as a developer, Hansoft makes me feel so bad, I know there has to be a better way.

The Burn-Down chart. They should have called it the burn-out chart. Ideally it should look like a triangle with the pointy corner on the bottom right. That ideal is made VERY clear when it is introduced. In practice it never looks like that. For anybody. It is however, a daily little graphic reminder that you're not doing as well as you "should" be. Better work faster!

Developers can count. We know how much work is left and how many days there are. We don't need an infographic for a one or two week period. Project managers should make themselves useful and make one for the whole project. Early. It would be much more helpful to know sooner if the project scope needs to be adjusted to hit our goals. We don't need to focus so much on finding blame on a day to day basis.

If you don't complete your sprint tasks, you're a failure. If you finish early, your reward is additional tasks from the backlog! Hoorah. Don't finish those extra tasks? That win you had? Yeah, that's over.

A better reward for finishing early would be to be able to help someone else on your team finish their tasks. You work together, build the team, they get to finish their list, you finish yours, when theirs is done you both help someone else tackle theirs. Build up the team, don't tear down the individual.

Tasks for each sprint are taken from the Backlog. Ahh the backlog. A never-ending list of things we should have had finished already. Dreams of what to do are easy. Implementing them is hard. Choices have to be made. There's nothing that destroys team morale like a gigantic, ever growing list that anyone in the studio can look at when they need ammunition against your team. Call it a wish-list, or the idea-bin, or trim it down to a manageable To-Do list, or only put in current project tasks, but control who can see it. Developers might then be able to feel a little more positive about what they're working on, rather than negative about what they aren't.

Oh, and project managers - please don't force Agile on anyone who can't control the scope of their tasks. If one of your sprint tasks is "support", or "customer service", trying to apply agile is going to do nothing except mess up your schedule and make that poor developer feel like they're failing all the time. They spend a day helping a customer, which is of course why they are there, and all of a sudden, the rest of their week is catch-up.

Lastly, meetings should be included as sprint tasks, not grouped under "overhead" and excluded from planning. If I have to sit through a bad meeting, I should get credit for that.

By Adam Clifton on 2013-09-26 04:07:29
Homepage: email:adam at hulkamaniac dot com
I remember when we actually used a form of Agile at our studio before Hansoft. Agile became glorified task tracking in Hansoft, with all the incomplete tasks moved into the next sprint so you can never tell historically how many of the planned tasks were getting done!

Also, in the magical unicorn world of real Agile you are supposed to come to an agreement at the sprint planning meeting on what you can reasonably complete during the sprint. So you shouldn't get more work pushed on you. But that never happens in reality, in fact I don't think I've ever been to a sprint planning meeting.

New Comment

Cookie Warning

We were unable to retrieve our cookie from your web browser. If pressing F5 once to reload this page does not get rid of this message, please read this to learn more.

You will not be able to post until you resolve this problem.

Comment (You can use HTML, but please double-check web link URLs and HTML tags!)
Your Name
Homepage (optional, don't include http://)
Email (optional, but automatically spam protected so please do)
What color is a lime? (What's this?)

  Admin Log In

[The Imperial Realm :: Miranda] [Blog] [Gallery] [About]
Terms Of Use & Privacy Policy