Explore
For Enterprise
Join for Free
Log In

艺术与人文
商务
计算机科学
数据科学
信息技术
健康
数学和逻辑
个人发展
物理科学与工程
社会科学
语言学习
学位和证书

浏览 Coursera 的全部课程

浏览
搜索
企业版
登录
免费加入

International and Distributed Teams

Loading...

Managing an Agile Team

弗吉尼亚大学

4.7（475 个评分） | 23K 名学生已注册

课程 1（共 5 门，敏捷开发专项课程）

查看授课大纲

Traditional development processes often lead to team frustration and poor results. Agile offers a different approach to managing the complexity of software development. This course focuses on the day-to-day jobs of running a software development program and how leading agile methodologies (Scrum, XP, kanban) can help you do them better. From transitioning a team to agile to running sprints to managing stakeholders, this course gives you the skills you need to manage an agile team in your specific operating environment. We'll show you how to: - Think through and focus on the most important aspects of your projects and sprints - Facilitate your team’s initial and ongoing adoption of the specific agile practices that work for you - Anchor your outcomes and success criteria in durable ideas about what makes for valuable products - Support your team's transition from traditional approaches to agile - Create an agile-friendly environment across functional disciplines - Identify and manage outside stakeholder needs As a Project Management Institute (PMI®) Registered Education Provider, the University of Virginia Darden School of Business has been approved by PMI to issue 20 professional development units (PDUs) for this course, which focuses on core competencies recognized by PMI. (Provider #2122) This course is supported by the Batten Institute at UVA’s Darden School of Business. The Batten Institute’s mission is to improve the world through entrepreneurship and innovation: www.batteninstitute.org.

您将学习的技能

agile product management, Agile Software Development, backlog management, Kanban, XP

审阅

4.7（475 个评分）

5 stars
344 ratings
4 stars
103 ratings
3 stars
25 ratings
2 stars
2 ratings
1 star
1 ratings

DB

Aug 01, 2017

This is an interesting course that provides critical information regarding collaboration with key stakeholders outside the scrum team. I use lessons learned in the course daily.

NJ

Oct 02, 2017

This is a super course... After taking this course now I am really feeling confident to lead a team with more skills. This course taught me how to quantify the team management.

从本节课中

Building, Managing, and Introducing

This week we’ll dive into the jobs of building software and the core management jobs in running an agile team. Agile--and XP in particular--offers a rich body of work on specific coding practices. We’ll step through a few of the most prominent and discuss key linkages with the other concepts and practices you’ve learned. On the job of managing, we’ll dive deeper into what that means and what works in an agile context. We’ll close with ideas and case studies for introducing (or reintroducing) agile to your organization.

The Agile Manager6:27

Creating an Agile-Friendly Environment6:44

Skit: A Developer at Work3:15

Bill Wake on Self-Organization3:03

Bill Wake on Support Escalations4:39

International and Distributed Teams9:16

Skit: Retrospective #64:21

Agile Teams Meet Waterfall Processes10:17

Greg Cohen on Software Development10:10

Agile Product Teams Meet Big Customer5:10

Working with Big Customers: Keeping the Initiative5:21

Working with Big Customers: Accommodating Customer Variations6:15

Skit: Big Meeting with Marla2:52

David Chait on Using Data with Clients7:49

教学方

Alex Cowan
Faculty & Batten Fellow

Let's talk about using Agile with distributed and international teams.

Now I'll summarize this for you.

By the way, do you know what this means?

It stands for too long, don't read.

And it kind of means,

this is an executive summary, that's internet shorthand that young people use.

And the summary here is that,

you've already learned what techniques work with Agile.

You already learned how to create an Agile friendly environment that will

help you drive towards those Agile outcomes that you want.

And all of those same things apply if your team members are abroad or international.

So, you basically have three choices, A, get everybody in the same place somehow.

B, make those employees that are somewhere else, their own discreet,

Agile team, so that they can execute the same plays that you're executing and

create their own take on Agile.

Spotify does this for example.

Or C, you can try really hard to make it work

with a couple of the team members within your Agile team being somewhere else.

And that's really hard and that's mostly what we'll talk about.

In case, for whatever reason, you're in that situation and

you need to make it work.

I will say this, if you have a team or

team members that are abroad, there are a few good reasons for that.

Technical talent is really hard to find and recruit.

So if that's the only place you could find the talent that you need, then hey, okay.

If it's because you are localizing a product and

you want a local team to work on that so that they understand the operating

environment of the buyer, that's a great reason to have a team abroad.

If you're focused on getting the lowest possible day rate per hour then

this may not be the case, but there may be an issue where you're focused on output.

How do we create the most amount of code for the least price, and

that's really kind of counter to most of what we talked about.

Our idea here that we're trying to learn about is let's create

less code that's more valuable rather than let's just generate a lot of output and

hope that somehow we hit on something good.

So with that said, lets talk about

how to make it work if some of your team members are some place else.

And we'll organize this around the four jobs that we have here.

On learning, you're going to need to tell and re-tell your stories.

There's a lot of cultural context that, these team member will not have.

I mean if they're in the mountains of Argentine and

you're in Atlanta Georgia, and let's say that it's the H&H people.

Well probably H/VAC installation repair and

what not works different in the Andes than it does in Atlanta and

so things that were implicit in your narrative that were okay for

your team in Atlanta are not going to be clear or obvious to the team in Argentina.

So one good thing to do is to go there where your team is and

see what it's like and talk to them about the narratives.

Another good thing to do is to make sure you're documenting the narrative.

Now, We will talk about the fact that narrative

is only useful as a collaboration tool, and that there's not this perfect spec

that you can write up and expect everybody to execute just the way that you wanted.

But if the narrative's not available to them because they can't have these

informal discussions in the office,

you'll need to find a way to make it available to them.

Another thing you may find, outside the US, though certainly not everywhere,

is that, a lot of the developers will want, more prescriptive, specific inputs.

And, this may be kind of deep seated.

It may be part of the, way that their education system worked.

It may be part of the way they're used to working with teams that are in

another country and are hiring them.

And that will of course vary from country to country and person to person,

but if you're finding that they say hey, can you just give me this back, or

can you just be specific about what you want me to do.

You're going to have to make sure that you're showing them these principles of

Agile and you're not just telling them no, I'm not going to give you specific inputs

because we're doing Agile and expect them to understand why and what that means.

You can put them on this you can go there and do a workshop for

them and show them examples of how you work.

But, don't expect them to necessarily know how narrative functions in Agile.

It's new to most people even in the most sophisticated operating environments.

Now let's talk about deciding, short cycles and seeing finished work early.

Well, just like it does for a regular Agile team will suss out a lot of problems

early, and help you see those, and figure out which ones are important so

you can work on fixing those with the team.

It's very important to have some overlap time.

I've heard a guideline of at least two hours a day.

I would certainly think that's a bare, bare minimum.

I mean if you have less than that

I think it will be really challenging to make this work.

If you have more than that it will make it a little easier.

If you don't have the opportunity to do daily stand ups together,

try to improvise them some how.

Maybe, for example, have everybody write them up over email or

after people do them in person they send a quick email.

And that's kind of a pain.

And there's a reason why it's not part of the standard way of doing daily stand-ups,

but you might want to test that and just see how it works out for

everybody, particularly with regard to making offshore team more successful.

We talked about this already, but automation will certainly help.

It's self encapsulated, it's available to everybody without a lot of.

Documentation and explanation, and so that'll be an asset that'll help

everybody on the team, and help work through a bunch of other issues that you

might otherwise have, about coordinating builds, and testing, things like that.

And likewise, continuous integration and virtualization will help a lot.

And so this applies to development and test environments, so

formalizing an environment on the working machines that the developers and

testers are using with tools, like currently Vagrant is very popular, and

quite handy for

creating a standardized virtual build of an operating system on a machine.

And then Docker's very popular at the moment, for doing that.

On servers, there are a lot of similar tools.

The idea is to self-describe and automate the creation of these environments so that

you don't have environment-to-environment issues so that it's not a big pain for

the people that are offsite to learn how to do this and

figure it out because they're not sitting next to somebody who did it a week ago.

So that'll help a lot, subtle but important thing.

Another important thing is to do that same set of things for test environments.

So if there is a interface, or software running for some kind of

internal system in your company, make sure they have access to that.

Or that you can create a sub service, like a fake version of it, or something, so

that whatever test tools you find that you need to have to do your job well

are readily available to that team,

because they may try to work around those things.

Again, they don't want to bother you, but in fact,

they're testing against an environment that's not realistic.

As you run through your cycles,

you'll start seeing that Hey, it's weird that this thing broke.

Well, it's because of the folks elsewhere didn't have ready access to the test

environments when they needed them and creates a whole big mess and

that will take a lot more time to fix after the fact.

We've talked about how the whole team is really important in managing And the,

really the ways to work around this are probably relatively self-evident to you.

Lots of open chats, tools like Slack are really good, lots of video conferences.

Maybe even leaving them up for, some cases, for the overlap period.

All that stuff will help.

Invest in the relationship.

So if you're going to go or they're going to come visit you need to take them

out to dinner, your other team members and spend time together.

You may take for granted that you have a personal relationship with your

working team in a way that you kind of

do on accelerated basis if you're working with people that are not on the same site.

This is an interesting one particularly if you're working with collaborators from

another culture a lot another time, and especially if they are on contract and

you're working at the company, they're going to want to say yes sure I'll try to

do that and so one of the important things is what I call getting the know.

Where you know that you have a good working relationship with them if you

explain a bunch of stuff and you ask them does it make sense?

And they say no I don't understand.

Or you ask them do you think you can get this story done by Wednesday?

No I don't think I can.

I need more time.

Well, that's a good sign.

It means you're communicating.

A team is telling you.

What they really think and

that you're getting a more healthy correspondence built up.

So those are a few tip and ideas and alternatives for getting Agile working

when you're needing to find talent in a bunch of different places.

探索我们的目录

免费加入并获得个性化推荐、更新和优惠。

Coursera 致力于普及全世界最好的教育，它与全球一流大学和机构合作提供在线课程。

© 2019 Coursera Inc. 保留所有权利。

通过 App Store 下载

通过 Google Play 获取

Coursera
关于
管理团队
工作机会
目录
证书
MasterTrack™ 证书
学位
企业版
政府版

社区
Learners
Partners
Developers
Beta Testers
Translators

连接
博客
Facebook
领英
Twitter
Instagram
YouTube
技术博客

更多
条款
隐私
帮助
内容访问
媒体
联系我们
目录
附属公司