Using Agile Scrum in vfx production
480 views
Skip to first unread message
javier gonzalez
Jan 4, 2017, 12:08:42 AM1/4/17
to soft...@listproc.autodesk.com
Hi guys, i just read in fxguide "scrum in vfx" article, and now am
exploring this metodology, can anyone point me out some maybe online
software, readings, videos focusing in scrum in the vfx, there is lots
fo reading for software development by the way.
shotgun or ftrack use this metodology or its something that the
shotgun user can implement?
------
Softimage Mailing List.
To unsubscribe, send a mail to softimag...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
exploring this metodology, can anyone point me out some maybe online
software, readings, videos focusing in scrum in the vfx, there is lots
fo reading for software development by the way.
shotgun or ftrack use this metodology or its something that the
shotgun user can implement?
------
Softimage Mailing List.
To unsubscribe, send a mail to softimag...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
Pierre Schiller
Jan 4, 2017, 7:21:53 PM1/4/17
to Official Softimage Users Mailing List. https://groups.google.com/forum/#!forum/xsi_list
If you could please share the URL, let´s get all our minds into it :D
On Wed, Jan 4, 2017 at 12:00 AM, javier gonzalez <javi09...@gmail.com> wrote:
Hi guys, i just read in fxguide "scrum in vfx" article, and now am
exploring this metodology, can anyone point me out some maybe online
software, readings, videos focusing in scrum in the vfx, there is lots
fo reading for software development by the way.
shotgun or ftrack use this metodology or its something that the
shotgun user can implement?
------
Softimage Mailing List.
To unsubscribe, send a mail to softimage-request@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
--
javier gonzalez
Jan 4, 2017, 11:30:44 PM1/4/17
to Official Softimage Users Mailing List. https://groups.google.com/forum/#!forum/xsi_list
Here you are:
https://www.fxguide.com/featured/scrum-in-vfx/
I research a little more, it seems a very good methodology, used in
the software development with a very good result. I found this to:
freescrumtraining.org/training/?gclid=COHig-Dcp9ECFYFDhgodP-UE0w
but they say needed some experience in software development, which i dont have.
2017-01-04 19:21 GMT-05:00, Pierre Schiller <activemoti...@gmail.com>:
> If you could please share the URL, let´s get all our minds into it :D
>
> On Wed, Jan 4, 2017 at 12:00 AM, javier gonzalez <javi09...@gmail.com>
> wrote:
>
>> Hi guys, i just read in fxguide "scrum in vfx" article, and now am
>> exploring this metodology, can anyone point me out some maybe online
>> software, readings, videos focusing in scrum in the vfx, there is lots
>> fo reading for software development by the way.
>> shotgun or ftrack use this metodology or its something that the
>> shotgun user can implement?
>> ------
>> Softimage Mailing List.
>> To unsubscribe, send a mail to softimag...@listproc.autodesk.com
>> with "unsubscribe" in the subject, and reply to confirm.
>>
>
>
>
> --
> Portfolio 2013 <http://be.net/3dcinetv>
> Cinema & TV production
> Video Reel <https://vimeo.com/3dcinetv/reel2012>
>
------
Softimage Mailing List.
To unsubscribe, send a mail to softimag...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
Alok Gandhi
Jan 5, 2017, 1:43:23 AM1/5/17
to Official Softimage Users Mailing List. https://groups.google.com/forum/#!forum/xsi_list
The article explains it all! Extremely well-written. Having been a member of the agile team, I can say that this is sounds very interesting for VFX Project Management. We use agile (though for software development for animation), our typical sprints are 7 days or 14 days. Scrums are every day.
Thomas Volkmann
Jan 5, 2017, 9:29:54 AM1/5/17
to Official Softimage Users Mailing List. https://groups.google.com/forum/#!forum/xsi_list
Very interesting read!
Being new to that topic, Alok could you share some insight what a typical scrum looks like (how long does it take, is it at the start or the end of the day, etc).
/Thomas
Alok Gandhi <alok.ga...@gmail.com> hat am 5. Januar 2017 um 07:43 geschrieben:
The article explains it all! Extremely well-written. Having been a member of the agile team, I can say that this is sounds very interesting for VFX Project Management. We use agile (though for software development for animation), our typical sprints are 7 days or 14 days. Scrums are every day.
Maurice Patel
Jan 5, 2017, 11:45:30 AM1/5/17
to Thomas Volkmann, Official Softimage Users Mailing List. https://groups.google.com/forum/#!forum/xsi_list
It is an interesting article and as pointed out VFX shares a lot of commonality with the problems faced in software development where iterations, ‘feature creep,’ the subjective nature of product quality and disparate stakeholders create complexity and a high potential for budget and scheduling overruns.
If you are interested in Agile methods such as Scrum and Sprints you can also find out more on websites like this one: https://www.versionone.com/agile-101/agile-methodologies/
This is just one of many companies that provides services in implementing Agile methods but they provide some background material into Agile methods on their website. Googling a bit will unearth more.
The principles of Agile are reasonably simple – the trick is getting them to work for you. Ideally the system you develop will be adapted to your needs and it is not really a standard formula that can be applied generically. The usual advice is pick one or two projects and try to implement agile methods on them first – projects with low risk and a high chance of success. Learning from that process should then enable you to deploy more broadly.
Finding the right tools that work the best in your company is a discovery process. You can teach yourself (takes longer and has the potential for a lot of hiccups but definitely doable) or find someone with some experience in implementing agile methods and a good knowledge of how you work to help.
A scrum meeting is typically held daily, often at the start of the day, with all key stakeholders and its main goal is prioritize and align on the backlog (generic term for what needs to get done). However for the meeting to work the tools used to document and measure the state of the backlog need to be accurate and appropriate – and that is the real challenge of the implementation – which is why the FXGuide article focuses quite heavily on that aspect
Maurice Patel
Tél: 514 954-7134
Cell: 514 242-6549
From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Thomas Volkmann
Sent: Thursday, January 05, 2017 9:30 AM
To: Official Softimage Users Mailing List. https://groups.google.com/forum/#!forum/xsi_list <soft...@listproc.autodesk.com>
Subject: Re: Using Agile Scrum in vfx production
Very interesting read!
Being new to that topic, Alok could you share some insight what a typical scrum looks like (how long does it take, is it at the start or the end of the day, etc).
/Thomas
Alok Gandhi <alok.ga...@gmail.com<mailto:alok.ga...@gmail.com>> hat am 5. Januar 2017 um 07:43 geschrieben:
If you are interested in Agile methods such as Scrum and Sprints you can also find out more on websites like this one: https://www.versionone.com/agile-101/agile-methodologies/
This is just one of many companies that provides services in implementing Agile methods but they provide some background material into Agile methods on their website. Googling a bit will unearth more.
The principles of Agile are reasonably simple – the trick is getting them to work for you. Ideally the system you develop will be adapted to your needs and it is not really a standard formula that can be applied generically. The usual advice is pick one or two projects and try to implement agile methods on them first – projects with low risk and a high chance of success. Learning from that process should then enable you to deploy more broadly.
Finding the right tools that work the best in your company is a discovery process. You can teach yourself (takes longer and has the potential for a lot of hiccups but definitely doable) or find someone with some experience in implementing agile methods and a good knowledge of how you work to help.
A scrum meeting is typically held daily, often at the start of the day, with all key stakeholders and its main goal is prioritize and align on the backlog (generic term for what needs to get done). However for the meeting to work the tools used to document and measure the state of the backlog need to be accurate and appropriate – and that is the real challenge of the implementation – which is why the FXGuide article focuses quite heavily on that aspect
Maurice Patel
Tél: 514 954-7134
Cell: 514 242-6549
From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Thomas Volkmann
Sent: Thursday, January 05, 2017 9:30 AM
To: Official Softimage Users Mailing List. https://groups.google.com/forum/#!forum/xsi_list <soft...@listproc.autodesk.com>
Subject: Re: Using Agile Scrum in vfx production
Very interesting read!
Being new to that topic, Alok could you share some insight what a typical scrum looks like (how long does it take, is it at the start or the end of the day, etc).
/Thomas
The article explains it all! Extremely well-written. Having been a member of the agile team, I can say that this is sounds very interesting for VFX Project Management. We use agile (though for software development for animation), our typical sprints are 7 days or 14 days. Scrums are every day.
------
Softimage Mailing List.
To unsubscribe, send a mail to softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com> with "unsubscribe" in the subject, and reply to confirm.
------
Softimage Mailing List.
javier gonzalez
Jan 5, 2017, 12:43:00 PM1/5/17
to Official Softimage Users Mailing List. https://groups.google.com/forum/#!forum/xsi_list
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.
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 softimag...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
Maurice Patel
Jan 5, 2017, 1:39:58 PM1/5/17
to Official Softimage Users Mailing List. https://groups.google.com/forum/#!forum/xsi_list
It is hard to say - it is whatever tools work best for you and your team to understand the scope of the backlog. It could well be a whiteboard that you update every meeting to start. I'd at least start there for a few tests. Once you get an understanding for it and feel it works you can formalize it with some digital tools. This is actually not really the hard part of agile.
There are a few other things to take into consideration when implementing agile:
- How ready is the team to change the way they work? If the team is hierarchical or you have team leaders who very much want to be in control (micromanage) it is going to take a cultural shift in the team before agile can be successful
- How good is the team at scoping work? The better you are at that the easier it is to migrate to agile methods
Scrum works well when everyone is aligned as to what needs to get done its priority and its effort. The meeting than can focus on impediments and resolving them. This is the real value of agile the continual course correction that can happen on a daily basis. But its only effective if everyone has a voice and everyone has a common if understanding on terms and scope. Agile works badly if you spend the entire meeting discussing how long it takes to do each task.
You also need a strong scrum master to keep meetings on track (they are facilitators not managers but they need to be empowered) and the product owner (vfx sup) needs to understand their role is not to micromanage or even to direct the scrum but to provide guidance on what needs to be done. So team dynamics are pretty critical here. The product owner defines what needs to be done - the scrum team figures out how much it can do and how it needs to be done.
You will have to go through several sprints before you can figure out exactly how much can be done realistically and whether you are scoping correctly.
The challenge is that agile is a means of fast iteration and collaboration - but to work you actually need to establish some things well in advance - such as methods of scoping and prioritizing work. Agile methods can provide tools for that too - such as epics and stories that are used to define the importance of a feature set - but you can use your own. An important thing to consider is ROI of work. Although it is impossible to actually quantify you typically need some way of establishing the value of different types of work. Having a good knowledge of the priority, effort and ROI of every item in the backlog leads for much easier discussions
> softimag...@listproc.autodesk.com<mailto:softimage-request@listp
There are a few other things to take into consideration when implementing agile:
- How ready is the team to change the way they work? If the team is hierarchical or you have team leaders who very much want to be in control (micromanage) it is going to take a cultural shift in the team before agile can be successful
- How good is the team at scoping work? The better you are at that the easier it is to migrate to agile methods
Scrum works well when everyone is aligned as to what needs to get done its priority and its effort. The meeting than can focus on impediments and resolving them. This is the real value of agile the continual course correction that can happen on a daily basis. But its only effective if everyone has a voice and everyone has a common if understanding on terms and scope. Agile works badly if you spend the entire meeting discussing how long it takes to do each task.
You also need a strong scrum master to keep meetings on track (they are facilitators not managers but they need to be empowered) and the product owner (vfx sup) needs to understand their role is not to micromanage or even to direct the scrum but to provide guidance on what needs to be done. So team dynamics are pretty critical here. The product owner defines what needs to be done - the scrum team figures out how much it can do and how it needs to be done.
You will have to go through several sprints before you can figure out exactly how much can be done realistically and whether you are scoping correctly.
The challenge is that agile is a means of fast iteration and collaboration - but to work you actually need to establish some things well in advance - such as methods of scoping and prioritizing work. Agile methods can provide tools for that too - such as epics and stories that are used to define the importance of a feature set - but you can use your own. An important thing to consider is ROI of work. Although it is impossible to actually quantify you typically need some way of establishing the value of different types of work. Having a good knowledge of the priority, effort and ROI of every item in the backlog leads for much easier discussions
Alok Gandhi
Jan 5, 2017, 8:29:45 PM1/5/17
to Official Softimage Users Mailing List. https://groups.google.com/forum/#!forum/xsi_list
Alok could you share some insight what a typical scrum looks like (how long does it take, is it at the start or the end of the day, etc).
Our scrums were through emails rather than in person meeting, although this offered the same functionality. At the end of each day, each team member had to communicate to our technical coordinator (through email or chat) what he /she did during the day, what he/she will be doing the next day and if there are any blockers in moving forward. The coordinator then compiled all individual information received from the team into a single email and send this email to all team members. When we started the next day, we all know what each person is working on today and if there is anything blocking them that we can help with.
Matt Lind
Jan 6, 2017, 1:45:07 AM1/6/17
to soft...@listproc.autodesk.com
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 <javi09...@gmail.com>
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 <javi09...@gmail.com>
Subject: Re: Using Agile Scrum in vfx production
To: "Official Softimage Users Mailing List.
https://groups.google.com/forum/#!forum/xsi_list"
<soft...@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.
To: "Official Softimage Users Mailing List.
https://groups.google.com/forum/#!forum/xsi_list"
<soft...@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.
Marc-Andre Carbonneau
Jan 6, 2017, 11:45:10 AM1/6/17
to Official Softimage Users Mailing List. https://groups.google.com/forum/#!forum/xsi_list
I don't believe this was mentionned yet but Jira from Atlassian is a very good task tracking tool and has all the Agile methodology implemented (Kabaan waterfalls, Agile etc...) and about 3 years ago, Shotgun implemented a way to talk to Jira. Might be worth checking it out. Haven't tested myself yet and now I can't find it on Shotgun's website... :S
MAC
Marc-Andre Carbonneau
Jan 6, 2017, 12:07:13 PM1/6/17
to Official Softimage Users Mailing List. https://groups.google.com/forum/#!forum/xsi_list
Oh and I know Jira looks very ugly to artists but you can customize it to make it work and "look" the way you want.
;)
;)
Ben Beckett
Jan 11, 2017, 9:51:21 AM1/11/17
to Official Softimage Users Mailing List. https://groups.google.com/forum/#!forum/xsi_list
Its defiantly assumes we don't mind working weekends!
> From: softimage-bounces@listproc.autodesk.com
> [mailto:softimage-bounces@listproc.autodesk.com] On Behalf Of Thomas
> Volkmann
> Sent: Thursday, January 05, 2017 9:30 AM
> To: Official Softimage Users Mailing List.
> https://groups.google.com/forum/#!forum/xsi_list
> <soft...@listproc.autodesk.com>
> Subject: Re: Using Agile Scrum in vfx production
>
> Very interesting read!
> Being new to that topic, Alok could you share some insight what a
> typical scrum looks like (how long does it take, is it at the start or
> the end of the day, etc).
>
> /Thomas
>
> Alok Gandhi
> <alok.ga...@gmail.com<mailto:alok.gandhi2002@gmail.com>>
> hat am 5. Januar 2017 um 07:43 geschrieben:
> The article explains it all! Extremely well-written. Having been a
> member of the agile team, I can say that this is sounds very
> interesting for VFX Project Management. We use agile (though for
> software development for animation), our typical sprints are 7 days or
> 14 days. Scrums are every day.
> ------
> Softimage Mailing List.
> To unsubscribe, send a mail to
> roc.autodesk.com> with "unsubscribe" in the subject, and reply to
> confirm.
>
>
>
------
Softimage Mailing List.
To unsubscribe, send a mail to softimage-request@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
------
Softimage Mailing List.
To unsubscribe, send a mail to softimage-request@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
------
Softimage Mailing List.
To unsubscribe, send a mail to softimage-request@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
Reply all
Reply to author
Forward
0 new messages