So here’s a doozey and not really related to TechArt per se. Having said that, here at Volition, we have recently started to use Scrum/Agile on one of our teams and so far, the experience has been a positive one. We’ve only gone through a couple of sprints and are in the middle of one now. For me, my biggest takeaway so far has been that it’s much easier to see how the project and teams are trending. Getting daily perspective into what others are doing from the daily standups on my team has also been rewarding.
I’m curious if any of you out there have or are using Scrum/Agile in a production environment? If so, what have been the pros/cons of using it? How did you as a Technical Artist fit in?
Yep, we have adopted the same method for our new project.
One of the main pros that I enjoy is that every day, the teams find out exactly what each other is up to, and whether they’re going to be creating issues for other team members or other teams depending on the work they’re doing. Good for ironing out potential workflow issues before they happen.
I guess you guys use something like Hansoft for backlog and sprint management? Nice having a central access to all project tasks and being able to estimate durations of tasks etc.
Regarding technical artists fitting into this, I haven’t done much out of the ordinary yet, but it’s fast to hear if there are any technical impediments to a team’s progress, and I’m usually the first to look into solving them so everything goes smoothly.
Yea, we are using Hansoft. We were also using a whiteboard as another version of the backlog this past sprint, but at least for the team I’m on, we decided to just use Hansoft. I think the most valuable thing for me I’ve gotten out of Hansoft is the burn down chart.
How long have you been using Scrum? Is there anything about it that hasn’t worked out so far?
We’ve been using it since near the start of the year. We have whiteboards too, per-team, for burndown and impediment lists, updated daily during the scrum.
Off-hand, I can’t really think of anything bad about it so far. One of the best things is being able to flag user stories in Hansoft as various priorities, and mark huge ones as “epic” which either get rejected back to design/production to be revised or broken down into more manageable tasks.
Being able to reject user stories based on them being poorly designed or insufficient detail to be broken into useful tasks is very handy. In the past, people might have just taken it on board and just tried their best to make it work (usually with less than desirable results).
Now I think the teams feel more empowered to say “no” to a ridiculous request, or be able to state accurately how long a really big task will take, rather than starting with no idea how it will end up, or what it’s really for.
While we’re a company with 2 smaller teams with a total of around 24 employees, we’ve used agile development since the company started at 6. I’m pretty sure we’ve adopted our methods from some of the ones the CEO used to use at Radical, though I’m not sure how much differently it’s executed with larger companies. I’ll just start firing away some rants.
Pros:
It gets your mind focused on exactly what you should try to accomplish in that day.
It’s a great way of getting people comfortable with one another on each team. It’s impossible for us to all get together at 9 in the morning and not bring up some form of nonsense chatter.
Our sprints have been greatly successful for iterative design. We know exactly what needs to be done and treat each sprint like a project in itself. This really helps to prevent those purgatory states in development when you’re rather lost on what it is exactly you should be accomplishing (though hopefully your leads and directors are on you with that one:wink:).
Granted it’s slightly personality based (as many can be more reserved on expressing thoughts to groups), we try to encourage everyone to step outside their shell during scrums and sprint meetings and try to bring up concerns relative to the sprint and milestones.
To sum the above, you generally just feel more organized every day.
Most of the above things, while positive, almost always have equally negative side effects. So here’s going to be my evil side’s response to each of these seemingly positive things:
Cons:
Scrums start right at the beginning of the day for us (around 9:10 - 9:20), leaving us little time a lot of the times to prepare what things to properly say that are actually valid. A lot of the time individuals will throw one word summaries like ‘AI’, ‘HUD stuff’, or ‘making some level shit,’ making the scrum rather useless for anyone who is depending on the others’ tasks.
Nonsense chatter… should be enough said but let’s go on, shall we? We’ve had wayyy too many scrums where jokes or remarks are thrown around and the scrum ends up taking an extra 10 mins after the initial gather to even get going. If I was in early and started to work on something and then get pulled away for 30 mins it’s hard to jump right back into focus and not just go out for a cigarette instead - pulling my AM focus away even more. Of course that’s very individual based and I certainly am one to sometimes go off on tangents (right now?), but it does happen in some form or another.
Sometimes the improvements in iterative design and expressed concerns has left us with the plague that is ‘too many cooks in the kitchen.’ The ideas will sometimes be instantly reacted upon, causing the actual goals of the sprints to be clustered with additional tasks and more hours. I know some might think that is the definition of Agile development, but it needs to be on a per-sprint basis (ideas integrated into the next sprint and all following sprints adjusted to accommodate changes thereafter).
I gotta say even though the cons might seem-a-plenty, the goods, while shorter worded, carry way more influence on my opinion of Agile development. It rocks. There’s obviously still plenty our studio needs to improve on with our process but I still think following the rubrics of what scrum/agile really is a hard thing to do on a per company basis. We have our own little twists on it (to summarize, more laid back), but the practice has still helped us a ton.
Edit: Oh, and as far as backlogging goes, we actually have an office assistant that takes the notes for us while we’re scrumming, and then sends out a nicely formatted email everyday of what each person is working on, as well as our previous day’s accomplishments from closed JIRA bugs (our bug tracking client). This definitely helps a ton to pop up from time to time during the day to refresh what you and others were working on.
We have production coordinators for each team who take notes during the scrums, keep track of Hansoft stuff, and generally help each team make sure they’re working as effectively as possible…
Actually, Kovac brought up a couple of good points - it’s true that having a scrum too early or too late can be bad (too early means that people might not be fully prepared, too late ruins the work “flow” and is too much of an unnatural break in the day). We tend to have ours around a 10am to 10:30am window.
It’s also the case that the “chatter” can sometimes make a scrum meeting run on a bit long, but ours are never more than about 5-10 minutes for an 8-person sprint team. Our scrum masters (production coordinators) usually make sure everyone stays on track. We have 3 key questions - what have you completed since last meeting, what are you working on today, and are there any impediments to your progress. That way people get through their list of things pretty fast and everyone knows where the team stands.
With regards to Kovac’s last “con” of adding stuff to a sprint that may be already full, we have been dealing with it pretty well, usually any additional stuff goes into the backlog for a later sprint unless the team agrees that they have time to accomplish it without impacting anything else.
We’ve been using scrum for about a year here at VV.
Initially tech art broke the process immediately because we didn’t plan for
the unknowns, like things breaking. I found a lot of my time could be sucked
into tasks that fell under the “support” umbrella. We adopted a 1/2 time rule for
tech art, where we are only ever booked for half the sprint, the other half is
reserved for fixing things, tool maintenance, firefighting and general trouble
shooting.
Once we got past that initial hickup, things have been pretty good.
Yep TechChimp, that’s one that nearly caught us out, but we noticed early on that support could eat up loads of time without warning, for stuff that needed doing immediately (not scheduled), so we usually have generic buffer time allotted to people who are in the sort of role where (like me) they’ll be providing support and bugfixing/troubleshooting for other team members.
I came from a software developer that was all about Agile, they were trainers, their whole development has revolved around it since 2000 or 2001, so they were an early adopter and still a heavy pusher of it. We were their first game project, and scrum failed, badly. The problem came down to incompetent management on the art side, and a complete lack of understanding on the client’s side which messed up programming.
On the art side, our spineless art director never fixed the planning/estimation for tasks- we had 2 days scheduled for an entire suit of armor, head to toe. So when a sprint had all armors, our artists were extremely overworked or extremely behind. For the past 2 months of my time, all I had were ‘skinning’ tasks scheduled for half a day each, I’d complete them in an hour and script the rest of the time. The scheduling was atrocious, and it showed.
On the programming side, our client (Wizards of the Coast) never understood the concept of ‘bugfixing’ or ‘polish,’ so we’d have userstories scheduled and then those features would slowly fall apart. They also never had a cohesive design and felt they could change important design features sprint to sprint, since this was ‘agile’ development (it turned out the GM’s had actually sold them the contract (which they vastly overpaid for) based on that idea). It turned out to be a wreck that was just saved by the hard work of a couple brilliant programmers.
Sorry to go all negative, but I wanted to give one of the negative Agile stories, from a studio that specializes in Agile development. I am a big Agile fan still, and I like how we do it at BioWare (much as described already), but a large part of project management comes down to the project managers- Agile helps lots because everyone is a contributor to project management and responsible for themselves to some degree. But put incompetent managers anywhere (our producer was great but was hamstrung at every turn), and all the Agile goodness in the world won’t save a project.
I’ve actually never heard of the concept, and we implement a much simpler strategy at work. I don’t think it really is worth the effort in smaller teams.
I do heavily agree with Rob though - If your project manager isn’t doing the job, it’s usually the main cause of a vast amount of problems within the project. You can have the simplest project out there ruined by shoddy management.
[QUOTE=Erilaz;476]I’ve actually never heard of the concept, and we implement a much simpler strategy at work. I don’t think it really is worth the effort in smaller teams.[/QUOTE]
Erilaz, care to elaborate? What’s the general structure of your company’s method, and what’s the employee base currently at?
I’m always all about presenting new development strategies to make our lives easier and would love to hear your process.
[QUOTE=Kovac;480]Erilaz, care to elaborate? What’s the general structure of your company’s method, and what’s the employee base currently at?
I’m always all about presenting new development strategies to make our lives easier and would love to hear your process.[/QUOTE]
Ours is actually an interesting situation. We are a team of around 10 people broken into smaller groups (give or take the business/managerial side of things), but we work as part of a larger company of around 1000 (ish… i’m making a broad guess).
Initial development is handled at the whiteboard.
Weekly development is fairly straightforward. A freemind log of everyone’s tasks is updated by the team leader and emailed out, and a weekly update of task status is emailed around by everyone else.
For the most part the graphics work is individually handled with daily updates, while the code work churns on in the background, with occasional bouts of extreme programming methodology (which I love). The smaller graphics team is only 4 people, so development is usually quite an intimate process with lots of internal feedback. We pretty much know what everyone is doing all of the time, so review and discussion of issues is quickly resolved.
Any dealings with project managers and the business are handled as required or when milestones are reached.
As I said: Very simple. Documented communication (ie. logs and emails) and constant talk is what keeps the team on track.
Agile development is something we talk about in theory, but I have yet to really to see it in implementation. I am going to be involved in an associate producer sort of way at our new studio, so I am looking at pushing to actually utilize some of the techniques.
Right now we have a daily meeting at 10:30 (which gives everyone a little bit of time to get settled in and ready for the meeting). This involves the producer, myself, the lead programmers for each platform (the game I’m working on wrapping up is a double SKU), and the lead artists for each platform. Occasionally our QA Manager shows up. We quickly address what we got done, what we’re working on, and what everyone needs to get what they’re working on done. This all works out fairly nicely.
The problem lies in how we deal with the publisher. Instead of the communication with the publisher being consistently directed through the producer, we instead have the publisher constantly directly e-mailing (and talking with during visits) the various leads, without CC’ing everyone else on the team. This has caused a horrendous amount of headache and it is something we are trying to handle a bit differently with the next project some of us are leading into.
We use Hansoft to help keeps things organized, including all of our internal bug tracking and milestone definitions. We switched to using Hansoft back in Feb, and although it caused a bit of a headache getting used to, has definitely helped to get everyone on the same page.
Thanks for the description Erilaz, that seems like it fits nicely for you guys.
I didn’t know Hansoft was (seemingly) so popular. We’re using JIRA right now and I have to admit… I absolutely hate it. When we were smaller we used Bugzilla and ms project for most all of our bug tracking/milestone management needs. Obviously that’s easier but less resourceful for recording data but JIRA feels like it could work for everything but games.
I don’t know if we just got that part right, or it was amended based on
experiences like yours, Rob. At the sprint launch we look at what we are slated to do and can reject tasks that don’t fit, or send them back for revision.
Ultimately, the person doing any given task can adjust the time required. It does
take some practice, and it’s hard to convince a junior artist not to bite off too
much (they are always eager to overwork themselves :D)
We have also had a couple of re-launches, where the direction of the sprint
changed so much that we rebooted the whole thing.
It’s been interesting for me, since I’m usually a cranky SOB, I find it hard to
bitch about things I agreed to and had a hand in working out.
I also had a bad experience with scrum. We (artists) decided to drop it after a few months because our managers made the mistake of starting the project with SCRUM directly without any pre-production. The result is that you have to make the concepts at the SAME time as the assets. So you’re still searching during the whole process. It’s cool for “ping-pong” creation technics between the production artist and the concept artist but I found it was more time consuming that a simple waterfall production. They tried to have a little delay between concept creation and asset production but we had only one or 2 concept designers and too many production guys so we ended up with “Ok, let’s take a coffee and wait for the concept”. I’m sure there are many ways of managing scrum and I think we didn’t take the good one
I’d reiterate some of what TechChimp and Rob said earlier. Scrum worked for a lot of departments and they loved it. For the tech-team (the engine & technology guys + me the TA), it seemed to become less effective as the project wore on into the cycle. Every TA knows that at some point in the project the majority of your time swings from planning and implementing to fire-fighting and bug-fixes that are impossible to identify in advance, let alone schedule for. That’s about the time that our group sort of gave up on scrums and such.
Further echoing sl4ppy’s comment, TA’s role in scrum towards the end of our project has changed to intelligence-gathering, bug-fixing, and general maintenance tasks. So we’re not really on the board, as much as listening to the goings-on and working as support where possible. (i.e. no tasks assigned to us, but we attend every meeting)
One thing to note is that we switched to scrum in the middle of our project’s lifecycle, and we had some growing pains to deal with. For one, we had to learn to discard elements of scrum (or any methodology) that didn’t work, instead of blindly following the rules.
For example, morning meetings are here to stay. They enhance communication, and for such a large team, that is imperative.
On the other hand, we ditched the “point poker” planning session almost immediately. While we still use points to measure work (which irritates me, but I’ll live with it), we don’t have the bidding session. We just trust the person doing the work to estimate, and the manager will sanity-check the estimate. The bidding didn’t add benefit, and typically just slowed the planning session. (although, in retrospect, it may have been good to at least try it first, to get everyone aligned on reasonable point values).
We used it at Faramix. With all of us being from all over the country, it was a big help. We used assembla.com, it’s pretty much everything you need to get started. Worked great for a game like CellZenith, will we use it for our UE3 project? No, but it works great for casual games (I’m sure I’m probably the only one here who makes them though ).
).