Alright, so thanks for the intro.

My name is Mia Brook.

As you kind of said alright.

And I'm here today to talk to you about collaborative work flows.

So, I work at a company called Pixo.

I am the creative director.

Which apparently now after this UX session here, probably be called the strategist

and the product owner and the UX designer and all that stuff, too.

So, I play quite a broad role at the company.

And we are, at Pixo, a fairly small company, there

are twenty nine of us and we do digital consulting, so.

Websites and web systems at a fairly large scale.

So as I mentioned, collaborative workflows.

A topic that I'm very, very passionate about.

And I'm gonna tell you a short story in a bit

as to why this topic is so near and dear to me.

And then we're gonna go into some concrete tools and techniques

that you can take back with you and implement in your teams.

So, we're gonna start with Annie.

This is my girl Annie.

In 1901, Annie Edson Taylor became the first woman, a

person to ever go over the Niagara Falls in a barrel.

This is a true story.

At the age of 63.

She went over all the falls and amazingly she survived and

you can see the look on that guy, that guy's face.

He is just like, what the heck was

this woman doing, but thank goodness, she's okay.

She survived with just a few bruises, a couple

cuts to her head but otherwise she was fine.

And I am sharing this story with you today because.

About two years ago, my team at Pixo, with me included, went over

the Niagara falls of web projects in a proverbial barrel.

So, this project was for an

overhaul complete redesign of the University website.

And that means there colleges, there departments, there centers, the works.

And to give you a sense of scale, this old site had about 3000 pages,

about 95 percent of the content needed to be completely checked or rewritten.

There was a legacy CMS that was no longer supported.

And we had a team of 12.

Very opinionated stakeholders.

So, we started the project using the water fall method that we'd always used

and we started with research.We went and

interviews their students, their faculty, their administration.

We really got in there.

We wrote this huge research brief.

And then based on that brief, the UX people created personas

and based on those personas, they build these beautiful interactive wire frames.

once those were done, that got handed over to

the design team which I was in at the time.

We, this was like right at the beginning of when we started doing responsive stuff.

So this was all Photoshop mock-ups of tons and

tons of different pages all at three different sizes.

I see nods.

You're like, those dark old ages.

When we were done, we handed that over to the development team.

And then we say goodbye.

It's like design and UX left, the developers were going to do their thing.

Once the developers were done, quality assurance came in and, and that was that.

We have done fairly large projects in the past,

but now responsive design really took us over the edge.

And.

Small waterfalls those can work just fine.

Medium size waterfalls can be okay.

Especially if you're wearing a helmet.

If you're into that kind of that thing.

But the larger the waterfall gets the more dangerous it becomes.

And the look of horror.

[LAUGH].

>> [LAUGH] On this guy's face, is pretty much how I felt, the moment

that I realized that our team was going over the Niagara Falls of web projects.

My friends in a barrel.

So I'm assuming most of you, or maybe even

everyone here today, has experienced the challenges that come with.

The waterfall methodology.

So I won't go into the gory details

of how painful this project actually ended up being.

But I'll tell you this.

Because of multiple delays, both on the client's part and

our part, say it took two very long years to complete.

And like Annie, we survived.

We came out the other end.

We were kind of bruised, kind of shaken.

But we, we made it out okay.

And the site turned out beautifully.

And we were fine.

But, I actually fully share Annie's sentiments.

And she said, if it was with my dying breath.

I would caution anyone against attempting the feat.

I would sooner walk up to the mouth of a cannon, knowing it

was going to blow me to pieces than make another trip over the Fall.

Never again am I going over that.

So, since our epic waterfall adventure.

We've put a lot of effort into rethinking

our process at Pixo, and we're totally not alone.

Every consulting firm that I've talked to recently, a

lot of people here that I've just been talking with.

Everybody seems to be moving from a more rigid silent

approach to one that's a lot more collaborative and iterative.

And at Pixo, we're really in the thick of making that transition.

We've definitely not got it solved, but we're doing a lot of experimentation and

a lot of tweaks and we've learned a ton in the past two years.

And the really key thing we've learned is that we

need to adapt our methodology to the needs of every project.

We found that different techniques worked better for different kinds of clients.

So, we found that using a different approach for, say, a large web system

