Session 16: Team Dynamics

• Download this transcript - PDF (English - US)

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]

 

Free Downloads

Video

• iTunes U (MP4 - 98MB)
• Internet Archive (MP4 - 98MB)

Subtitle

• English - US (SRT)