Re: Using Agile Scrum in vfx production

[Matt Lind]

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 b

Re: Using Agile Scrum in vfx production

[Alok Gandhi]

>
> 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.
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: Setting two weightmaps with Set Weightmap by Volume?

[Morten Bartholdy]

Thanks a lot Rob - that works as advertised and does the trick.

So I am guessing the trick is to write to two separate data sets and write that 
to the respective weightmaps. After tinkering more with the Set Weights by 
Volume compound I can see it writes some custom data, and if that is the same 
for each compound ICE probably chooses which one to write but can't do both. I 
am not entirely sure though :)

Cheers
Morten





> Den 4. januar 2017 klokken 12:47 skrev Rob Chapman :
> 
> 
> private eh? well there is always more than one way to skin the proverbial
> cat.  here is previously made similar compound + 2015 scene setup that does
> pretty much what you are asking
> 
> 
> On 4 January 2017 at 10:21, Morten Bartholdy  wrote:
> 
> > The compound is private so no poking around :) but the two object method
> > sounds feasible. I wil give that a go - thanks!
> >
> > Morten
> >
> >
> >
> > > Den 4. januar 2017 klokken 10:34 skrev Andi Farhall  > >:
> > >
> > >
> > > although i imagine if you hunt around inside the compound it's probably
> > setting a value on an attribute which both compounds are trying to use.
> > Find what's using the attribute and rename each instance in the second
> > compound
> > >
> > >
> > > 
> > ...
> > > http://www.hackneyeffects.com/
> > > https://vimeo.com/user4174293
> > > http://www.linkedin.com/pub/andi-farhall/b/496/b21
> > >
> > >
> > > http://www.flickr.com/photos/lord_hackney/
> > > http://spylon.tumblr.com/
> > >
> > >
> > > This email and any attachments to it may be confidential and are
> > intended solely for the use of the individual to whom it is addressed. Any
> > views or opinions expressed are solely those of the author and do not
> > necessarily represent those of Hackney Effects Ltd.
> > >
> > > If you are not the intended recipient of this email, you must neither
> > take any action based upon its contents, nor copy or show it to anyone.
> > >
> > > Please contact the sender if you believe you have received this email in
> > error.
> > >
> > > 
> > >
> > >
> > > 
> > > From: softimage-boun...@listproc.autodesk.com <
> > softimage-boun...@listproc.autodesk.com> on behalf of Morten Bartholdy <
> > x...@colorshopvfx.dk>
> > > Sent: 04 January 2017 01:36
> > > To: Userlist, Softimage
> > > Subject: Setting two weightmaps with Set Weightmap by Volume?
> > >
> > > I am trying to create two separate dynamic weightmaps on an object using
> > Giulio Tonini's excellent Set Weightmap by Volume compound. They work fine
> > separately, but I need to combine both in the Rendertree and no matter what
> > I try, it only creates one of the maps when both compounds are plugged in
> > at the same time. I have tried doing each in a separate ICE Tree, read, log
> > and write the values, but still no cigar. It seems creating one weightmap
> > prevents te other from being created.
> > >
> > > https://vimeo.com/88671801
> > >
> > > http://giuliotonini.blogspot.dk/search/label/Compound
> > >
> > > Any ideas on how to do this, or if it is at all possible?
> > >
> > > Thanks.
> > >
> > > Morten
> > > --
> > > Softimage Mailing List.
> > > To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> > with "unsubscribe" in the subject, and reply to confirm.
> > > --
> > > Softimage Mailing List.
> > > To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> > with "unsubscribe" in the subject, and reply to confirm.
> > --
> > Softimage Mailing List.
> > To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> > with "unsubscribe" in the subject, and reply to confirm.
> >
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
> "unsubscribe" in the subject, and reply to confirm.
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

RE: Using Agile Scrum in vfx production

[Maurice Patel]

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

Maurice Patel
Tél:  514 954-7134
Cell: 514 242-6549

-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of javier gonzalez
Sent: Thursday, January 05, 2017 12:43 PM
To: Official Softimage Users Mailing List. 
https://groups.google.com/forum/#!forum/xsi_list 

Subject: Re: Using Agile Scrum in vfx production

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.

2017-01-05 11:42 GMT-05:00, Maurice Patel :
> 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 t

Re: Using Agile Scrum in vfx production

[javier gonzalez]

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.

2017-01-05 11:42 GMT-05:00, Maurice Patel :
> 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: softimage-boun...@listproc.autodesk.com
> [mailto:softimage-boun...@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
> 
> 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 mailto:alok.gandhi2...@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
> softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>
>
>

--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

RE: Using Agile Scrum in vfx production

[Maurice Patel]

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: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@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 

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 mailto:alok.gandhi2...@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 
softimage-requ...@listproc.autodesk.com
 with "unsubscribe" in the subject, and reply to confirm.


<>--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: Using Agile Scrum in vfx production

[Thomas Volkmann]

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  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 softimage-requ...@listproc.autodesk.com with
> "unsubscribe" in the subject, and reply to confirm.
> 

 --
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.