is needed as opposed to, say, a sexy brochure marketing site for a start up.

And, that's why what I'm presenting today isn't a methodology in and of itself.

It doesn't represent our, you know, quote, unquote process.

It's a collection of tools and techniques that you can use all at, you can start

implementing all at once, but I actually recommend

implementing them and trying them out one by one.

There's a great quote from an article in a list apart that showed up a

couple of weeks ago by Mike Libreria that really gets to the heart of this.

He said, a mentor of mine once told me that programming boils down

to reducing the number of unknowns on a project to a manageable number.

One is fine, two is a stretch, three is asking for trouble.

So, change takes time.

And.

Now I'm gonna talk to you a little about

those techniques that we can then jump into and

you can take and you can implement with your

own teams and your own peoples and your own project.

So, Sketch Studios, this is my favorite technique to

get the entire team invested and, on a project.

So Sketch Studios are a collaborative exercise.

Where the project team designs and iterates

a interface together in a structured format.

And this technique helps build the shared understanding of

the points of view and expectations on a project.

And it really speeds up the process of getting to the final design.

So I'm gonna show you a story of a recent one we did.

And a step-by-step breakdown of how to do a successful sketch studio.

So recently we redesigned the intranet

for the Champaign-Urbana Mass Transit District.

And this is the organization behind

Champaign-Urbana's really, really wonderful transit system.

So MTD's intranet is their core internal communication hub.

It's really, really important to the day to day runnings of the organization.

It's where bus operators message each other.

It's where payroll requests are made.

It's where people submit forms and, and request.

Things like clothing allowances.

Doing a sketch studio was one of the keys to this project's success.

So a good sketch studio needs clear

objectives, and research helps establish those objectives.

For MTV we began the process by interviewing MTV employees about how

they used the Internet, and we made sure to include MTV's project

liaisons in those interviews, so that they could hear first-hand, what the

paint points were and what the issues were that employees were talking about.

So using the results of these interviews and looking at

analytics and then doing our own assessment of the site.

We came up with a feature report that captured

those pain points and our recommended solutions for them.

It also assigned priorities for each of those recommendations.

And here's an example of the feature report that we did for MTV.

So the first column identifies Pixo's recommendations based on the pinpoints.

And the second column is an explanation of those recommendations.

So, for example, exposed key info in the dashboard.

Currently takes a lot of drilling in to find out what's new and fresh.

Let's make sure that is, we show that on the dashboard in the new system.

We then have columns for value and effort

and element nature for low, medium and high.

So with the case of NTD, they had an in-house developer that was exceptionally

talented and wonderful, and they were gonna

have him build the intranet that we designed.

So we then handed this feature port to him and had him

add some of his own notes and had him actually go through.

And add what he thought the was value and effort for each of these features.

And so that really helped determine our priorities

and make sure that when we went into

the sketch studios we had a clear set of tasks that we wanted to work on.

So a good sketch session needs clear objections.

And the feature report helps define the problems that you're trying to solve.

And your feature report may look completely different.

I mean, we did ours in Excel but, probably we'd use Google Sheets now.

You can even have it as a list.

But the most important thing is to identify

what you want and need to work on, what

value those features bring to the project, and what

the level of effort is to implement those features.

[BLANK_AUDIO]

One sec.

Water.

All right, the next thing is to include the

full team and typically in our industry, sketch studios, these

kind of things, are done by UX, or the

teams that are known as UX, sometimes designers get involved.

But I wanna emphasize that the most succesful, of the design studi, of

the sketch studios that I've done, have

involved a much broader, much broader team.

So invite your clients, invite project managers, invite developers,

maybe even the quality assurance people, so that they can

really see, what you're, what you're gonna be building,

and get a real sense of ownership into the project.

And by having the full team you get

perspectives that you might not have gotten otherwise.

So in the case of NTD there were three of us.

There was a UX designer, a graphic designer,

in this case me, and NTD's in-house developer.

And some of the best decisions we made came from MTD's developer.

As somebody who worked there, he had a

really strong understanding of the organization and its users.

And he's also going to be building the thing.

So he had a real investment and, and incentive to make sure

that every single aspect of the design made perfect sense for implementation.

He was gonna be building the thing.

So in our feature report, we broke the internet

