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.
International and Distributed Teams
Loading...
来自 University of Virginia 的课程
Managing an Agile Team
357 个评分
从本节课中
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.
与讲师见面
Alex CowanFaculty & Batten Fellow
Darden School of Business
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.
