As mentioned in earlier posts, you need to experiment for a while before you find the right mix.
While at Carbine developing Wildstar, towards the latter part of my tenure the studio switched to agile/scrum methods to hold people more accountable as there was a communications problem studio wide. The left hand didn't know what the right hand was doing, and vice versa. Every department had 15-minute daily standups (which, in actuality, were 30-45 minutes), and we had a lot of departments. Probably too many. In the middle of the mornings I would be in the standup with technical artists, and in the middle of the afternoons in another standup with programmers. On select days I'd also participate in scrums with managers for pertinent topics. I never had a dedicated block of time to actually do my work which required lots of deep thinking and quiet time. As a result I always looked like I was underperforming when reality was I was burdened with preparing for standups all day to present points of discussion, or counter-arguments/answers to questions raised in previous discussions. If you didn't look good in the standup, you looked bad to management. The standups favored people who had simple or repetitive tasks, and worked against people who had more complicated schedules/tasks. I would suggest scheduling meetings only when there is something relevant to share. If you meet too often, you waste people's time because they have to clear a part of their schedule just to attend. If the standup is void of tangible discussion, that's time that could've been spent doing actual work. In my case, that also meant cutting short time helping others just so I could run across the building for the standup. When I'd return, that person would be in their own standup. Later when that person was finally done with a standup, it was lunch time, or time for another meeting. Enough crossed schedules like that and you create more problems than you solve, including adding stress unnecessarily to people who already have stressful jobs. Personally, I did not like the agile/scrum methodology employed at Carbine. It made my day more difficult and less productive. This brings up point #2 - you need to evaluate what the actual need is for employing agile/scrum methodology. If you have long timelines and tasks that require lots of dedicated uninterrupted time to complete, then slicing that into frequent scrums is probably a bad idea. Set meeting frequency to fit the pace of the project's divisible time/task units. If an average task takes a week, having a daily standup is probably overkill. Conversely, if the average task takes a day or less and is not critical to the bigger deadline...do you really need agile methods to be employed? Agile is best for situations where there is a lot of interdependency between tasks being performed. If your tasks are independent of each other, then you may not need agile workflow. Point #3, is only invite people to standups who are needed for the discussion. This may mean the attendee list rotates frequently, but not everybody needs to hear the details every standup. A given department may be comprised of a mixture of people working on short term simple tasks and those with longer term more difficult tasks. The simple task people would need more frequent standups and the longer cycled people can be allowed to skip a few meetings as their schedule will not impact or be impacted much in either direction. The point is to group people according to how they function and impact the schedule, not strictly by their job title or what office/cubicle their desk is located. For concrete example, I was a technical artist but wrote code all day, no rigging. The other 6 technical artists only did character rigging, no coding. It wasn't of much value for me to be at every standup listening to what characters they rigged since the previous standup, nor was it productive for the other technical artists hear me talk about coding issues on my tasks as they often had no clue what I was talking about. Their work did not impact my schedule, and most of the time my work didn't impact theirs either because I'd be writing tools for other departments. Similarly, the afternoon standup with the programmers was a mismatch as I was working on artist tools while they worked on systems tools, but there was little to no overlap in our respective work. The meeting was mostly a way to get a feel of what life was like in other departments as opposed to being relevant to the functioning of the project. The last point I would try to emphasize is to make sure the person managing the standups and schedule is someone who has first hand experience with the tasks being managed. That is, if managing a technical art group, then make sure that person has technical art experience, or experience closely related to it. If that person is strictly a manager out of business school or similar, you run risk of having meetings which only serve to fill in blanks on a piece of paper and never used for anything meaningful because the manager has no way of connecting the dots to keep things on track. In other words, they don't serve any purpose and only waste people's time. In short, not all projects will benefit from agile methods. Evaluate your needs and act accordingly. Matt Date: Thu, 5 Jan 2017 12:42:43 -0500 From: javier gonzalez <javi09warr...@gmail.com> Subject: Re: Using Agile Scrum in vfx production To: "Official Softimage Users Mailing List. https://groups.google.com/forum/#!forum/xsi_list"; <softimage@listproc.autodesk.com> About the implementation, its better a simple white board for the kanban board or use some agile tools for this and to calculate a burndown chart etc? Thank for the link maurice, i think i will ask to some software development friends. ------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