into ten distinct features and we did one sketch

session per feature for a total of a ten

sketch set studios over the course of a few weeks.

In order to lower the stakes of the

initial sketch studio and to get everybody feeling comfortable.

We actually started with the lowest priority feature.

And in MTV's case, this was the classified section.

So we had a classified section, it was

kind of crappy on their current internet, it was

something that would bring value to the employees, but

it wasn't crucial to the day to day operation.

So that's what we started on first.

So if you're going to be doing multiple sketch studios because you have several

features you want to work on, I

definitely recommend starting with the lowest priority first,

because then you can work out the kinks in your process, and for us, by

the time we got to the really important features, we were really on our game.

We knew how to do things.

We knew how it worked, and we had established that basic communication.

So at the beginning of each of these sketch studios, we reviewed

a very informal feature brief that was compiled by our UX designer.

And in this document, again super simple Google Doc, she identified the page

types that we would need to be working on during that sketch studio.

So for classifieds.

things like a list page an item page post an item page she also did a comparison

of popular classified listings and how they approach key features that we need in

the classifieds so for example how long should

a listing stay up should we let people

do thirty days sixty days or what kind

of categories should we break the classifieds into.

She also included screen shots of each classified listing.

And Kijiji happens to be horribly ugly.

But it had some key features that would allow us to really

have a good discussion of what they're including, versus what we need.

And those Canadians in the house might recognize Kijiji.

So a feature brief should establish the sketch studio's

priorities, and coming with a concrete task list helps

give structure to the session and a comparison analysis

really gives you a great jumping off point for discussions.

So is this, this is really where the fun starts, so the image I'm gonna show here.

Is we did this for our dashboard and

the dashboard was one of the most important features.

I think we did this one third and we

wrote out on the whiteboard the most important elements, all

the elements that need, that needed to be on the

page and then we had our developer go ahead and.

Rank them in order of importance and you can see over

here that he actually marked the bulletins as the number one

thing in importance and I'm there on the left starting to

draw out these little grids for where the bulletins would go.

So the great thing about this process is that,

especially working with a white board, you can erase.

Photograph, discuss, sketch, erase some more, and

it's a very, very quick iteration between ideas,

and for us, it was also an opportunity to sort of get the ugly out.

Get those ideas that are kind of stale, and kind

of lame, but they're the first ones that come to mind.

So, for here it was like all right let's do this traditional

card gridded approach for each particular, piece of content that we needed.

But what we found was as we kept sketching and iterating on this,

with that stream made a lot more sense, that had all the different

elements in the order that they came in, and that was something that

was more digest, that we hypothesized at the time was more easily digestible.

And it's something that we've done user testing

on since and it's been a really good approach.

So it was really amazing to have the developer's last

client on hand cuz he was immediately able to video things

that just wouldn't work and fill in any knowledge gaps

that arose and we also held these sessions at MTV's office.

And what that did was it really allowed us to, anytime,

we had a question about something that our developer couldn't answer.

He was able to run from the next room.

Grab the person who was in that area and have them come in.

Look at our whiteboard and give us feedback.

Or just make a quick phone call.

Somebody would come down.

If you have the opportunity to do this onsite with your client,

it's really really great to be able to bring those people in.

Because of all the prep we've also done.

We were able to very quickly iron out all the

snacks, and fill in detail, and move towards the prohesive design.

So, after you're sketch studio, we went back to Pixo

with photos of our drawings in hand, and a UX designer.

When ahead and put those in an interactive prototype that was filled

with annotation based on the things that we had discussed during the session.

And this serves, this served as the main records for our designed decisions.

So in total we held about ten sketch sessions

about two hours each, very dependent on the features.

Some features were very quick.

Took us about a half an hour.

Other features that were more complicated took us up to two hours.

But in an average of 20 hours, we were able to get more

progress and more consensus that we historically

have gotten in about twice that time.

And one of the wonderfullest things that came out of this was that we

actually came in 40 hours under budget for this particular phase of the project.

So I've just shown you one variation, but I definitely encourage you to take the

concept of Sketch Studio and adapt it to you and your teams and your projects.

And here are a couple variations based on scenarios that you might find yourself in.

So large groups.

What I just showed you works great for two to four people.

