›

Viscera Crunchies, probably not ideal for consumption

DarkCarnivourDarkCarnivour
edited in General
I put up a quick blog post touching on some of the issues with how we made Rooks Keep and Viscera Cleanup Detail and working towards sorting them out.

http://www.runestorm.com/blog/2013/12/15/crunching-the-crunches-rooks-keep-viscera-cleanup-detail-and-the-time-demons/

Comments

  • mattbenicmattbenic
    However, time management has been steadily improving – we somehow got 5 significant releases out on schedule in the last 6 months – but it’s not nearly good enough.
    That is an epic achievement, really. I know you're trying to improve your process, but I'd love to know what your current process is. Even if you're not quite happy with it, it's obviously A LOT better than what some others are doing.

    You're so right about needing the flexibility to innovate, and find those great things that end up making your game what it is. I believe the only way to do this without killing yourself on crunches is to pad the hell out of your schedule in anticipation of it. As it is, I think we're all prone to over-estimating what we can get done in a set amount of time-not because we overestimate our abilities, but because there are always unexpected hiccups like that stupid little bug that takes a week (and eventually one line of code) to figure out and fix. @Fengol would probably have some valuable input here.

    At one point we tried using scrum at Luma, and I'm still convinced that with some tweaks it (or something similar) could work really well. It would need a couple of things I think we failed to include when we tried it though:
    -Serious management transparency and buy-in and ability to prioritize showy stuff. It doesn't help if your scrum board is pulling in one direction and your management in another because while the scrum is focused on features management has to worry about pitches and shows. This includes marketing assets that we always ended up scrambling together 2-3 days before a show, blowing what otherwise would have been a great sprint.
    -Better/padded task estimates AND a given percentage of padding for unknown features. Agile should by definition work well with unknown stuff but that can only work if time is allowed for it in the overall schedule.
    -A less admin-intensive implementation and longer sprints (we used JIRA and our sprints were only two weeks, and found we spent more time on meetings and admin than was ideal)
Sign In or Register to comment.