The following content is provided under a Creative
Commons license.
Your support will help MIT OpenCourseWare
continue to offer high quality educational resources for free.
To make a donation or view additional materials
from hundreds of MIT courses, visit MIT OpenCourseWare
at ocw.mit.edu.
PROFESSOR: OK, most everyone's here.
We're still going to take a few minutes to wait
for the last few people show up.
I don't have a ton of announcements,
but if you looked at the syllabus,
you might notice is there are a couple days where we have,
I think we've got TBD as the topic, like to be determined.
What I'd like to do is just take a quick poll from y'all.
Is there anything that you are interested in learning
about in the creation of video games
that you either we haven't talked about in class yet,
maybe we've talked about it but not
fully, you've looked at the syllabus
and it's not there on the syllabus.
Or it's something that you think is
going to be directly useful for the games
and you're working on right now.
So just putting that out there.
If there's any topics you might want to talk about,
learn about, let me know.
Yes?
AUDIENCE: You really, like, in other classes
you didn't say, really, in the last class or the last two
classes, say really, like, what people actually
do in the industry.
PROFESSOR: OK, so yes.
Cool, so what people do in the industry.
Cool.
You are in luck.
On December 1st and 3rd.
On the first, we're having a business in games panel.
So two independent developers in the area
are going to come by and talk about how they started
their companies, what do they do,
what's their daily life, things like that.
And then another one following that
is the community manager for Fire Hose Games, Sean Baptiste,
is going to talk to us about how do they get their games out
in the world, and how they get people to play their games.
And how do they engage their fan base.
And how do they even just create a fanbase in general.
So that's not on the syllabus, But we will be doing that.
Any other topics?
OK.
I'm going to ask this again in a couple weeks in case something
pops up, because you probably haven't
done a lot of technical things with your game engines yet.
So if there's anything gaming specific
that you might want to know about,
either let us know through the through the video game bosses
email address, or let us know in class.
Yeah?
AUDIENCE: Who will be giving these lectures?
Like, is this open to-- can you get--
PROFESSOR: I can get people.
So I can get people who are local,
we've got connections to local industry.
We've got connections to the people
who make the tools, in some cases, depending on the tool.
That's why I'm asking now, because it gives me time
to fill new gaps.
Also, it might be something that we can talk to.
So if there's anything design-related
that you think is useful for your games
that we haven't talked about yet,
and you don't see it on the schedule, let us know.
If there's anything technical related,
Drew can come up and say something.
The other thing we can do is if there's
anything that you want to do, or if you
want to set up office hours in class
to talk about a certain topic for your games,
specifically technical issues, technical questions, that's
what Drew's here for.
To come and talk with your group as a whole, or just
individual members in your group to talk about the issues
that you have.
So we can do that during class, during our schedule, one
and a half to two hour work-in-class periods,
or you can set up work office hours with him.
Just give people couple more minutes.
The attendance sheet is moving around.
So is everybody sitting with their teams right now?
It looks like-- I'm going to go across and just
try to figure out which of these teams are.
So it's the snap team, is everyone here?
Two, OK.
Which team, this is forecast-based futures
over here, right?
How far do you go?
John, are you in this team, or are you in the next team?
Cool.
Next team over, which team are you?
Cholera?
No.
You're in cholera team?
Were you the island group?
Animal Crossing one.
Cool.
And then in the front here we've got heat wave,
and the back it's the other cholera group.
OK.
I did not get a chance to play your game.
But I will eventually.
So there's going to be a little bit of interactivity
in the talk.
I've given this talk before.
I rewrote the lecture, and I haven't given it
since I rewrote lecture, so we'll see how it goes.
They're my backup to let me know if I forgot anything.
There will be some reading on this
I'm going to put into Stellar.
So if you are interested in the topic,
if you have more interest in the topic
and you want to read the reading,
I would highly recommend it, especially
if you think you're going to be in a leadership
position in the future, or any kind of managerial position.
Or you're interested in just psychology,
and how people talk to each other and work together.
So our three main topics, this will actually
be pretty quick on this lecture.
We're going talk about, we're going
to do a really quick review of Agile.
We're going to talk about team dynamics,
and we're going to talk about how do distributed Agile
teams perform?
So what are some of the best practices
they have for performing?
And then you're going to work in class.
You'll have at least two hours to work in class today,
a little more than that.
So agile processes.
If you forget everything in this class,
you got into the real world and somebody asked you,
what is agile?
I hope you remember this part.
Iterative development.
Does anybody consider what they're
doing iterative development on their projects right now?
Are you working in short periods of time?
So you broken up your time in the small sprints.
You can't really read it that well on the slide.
But are you within that short period of time designing
what you're going to work on, planning how it's
going to work, doing it, and then testing it evaluating,
the test and changing it?
Are you doing all that within one week, or two week cycle?
Raise your hands yea-- so yes, raise your hands.
No, raise your hands.
It's OK if you say no.
OK.
If you're doing something that looks like this, then great.
And remember, agile, and in particular, Scrum processes,
they're based on these three pillars
that Sarah talked about when we first brought this up.
So the pillar of transparency.
And what we mean by transparency there,
we really just need a common nomenclature.
To be honest, I don't care what you
call the things that you use as part
of your process in your team.
So long as everyone within the team
knows what it is, so long as whoever you're submitting
those processes to also know who it is.
So we're not acting as your product owners in the class.
But if you had a product owner, they
should also know what you're calling things.
What you're calling your product backlog,
what you're calling a task, how you're estimating
and how you're doing your processes.
So everyone on the team should know it, not just
in a more traditional manner, a project manager knowing
what all the processes are.
There's a number of inspection that's going on.
So through the process, you are taking a look
at all the artifacts that you've created.
So those backlog items, tasks lists,
things like that that you're creating during the process.
You're inspecting it, and in particular, you're
inspecting it during meetings.
So you're taking a look at what you've done in a meeting,
and talking about it.
So you're not just doing a process, you're doing a process
and you're talking about it, and you're actively
thinking about the process.
And then you're adapting.
So based on evidence, based on changes in needs,
you're changing that process.
Again, if you're doing any one of these three things,
you're doing processes well.
You're doing some form of agile-like process.
That's another thing I hope you take from the class.
The agile manifesto.
It is a manifesto, It is an idea.
It is something that has some political weight behind it.
It's saying, this is the way to do things,
this is the right way to do things.
But it's actually more vague than that.
It's really just saying, here are some four key things
that we feel are more important than other four key things.
So the first item is individuals and interactions
over processes and tools.
So we've been talking a lot processes and tools
for the first part of the semester,
now we're going to talk about individuals and interactions
between individuals.
So your team members.
All right.
What's a team?
Anybody give me a working definition
for what you'd call a team.
What'd you say?
AUDIENCE: A bunch of [INAUDIBLE].
PROFESSOR: A bunch of puppies?
Is it a group of people?
Is it just a group of people?
AUDIENCE: A group of people working toward a common goal.
PROFESSOR: Yes.
Anything else?
So it's a collection of individuals,
so it's a group of people.
They're working toward a common purpose.
They have shared responsibility for common outcomes.
If one of those puppies trips, that stick
goes in another puppy's mouth, and it hurts a lot.
So keep that in mind.
Shared responsibility, common purpose, common outcome.
So teams evolve over time.
And the little bit of research I'm
going to talk about actually comes
from studying group behaviors.
And this is all from about 1960s and on up,
and around the 2000s, and I'll post this reading up.
There were some studies showing that this actually
works for teams.
This does work for people who have a common goal.
But as you get a bunch of people together, and get
a small group of people together.
And in our terms, we're calling a small group
of people eight to 10 people.
Maybe a little bit bigger, but about 10 people total.
They're going to evolve based on those interpersonal
relationships.
So how they know each other, what they
talk about, how they talk about.
And their task behaviors.
So we're going to be talking about not the tasks
that you're doing in your teams, but the behavior surrounding
the tasks that you're doing it.
So if you're working on a task, if you are doing some coding,
how are you coding, or who are you coding with?
How are you talking to other people
about what you're coding?
And you can apply to any task that you're
doing in your teams.
There's a lot of different theories.
Actually, Wikipedia is a pretty good nutshell
of what are all the different kinds of theories,
and different kinds of models we can
use to describe how groups talk to each other,
and how groups evolve.
But they all come down to these common things.
There's a period of getting to know each other,
there's a period of experiencing conflict,
and there's both positive and negative conflict when
you're talking with each other.
Your roles shift based on changing knowledge and changing
experience.
And hopefully at some point, there's some kind of consensus,
there's some kind of moving forward.
Decisions happen here.
The point is, though, what kind of decisions get made?
Are they effective decisions, or are they ineffective, unproven,
they get made because you have to make them,
and you have to move on.
And we're hoping that by analyzing how your teams work,
you can then move towards having some effective decision making.
So the model we're going to talk about
is Tuckman's model from '65.
It's got four phases.
Forming, norming, storming, performing.
It's very cutesy.
It gets used in training sessions a lot.
It can just be something that you can just spit out and say,
and someone says, oh, you're smart, you know that model.
But maybe you don't know everything behind it.
I might be more in the you're smart,
but maybe you don't know everything behind it.
I'm still learning about how this works.
But each phase has items you can identify.
More useful for us is this is a model
you can use to figure out where your team is right now.
What phase are you in, so you can then make decisions
about where you need to go, and how you
need to work together better.
So the forming phase of it is when you first
are getting together.
Everyone wants to be friendly, everyone wants to get along
and to be accepted with each other.
There might be some serious problems from the get-go,
but they're usually avoided.
And the team learns about challenges and goals.
But not much gets done.
There's no real task completion going on in this stage.
When you think about your previous teams,
you've been in this stage, right?
When you first got together?
Say project two, project three, I'm
going to ask you some questions about projects two and three
as we go forward.
All right.
That's a happy stage.
Then storming happens.
People are able to express discontent.
There actually might have been discontent in phase one,
but it actually wasn't being expressed in some form.
In phase two, it's being expressed.
But how it's being expressed can be different.
So it could be someone actively saying, no, you're wrong,
that's stupid.
It could be someone not talking.
But they're feeling the same thing,
and they're thinking about the same thing.
It's the same kind of disconnect can happen.
Opinions tend to get challenged.
It can be contentious, it can be unpleasant.
In order to advance past this stage, what your team really
need is tolerance and patience just to get through it.
But even more important, you need
to establish lines of trust and open communication
to get through this stage.
This is what we've been doing for the past first
of the semester, is creating processes.
We've been giving you some tools that you can use,
so then you can then create those processes in your teams.
So just a quick hand raise from teams.
Does anybody think that they're in this stage right now?
Do you think, in your team, you are currently,
you're expressing discontent, you are creating processes,
you don't have processors yet, but you're figuring out
what your process might be?
Maybe?
What do you say?
You're not sure?
AUDIENCE: Yeah.
PROFESSOR: OK.
Next u p, norming.
So this is where you have those processes.
Individuals start giving up their own ideas and goals.
You're actually moving toward a team goal right now,
and people are starting to take responsibility,
and rules are established.
OK.
Comparing storming to norming, raise
your hands if you think your team is in norming right now.
OK, yeah.
Now raise your hands if you think your team is
in storming right now.
OK.
All right, so.
Is anybody performing?
Are you functioning as a unit efficiently?
Are your team members already autonomous?
Is descent expected and addressed right now?
This is where you want to get to.
You probably aren't this far yet.
My bet's you're probably somewhere in the storming area
things, maybe getting close to the norming area things.
Basically, you're still talking to each other, you still trying
to figure out what are the different ways of communicating
with each other.
What are the different processes and rules you might have.
And you might not get this far in class,
by the end of the semester.
You might not be fully efficient by the end of the class,
and that's OK.
But if you are, it's kind of cool.
So the model in practice tends to be nonlinear.
It gets talked about, and it was originally established
as a you go from here, to here, to here, to here.
You go through the phases, at the end of the thing,
you're done.
Your team's awesome, go you.
What we Actually see in process is
that teams tend get in the forming, they go in the circle
where they go from having some issues,
figuring out how to deal with those issues,
establish some rules.
All right, we're going really well again.
New challenge comes up, we're back in the storming.
We've put ourselves in a position where
we don't know how to talk to each other,
or we don't know how to communicate with each other.
So there's some problems with the model.
This is really a descriptive model.
It's a tool for us to use to see how things are going.
It's basically a way to evaluate symptoms.
But there's no triggers in the model.
We don't know when those things happen.
When does your team switch from storming to norming?
So this is what I'd like you to do in your teams,
just take a couple minutes.
Talk about your previous teams you've been on,
talk about the team you're on now.
When do you think your team would move from stage to stage,
and how could a team move intentionally?
And in particular, think about that
storming to norming part of it.
So what is it going to take for your team right now,
or what happened in your team right now to go from,
we are having some difficulty talking with each other,
we have a bunch of opinions, to we're all on the same page.
Take three minutes.
AUDIENCE: Just one thing I want to chime in.
There's a very, very good chance that your team actually
is still in forming stage.
And one of the reasons why very few of you
might have put up your hands that you don't actually
want to express dissent, which is exactly the situation
that you get in the forming stage.
It is uncomfortable, but hopefully you can logically
see the benefits of being in a team where
you can talk about the things that you disagree with, right?
So it's possible that you are still in forming,
and it's good to identify your teams as, OK,
this normal evolution of a team, and that's
where our team is at right now.
So talk about it among your team.
PROFESSOR: So take three minutes,
just talk to your teams.
I'm going to ask you some questions when we're done.
[SIDE CONVERSATIONS]
So each group, give me something you talked about about
what are the triggers, what are the things you
saw as you moved?
Just let me know which phases you're talking about.
So go ahead.
AUDIENCE: So we have the answer to [INAUDIBLE].
We're somewhere between storming and norming.
PROFESSOR: How do you know?
What caused you to get there, you think?
AUDIENCE: We got a lot of the core game squared out.
And that was when we had the most storming.
The reason that I think we're closer to norming now
is because it's like past standard.
Pick them up, [INAUDIBLE] and marking this done.
Which is faster.
On the front end, we're between forming and storming.
Because we're still working on a lot of design decisions.
PROFESSOR: All right, so it's big decisions.
How big are those two teams?
AUDIENCE: Four and four.
PROFESSOR: Four and four?
OK.
So somebody else next.
A trigger that you saw that made you go from one stage
to the other.
AUDIENCE: I think as a team, we're
moved from storming to norming.
And part of that trigger was working
on solidifying our game idea.
Because at this point, while we all
recognize that we're building as a team,
we all have different ideas of what this game should be.
And as we're solidifying the game,
we're also getting ourselves in line
with what we're actually doing, and how we're going to do it.
PROFESSOR: Do you think that the task of solidifying the game
idea is helping you, because there's this big decision
you have to make.
Is that helping you work as a team?
It's not getting in your way?
AUDIENCE: I think it's the fact that as we're doing this,
we've definitely had this conflict in our team,
where people were shouting out different ideas,
and trying to work through it.
And at first, we weren't doing the best job
of getting those ideas and working through them.
But I see that now, we're doing a much better job
of understanding each other, and seeing how it
fits into the bigger picture.
PROFESSOR: OK, cool.
Next team.
A triggering moment that you saw in this team or previous teams.
AUDIENCE: So we had a bigger power team at first,
and I think that having the sides split up
was the way to help us jump from forming to storming.
Because we had to use scripts in order
to get our team to get to ideas.
Also, there were conflicting ideas
in terms of where ideas go in the brainstorming session.
PROFESSOR: So it's basically just reducing the number
of opinions, really, right?
When that is purely through people.
AUDIENCE: So with our game, I think getting us to norming
was really-- you talked about assigning tasks.
But also just the accountability aspect,
because instead of spending time arguing,
we had a designated person, or a couple people
who are capable for different things.
Which allows us to just not argue [INAUDIBLE].
PROFESSOR: So like certain people
have different they own some subtasks,
or their own subroles?
AUDIENCE: Yes.
PROFESSOR: OK.
Cool.
In the back?
What do you think?
AUDIENCE: I guess what got us over to storming
was meeting together as a team to make design decisions, which
was like what has been said there.
And I think that the next step for bringing us over to norming
would be actually getting everyone
to participate in design decisions.
Because people have both not shown up, and not particularly
shown interest in getting things going.
So having everyone on board is [INAUDIBLE].
PROFESSOR: So that's a big one.
That's a huge difficulty, especially
with student projects.
You've got all these other things going on around you.
Do you think you need everyone to contribute to the design,
or do you need everyone to be on board with the design?
AUDIENCE: So I understand some people are just
less interested in having deep discussions about the design
of the game, but getting everyone
to both be aware and willing to participate when they need to.
PROFESSOR: OK.
Because yeah, there's important conversations
being done that, if they're not there when it happens,
they're not going to know where the status of the game is.
AUDIENCE: Yeah.
They just need to be willing to participate.
If they're not there, take the step of, oh,
what'd you guys talk about?
I'm interested in knowing.
PROFESSOR: Thank you for that lead,
because that gets us to our next stage.
So I think we find ourselves talking a lot about the product
that we're making.
It's just easier.
It's that hard thing you can see.
It's being made, it's being done.
We can play it.
It means we're probably doing something right.
But it's still very difficult to talk about the people.
But we saw been talking about the people a little bit
here, especially with accountability in this one.
It was good.
Cool.
So that brings me to the next topic.
Teams are composed of individuals,
and each person on your team is going
to have a lot of different factors affecting
what they do, how they do it, when they do it.
I can't give you the magic formula to get them motivated.
What I can do is show you some of the different ways
that you can try to either understand the people you're
with, understand the people on your team,
or find things to talk to them about.
You might notice a number of these things.
So to get someone who's motivated,
someone who's going to be able to participate,
think about all these things.
Think about personal development.
So you're in a class, you're here
hopefully because you want to learn.
You want to learn a new skill, you want to try a new skill.
Everyone wants to learn a new skill.
There might be a skill that they want to work on on your team,
and I think we've talked about that
in the past when we were talking about the vision statement,
and people putting down why they're involved on the team,
and why they're involved in this project.
So being aware of that, and constantly coming back
to that for each person, especially if you have someone
on your team who is just not participating,
and you need to figure out how to engage them.
Think about the skills that they want
to bring to the table, the skills
they're trying to practice.
When it comes to motivation, it largely
comes down to intrinsic or extrinsic.
The extrinsic might be the grade that they're going to get,
but it's really difficult to really hone in on that,
because the grade's shared between your group.
So that might not be the place to look at.
Try to take a look at the intrinsic things.
If they had enthusiasms about the project at some point,
try to remember what that was.
Ask somebody else on your team what that might have been.
See if you can bring that enthusiasm back
into the project.
Morale or self-worth.
There's been some research that shows
that the reason why people work well on teams, and the reason
why we want to work on teams is because it brings us
self-worth.
And in particular, there's some self awareness
that can happen by being on a team, and getting--
and actually, it links a little bit to extrinsic rewards.
By getting rewarded, getting feedback on my performance,
it's going to help me do better.
Empowerment, giving ownership.
So raise your hands if your team uses assigning tasks or taking
tasks.
So assigning tasks, raise your hand.
If your team assigns tasks to individuals.
That team.
Kind of?
Yeah.
You assign, so there's one person on your team
that says you are going to do this.
Has anybody tried ownership, where
someone takes a task from a set of tasks that are available?
Little, little.
When does that work?
When does ownership work?
AUDIENCE: [INAUDIBLE].
What's that?
AUDIENCE: When people are eager to work,
and they're interested in what we're doing.
PROFESSOR: So there's some of those other things.
There's some enthusiasm over it.
Yeah?
AUDIENCE: It's usually a while before the deadline, too.
PROFESSOR: OK, cool.
Yeah?
AUDIENCE: You can run into problems
if you say who's going to do this, and nobody volunteers.
So my experience has been that it's good
if people can volunteer for tasks that they're
enthusiastic about, but then, if nobody will volunteer
to do something that needs to be done, someone has to step up
and say, OK, you're going to do this.
So it's like kind of a hybrid [INAUDIBLE].
PROFESSOR: So where does-- yeah, go ahead.
AUDIENCE: Yeah, and I think also,
it depends on if everyone on a team
is willing to take ownership versus, like, only some people.
Because that'll create a different dynamic.
There's some people who are really taking initiative,
but the others aren't, so you're still going
to need to assign them tasks.
So I think something that's where
at the beginning ask for people to take ownership,
and then the tasks that are left,
there's one person who's going to delegate this out.
PROFESSOR: So at the beginning, everybody takes on tasks.
And at the end, when you have the leftovers,
they get assigned.
Yeah, Matt?
AUDIENCE: One of the biggest problems
I've seen with this is when you're not thinking
about the game you are working on,
especially this is very easy since we have
a lot of other work, then things can stall, because you're not
thinking about what kind of game,
so you're not thinking about being passive.
PROFESSOR: So you might not actually have ownership.
It might look like you had ownership.
There is the evidence of ownership
in that someone said, OK, I'll take that task.
But there's no follow through, there's no commitment.
And that gets to the next one, commitment.
The best way to have commitment on your team is for one person
to be committed to express that commitment,
to express that loyalty.
For everyone else to see that loyalty
and see that commitment, and then
hopefully they pick up the ball, and they're like, OK,
I'm going to be committed, too.
If that second person doesn't do that, pick it up,
then it doesn't travel through the chain,
it just doesn't happen.
Even though that one person went out
of their way to show that kind of sacrifice,
it just didn't get picked up.
Do see that chain happening on your teams,
do you see it breaking?
Can you identify where that breaking point is,
and can you think about ways to fix that?
Trust is a big one.
So raise your hands if you have worked
with the majority of people on your team
before, in some fashion.
This class or other classes.
You feel like you know your teammates.
Raise your hands if you feel like you really
know your teammates, you've worked with them before.
High if you really think so.
So one, two, maybe.
One, two, three.
So think about how well you know each other,
think about ways you can figure out how
you can know each other better.
Social interactions.
Going out for coffee, going out for lunch, things like that.
Is there something that you can do that will
help that kind of thing happen?
And then here's the big one, this is the MIT one, stress.
Stress tends to be the negative.
It can be positive, in that it's the end of the project,
and it's due, and you just need to get things done,
and that could lead to crunch.
But then there's also the huge negative aspect of stress,
and that's very much an external factor, for the most part.
It could be in an internal factor.
If there's some stress being caused by internal things
going on with your team, it's likely related
to one of the ones above it.
So one way to think about these 7 things,
you can think of them in terms of the desirability
to learn new skills, or the desirability to take on task.
So if you're trying to come up with strategies
with your team on how to solve some of these problems,
think of it in those two terms.
So how do distributed teams perform?
So what do I mean by distributed?
What is a distributed team?
Yeah?
AUDIENCE: Chopped up into groups, and each group
is working on its own secret?
PROFESSOR: Yeah.
Or just everyone's all over the place.
It could mean that you are in Singapore,
and someone else is in Ohio.
You could be separated by time zones, by oceans.
And really, I think that might be east campus and MacGregor,
maybe.
It could just be through distance,
it could be through your schools, could be through
your departments, your majors, whatnot.
There's some kind of boundaries going on between people.
In this case, it's largely time.
Some people can work during some hours,
some people can't work during those hours.
So what have you done so far to fix that?
And think back on the postmortems you've given us.
What are some of the strategies you've already used and seen
used to figure out how to work across different time periods?
AUDIENCE: Well, right now, we're using Slacked,
which is pretty helpful.
[INAUDIBLE]
PROFESSOR: What's it called?
AUDIENCE: Slacked.
It's like Flowdock.
PROFESSOR: It's like what?
AUDIENCE: Flowdock.
PROFESSOR: What's that?
AUDIENCE: It's group instant messaging.
PROFESSOR: Yay.
AUDIENCE: And it keeps track of all our assigned tasks.
And also, [INAUDIBLE]
PROFESSOR: Cool. anybody else using group IM, or an IRC chat?
Yeah?
AUDIENCE: We're using something called [INAUDIBLE],
which is like a chat tied to your GitHub.
PROFESSOR: Cool.
AUDIENCE: I think Skype also just allows
communication [INAUDIBLE].
PROFESSOR: Cool.
OK.
It's great when it can hook up to the things,
and it works with your workflow.
It's also just great to have just period.
If you don't use any of those, maybe think about Skype.
Any other things people use?
Yeah.
AUDIENCE: In my experience, let's say
we're working on something, and [INAUDIBLE] at that point.
It would be good to keep the whole team informed
of all the programs, what's happening on your grant.
So we really like to just use a Google Doc explaining exactly
what you have done so far.
PROFESSOR: So reporting.
I remember some people had issues with email
on previous teams.
So anybody still using email as a primary
means of communication on your team?
How's it working for y'all so far?
AUDIENCE: It hasn't gotten to the hectic point yet.
We think we started talking about emailing subgroups more,
except [INAUDIBLE].
PROFESSOR: Yep.
Are those emails going to be archived and viewable
by everyone at a later date?
AUDIENCE: That would be a good idea.
PROFESSOR: Yeah.
And I think that's why we tend to think about group IMs.
And particularly, Philip likes IRC for that very reason.
Certain IRC servers will keep an archive for you.
Other kinds of groupware will do that too,
but they tend to be pricey.
Has anybody started using Trello on your teams yet?
Yeah?
Are you using it as a communication method,
or as a recording of things?
AUDIENCE: Recording of things.
PROFESSOR: Anybody using that as a communication method at all?
Trying that out.
Because I think it can do email notifications and things
like that when things change.
Assigning members to tasks, stuff like that.
All right.
So again, we got talking into tools.
What other things can we do?
So another paper that it's going to be on Stellar if you want
to look at it was basically a survey
of distributed teams using agile processes,
and giving up some best practices of what
worked best for them.
And I was nice, and I'm just give you the summary of that.
So one thing they noticed is having a one team mindset
was the thing that got them through working together
as a group.
What do we mean by one team?
That the group first identifies as a team,
like what we talked about before.
They all have a goal that they're going towards,
they all identify as going towards that goal.
They don't identify as just an individual group.
But that's actually a major part of their identity.
For them, it's because that's their 40 hour, 80 hour, 120
hour work weeks.
Something I think you you're going
to have an issue with, because you're working
smaller periods of time.
But the way they're able to do that is they've
got these frequent team interactions.
And actually, when they're working
for a long period of time, there are
people who are working on their own
in their home or their home office
with another team that's very far away.
And yet, these teams still do a daily stand up.
Does anybody here do a daily stand up on their teams
right now?
So what they're doing is they're going on video,
they're talking to each other for a very short period of time
about what they've done, what they're going to do,
what's in their way.
The cool thing with daily stand ups,
and why they think this works for them,
it goes back to those seven items
I listed about how you get people engaged on a team?
It shows commitment.
The fact that there are people who are showing up to meetings.
There's some kind of personal sacrifice.
Some people are meeting at a very strange hour of the day
that they're not normally going to meet,
and they're doing that because of the team.
They're sacrificing something personal for the team.
Everyone else on the team sees that, they
see that kind of commitment.
They feel like they need to reflect that back themselves.
Also trust.
And in this particular case, it's
the trust of not letting meetings take too long.
These daily stand ups really should only take 10 minutes.
An effective team can do it in five.
An effective 10 person team.
30 seconds each, go, everyone says what they've done.
Everyone sees each other's faces.
The great thing about seeing each other's faces
is you can see what stage of fear and anxiety they're in.
And you can then talk to them later,
and have some other personal interactions with them.
The other thing they do, they do co-located work.
They've got money sometimes, so they're
flying people back and forth.
But again, they're also doing co-located work
by doing things, having Skype always on in the background
while they're working together.
But they're not doing it the entire time,
they can't afford that.
So one thing you can do is to schedule your co-located time
at the beginning of the project, which is basically
what we've been doing in class for the past few weeks.
Identifying important milestones, and making sure
you've scheduled a co-located period during that milestone,
right before that milestone is going to help you greatly.
Doing insert teams, and doing video chat.
And here's a big one we haven't talked about in class so much,
but I get the impression that some of you
might be interested in this kind of thing.
Having coaches.
So we've already seen some of the teams
have a dedicated scrum master or producer.
Think about having a dedicated coach.
So someone who's on your team, who's
there to cultivate team spirit.
They're going to emphasize the importance of one team.
They could be your scrum master or producer,
but they're not actually the same role.
The scrum master or the producer is measuring productivity.
They're measuring tasks on how well things get done.
The coach is very different.
They're looking at how people interact with each other,
how people talk to each other.
How people work with each other.
Oftentimes, people who are naturally inclined to do one
can be inclined to do the other, but that's not always the case.
So if you have someone on your team
who is one of those extroverted, outgoing, or even introverted
but really interested in what individuals do one-on-one,
and how individuals work.
See if you can incorporate some coaching strategies
with your teammates.
And again, you can do one-on-one meetings,
and we can talk about this in the future
if you're interested in this kind of stuff.
We can unpack on this topic and talk about it further.
But I highly recommend it.
So I did mention meetings.
You do have agile meetings, these people
have agile meetings.
These are what they are.
So who has a formal sprint process, where you plan
your sprint before you start?
So you basically create your sprint task list at a meeting?
Is everyone there?
Not everyone's there.
AUDIENCE: We have the tasks, and we've focused [INAUDIBLE].
So we do have a formal week-by-week, here's
what we want to get done this week.
PROFESSOR: OK, cool.
And you had a meeting to create that?
Then you have your daily stand ups.
At the end of the sprint, you want to have a sprint review.
Just basically the inverse of the sprint planning meeting.
You go back and see what you made.
Hopefully, you have a build and you just basically
look at the build, compare the build to the completed tasks,
and make sure it matches.
The other meeting that you may or may not be doing
is the agile retrospective.
And that's how did you work this week?
Is anybody doing that, is anybody
at the end of their sprint, talking
about the processes of what you did and how you did it?
OK.
It's what I expect.
I think you're doing yourself a disservice
if you're not doing that.
And particularly, if you are doing that
and you're making that a face to face meeting,
that's the time when you can talk about some
of these interpersonal issues.
That's the time when you can talk
about your feelings, that's the time when you can open up,
and try to figure out what is about,
why are some of these tasks not getting taken on,
who's not doing them, and what's in their way from doing them.
But really, it's not really about what's in the way,
it's difficult to talk about.
It's not about what's in their way,
but it might be about what outside
of the project and outside of the team could be in their way?
And can you work through some of those issues?
So I'm done.
What I'd like you do before you go and work in your teams
is schedule a sprint retrospective.
So take a look at your sprint process.
How long is your sprint?
Is it one week or two weeks?
We've been assuming it's one-week sprints.
Schedule a time period that everyone can attend,
and an amount of time that they can attend.
That they can see each other face
to face, but not necessarily are in the same room.
If they can be in the same room, awesome.
If you can't, try to figure out a time
that you can chat using Google Hangout, or some other kind
of face to face video chat.
Make sure the meeting is focused on talking
about your processes.
So don't talk about your game, don't talk about the work
that you've done.
Talk about how you organized yourself.
And in particular, talk about your interpersonal matters.
Basically, communicate about communicating.
So talk about how you're talking to each other.
And yeah, I want to talk to you about this again in a couple
weeks.
I think most of you right now are probably
in the concepting phase, pre-production phase right now.
You're still figuring out your game,
you haven't quite-- I guess you guys are actually
working on your back end, because someone
did the initial design for you.
The rest are probably still working out the design phase.
When I talk about this again, you'll
likely be in full-on production mode,
and so some of the activities I'm going to show you
might hopefully help when you're doing these meetings.
Any questions?
OK.
So it's 1:50.
Go ahead and take a few minutes to break,
and then the rest of the class is yours to work in your teams.
But still do this.
[SIDE CONVERSATIONS]