Very informal, in front of a white board, with absolutely no structure tying to it.

If you're going to do sketch studios with larger groups, I encourage you

to break up into smaller teams, and then have people sketch on paper.

also really helpful to actually give time structure, in these cases.

So, to have these smaller groups do ten

minutes of brain storming and sketching, come back

together as a group, ten minutes of review

and discussion, then go back and iterate on that.

So having a structure for larger groups really helps keep things moving.

And keep people on task.

You might also find yourself being part of remote teams or having remote clients.

And one of the absolutely most wonderful

tools for this is an IPEVO document camera.

It's really helpful to be able to sketch

and see each other's sketches in real time.

And this camera is particularly great because if you put your hand.

It's the camera goes on to the paper, but if you put your hand in,

it doesn't refocus on your end, it will keep a fixed focus on the paper.

This is a particularly good tool for working remotely.

And, I just read a blog post a while back about a company that actually sends

clients these cameras in the mail when they

wanna do this collaborate sketch studios with them.

Cuz, it's such a valuable part of their experience.

So, Sketch Studios are a lot of fun.

And by getting a team, the team in the room and sketching together, you can

iterate ideas, superfast in real time, and give

everyone a sense of ownership of the project.

[BLANK_AUDIO]

So the next technique, if you've gone

to design school, you'll be intimately familiar with.

Group critiques are absolutely crucial to good innovative design.

But, in my experience, they're also something

that's really easy to forget to do.

Or to push aside in the face of deadlines or people being spread too thin.

And regular code reviews fall into a pretty similar bucket.

And also getting critiqued can be scary.

And you're standing and presenting in front of

a room of people who are smarter than you,

and pointing out things that you potentially have

missed, or things that you could have done better.

And

that's something that can be pretty humbling for a lot of people.

But in order to be successful, be on the waterfall.

We have to get comfortable exposing our unfinished work to the rest of the team.

And by the rest of the team, I

mean everyone who's gonna be working on the project.

Make sure to show it to your developers, to your project managers.

Really, the more people that you can, to get that feedback.

So, when discussing the success of Pixar's films, and that is Pixar, not Pixo.

We get that mixed up a lot.

The President of Walt Disney animation studios Ed Catmull, said that one of

their, the keys to their success, was reviewing the material every single day.

This was a process of review that came from employees that had worked at

Disney, that had worked at Lucas films,

and he stressed the importance of constant review.

As creative people, we wanna show things when they're done.

That's kind of our natural inclination.

But, he said, when you get over the embarrassment, you get more creative.

It's not obvious to people, but starting down that path, helped everything we did.

So at Pixar we don't have daily formal design critiques,

but we have a lot of, frequent informal reviews, and every

Wednesday, we get the entire design UX in front of the

development team, for an hour of what we call design digs.

So we use that hour to discuss web trends.

If somebody's seen a speaker and there's a video,

we will watch that video or watch a webinar.

And it's an opportunity for us to share our work for the team.

With 29 people at Pixar, we don't often

get to see what everybody else is working on.

And this gives us an opportunity to, not only share what

we're learning, but, give each other feedback, and much much needed feedback.

So the first time we did a critique at Design Digs, the project manager for

that particular project walked away saying, I

never wanna do a project without this again.

And ever since then we've made it a point,

to bring every project that we can for group critiques.

When running a critique, it's really important to ask the right questions,

and this is something that I've heard in, talk after talk today.

What do you think?

That question will only get you so far.

And, may not address the full underlying issues that you're trying to solve.

So Jason [UNKNOWN], the CEO of base camp, recently published a blog

post, with about 50 questions that he finds himself asking at design reviews.

It's a really wonderful reference that I highly recommend, you guys look up.

And for today, I've pulled out some of my favorites.

What's the takeaway after eight seconds?

Why is that worth a click?

What's the simpler version of this?

Why that order?

Would it matter if someone missed that?

Is this better as a sentence or a picture?

What problem is that solving?

So proactively asking for feedback, not a super natural inclination for most people.

But for me collaborating with others, is one

of the absolute best parts of being a designer.

And by making the critiques a priority in asking those hard questions, we

can push ourselves to innovate beyond the web trends that we're seeing everywhere.

So next you're doing a group critique, grab somebody

who you might not traditionally involve in a crit.

Make design a shared effort, and let your

team help push the boundaries of what you're creating.

So I'm gonna with you a story, about a

site we just built for a startup in Silicon Valley,

whose name I can't actually share with you cuz they're

in stealth mode until they launch their site next week.

So the client came to us, requesting a marketing site that

will show off a super-cool biotech product that they're working on.

But the thing was, they like, you know we have this

PR deadline coming up and we need the site in seven weeks.

They also had three very key goals.

The first being, they needed to get sign ups for their beta.

[SOUND] The second is to show investors and

potential investors that their product is actually for real.

And the third, is to blow any competitors that are

in the market, at the moment, completely out of the water.

So, typically at Pixar, we take anywhere from

four months to a year to build the site.

We work on large scale web systems.

We do a lot of requirements gathering.

And as you've heard from my previous story about the epic waterfall adventure.

In some cases it can actually take up to two years.

How that, knock on wood, never again.

We've never done such a large scale, such a, full blown,

cutting edge marketing site in such a short period of time.

But this project, ended up being the combination of two

year's worth of experimentation, with new techniques and new processes.

And has been by far the most successful and

profitable and fun project that I've worked on to date.

So leveraging techniques, that we tested out to this point,

we came out with a plan particularly for this project.

And here are the lessons that we put

into practice, that made it such a successful project.

So identify your team, your full team,

right at the very beginning of the project.

And make sure that team stays on, from the beginning right till the very end.

Cohesive teams, that stay together throughout the length

of the process, are a lot more efficient.

They have a greater ownership of the product that they're working on.

I mean nobody likes to come in, in the middle of a

project, look at somebody else's code,

because somebody else's code is always bad.

And then have to, re-architect or re-learn how they did it.

By having cohesive teams throughout the life

cycle of the project, you also capitalize on

that sense of, comradery and trust that

comes with people working together throughout the project.

At Pixar, we have definitely been guilty of hot potatoing projects.

And we have found that [SOUND].

Aside from exploding the project's timeline, it also

significantly reduces the profit, profitability of a project.

There is massive knowledge loss, when you pull somebody off a

project, and then there's the spin-up cost, when you put somebody

new on, and it takes a lot of time for them

to get up to speed, and in our business, time is money.

So, if you're in a startup, or a

product focus company, keeping your team cohesive may not

be as big of an issue, but in a consulting company, this is like, super super hard.

And we don't have a magic bullet yet for making

this work perfectly, but seeing how important this is for,

our own team morale and the bottom line, we've updated

our sales and traffic management processes to prioritize cohesive teams.

When difficult decisions need to be made, the

priority now is to always keep our teams together.

That meant that for the starter project, we actually had to hire

two contractors to make sure that the project got done on time.

And while our own team members were super bummed about it,

cuz it was a really, really cool project, it made sure that

we were able to get the project done on time, and it

wasn't impacting any of our other work that we had going on.

So keeping your team cohesive is way more efficient.

It brings a greater sence of ownership to the team,

and it's really, really important, for building comradery and trust.

So the traditional waterfall model, kind of like a relay

race, maybe a very antiquated relay race at this point.

Each team does its work, passes the baton in the form of knowledge

and de, and deliverables off to the next team, and as so it goes.

So you've got, in silos each team does it's

thing, gets things done, hands things over to the next.

For the startup project, because we are on such

a tight timeline, we decided to work in parallel.

So we started to get familiar with the client, get to know

what their priorities were, get to know the product a little bit more.

And then we did an internal sketch studio, with the entire team

based on our, and based on those sketches we built an interactive prototype.

So when the basic architecture of the

site was down, we jumped straight into implementation.

The wire frame, this prototype, far from being finished.

It really just had the basics in it.

Have a navigation, has a footer, has some homepage elements, had

some pieces from more informational pages, but it was enough there that

the development team could, build out basic features, build out all the

infrastructure that they needed and really get started, and then in parallel,

we also started the design process.

So, getting the visual style of the site down,

making sure we had the bits and pieces that we

could then hand over to the development team and

really make sure, that the initial site design was established.

Very shortly after design and development began, we pulled our QA person in.

Because, then she was able to test things in real time as a feature went

up on our DEV site, she went through, made sure it worked and that really helped.

You dont get to the end of the project, you've got like, a few weeks

left, and then it's like boom, here are all your problems that QA comes up with.

So having them do that, as we were building, made a huge difference.

So working in parallel allowed us to it,

allowed us to iterate on the site incredibly quickly.

About two weeks into the project, it became very clear

that a particular section of the site where we were

talking about the client's web interface, it really needed some

sort of video or animation to communicate, effectively how it worked.

And so, in our initial prototype ,we had static

images and text that were describing this web interface.

And after doing some user testing, showing this

around, people were like gosh we really, really want

an animation, somehow get us in there so we can, we can see how the thing works.

We have initially intended to do our animation in phase two,

just because they really wasn't very much time on this project.

We also included in our contract, that we wouldn't

do any animation in phase one because of the timeline.

That could be felt so strongly about, wanting to set the

expectations and not get into something that might have been very troublesome.

But, you know, this approach we knew just weren't, wasnt gonna cut it.

We didn't wanna move forward with it.

So what we did is we had our developer, since we

were making such good progress at this point, go into a prototype.

He went, spent a day, spent a little bit of time working on a particular piece

of the animation, to see if we actually could do this in a short amount of time.

He came back, and he's like.

That was so much easier than I expected.

I have no issues and no concerns that we

can do to the full animation within the timeline.

So we prove to ourselves that we can do it.

I need to show you a little snippet.

How it turned out.

And that being a much more immersive experience.

And when we show this in our user testing, people are like oh my

gosh, okay, we get this, we understand so much more of how this works.

And this was really only possible, because development

started well before, either design or UX were complete.

And it gave us that buffer time that we needed, to

add something that actually became the client's favorite feature on the site.

And it made us look great, cuz we give this bonus

feature that went above and beyond the expectations that we have set.

So having UX design, development QA working in

parallel, not only saved us a ton of time.

But it gave us room to really respond to the needs of the project as they arose.

And, made for a really cool feature, and very very happy clients.

So I can't stress enough how important regular,

consistent communication is, both for the client and internally.

And because this starter project was done on such a tight

timeline, we had our client commit to a one hour meeting.

Every single day.

And that might sound excessive, but it was actually

one of the reasons that our project was so successful.

Because any time we had a question and any time that we had

something we wanted to showed them, we knew that we had a meeting

at the end of the day, that we can then show it to

them and get their immediate feedback, and

it allowed us to iterate incredibly quickly.

When you're working on a tight timeline, the most important thing is to keep

things moving and the thing that really

holds up progress the most is unanswered questions.

Internally, we also held three weekly team meetings

that were about ten to 30 minutes each,

and the key questions at these meetings, is

do you have what you need to keep working?

So these meetings could sometimes be super short when everybody went

around and was like, yep, yep, yep, got what we need.

Sometimes they were a little bit longer when somebody said, you know, I

have a bit of a blocker here, and we needed to talk that through.

But the goal of these meetings was really to keep it

short and make, make sure that people could keep on moving.

On top of that we also held one, one to

one and a half hour tech meeting, where this was

the opportunity for our team to really problem solve bigger

tech issues like, what framework, if any are we gonna use?

How are we gonna handle version control?

What's the go live process gonna look like?

So, one of the hardest things for us to stomach at

the beginning of this transition to more collaborative and iterative work flows,

was the uptake in the number of meetings that we ended up

having, and there is no question, meetings take a ton of time.

But we also notice this, the projects that we had more task

based team meetings where people were actually sitting in them and not just

schmoozing and talking but really addressing

key issues, were the ones that tended

to not go over budget, and we've seen a really consistent trend here.

[SOUND] And while it's a pretty large and potentially scary committment to

make, that's a lot of time, especially in a consulting environment, it's really

paid off for us, in the long run and I would say at

this point, we budget about 25% of our project's budget for team meetings.

So task-based meetings, super, super important, to keep the project's momentum.

They also really help the team gell and they create this,

greater sense of accountability and excitements,

in the team about the project.

All right, Agile, the big hot topic in our industry at the moment.

This has, Agile Development has actually given us some of

the most transformative and powerful techniques that we've used Pixar.

And most of the established Agile techniques, they're very structured.

You know, very particular rules, very particular things

you need to follow to do them right.

But, at Pixar we've been easing our way

in and really cherry picking, the pieces and the

bits of the Agile process that really worked

for us in the particular projects we're working on.

And task boards, are one of those bits.

So, task boards are a project management tool, that allows the team to

see at a glance the status of any given task on a project.

And these boards are amazing.

There was this like, audible side relief at Pixar, when we started

using it through the company about a year and a half ago.

So we internally use a project management tool called JIRA for our task boards.

But you can use all sorts of other tools.

There are plenty online.

Last night at the reception I was talking to somebody

who uses Trello, and is super in love with Trello.

His team absolutely adores it.

and, you know you could also use post it notes on a wall or a white board.

The, the key thing here is that, you keep each

person's task outline in a very, very easy to internalize format.

So here's the Agile board we used, for the start up project.

And I'm gonna go through it just to give you a sense of how these things work.

So the first column has, the tasks that need to be worked on.

So the title is of this one, to do.

The second shows the tasks that are in progress, and the third

is for tasks that are blocked or on hold for some reason.

So for example, a task might depend on a response from a client.

We've asked the question we're now waiting for that answer.

Or if I'm waiting for somebody to finish up their piece before I can work on mine.

The most important thing, is that everyone can see, at any

given time, that, that parti, that particular task is in limbo.

And then, really have conversations to address how to get that out of limbo.

Next you see a design review column.

And this indicates to whoever is testing or

reviewing, that this task is ready for review.

Then that person can go in, test that feature,

and then slide it over to the done column.

There's, lots of different ways that you can arrange these

boards, and we've experimented with

different approaches from project to project.

And you can see in this board from another

project, that there are six columns instead of five.

You can see the titles of the columns are slightly different.

It's very much depending on the projects needs.

I could seriously give an entire talk about

task boards, nuances of how to use them, but

I am just gonna show the, very very

basic workflow that we used on the startup project.

Okay, so the beginning of the project, the project manager creates a list

of tasks, for every known task that they need to do on the project.

All of those tasks then go into a backlog.

It's a list of all of them as a catalog

at any given moment of the task that we know about.

[SOUND] At the beginning of the week, the private manager selects a set of tasks

based on the priorities that have been

established and moves them into the task board.

And then as people work on their tasks, they can drag and drop the

tasks from column to column to reflect in real time the status of the task.

And at the end of the week the board is

refreshed, the done tasks are removed, and the cycle begins again.

And like I said this varies so much from project

to project, we might have, that review process go for two

weeks, it could be shorter, it could be longer, it's

very, very much depending on how things go with your project.

But, what I love about task boards and this view is the

transparency, you know where your team is at, at any given time.

You know what the bottlenecks are, and

you can go ahead and address those immediately.

It's also a really wonderful way to capture and organize your team's issues.

Prioritize them, take action on what's important.

So of all the tools and techniques in this talk, if you're not using

task boards at the moment, that's the first thing that I would try out.

As the complexity of our project grows, the amount

of stuff we need to keep track of increases.

Task boards have been an absolute life saver for us.

And I'm absolutely never doing a project again,

without having a view like this to work with.

[BLANK_AUDIO]

So, we've still got a ton to learn at Pixar.

Like I said, we're very much in the thick of it.

Everyone I've talked to in the industry is very much in the thick of it.

But, we're moving forward, we're trying out these new techniques.

We're trying out ways to be more collaborative and efficient in

our process and we're, we're definitely moving in the right direction.

My girl Annie would be proud.

Every project we do goes a little big smoother, a little bit faster.

I can see real change happening, and you know, change is hard.

We get used to working in particular ways.

We get habits.

We get into our comfort zones.

It's kind of, challenging sometimes to get ourselves

out of it, but it's so very worth it.

And this is a really cool time in our industry because

like I said no one really has this fully figured out.

So as you guys try the techniques, learn better ways to do things.

Definitely keep sharing them with us.

You know, let's create a better way to work together.

So my parting words of advice to you are these, don't go chasing waterfalls.

[LAUGH] Whatever tool or method you use, let it be one

that empowers your team and allows them to be true partners.

So, I can't wait to see what you

guys do, how you're adventures beyond the waterfalls go.

And I'll see you on the other side.

Thank you.

[SOUND]