Explore
For Enterprise
Join for Free
Log In

Arts et humanités
Business
Informatique
Science des données
Technologies de l'information
santé
Mathématiques et logique
Développement personnel
Sciences physiques et ingénierie
Sciences sociales
Apprentissage des langues
Diplômes
Certificats

Explorez l'intégralité de Coursera

Parcourir
Rechercher
For Enterprise
Connexion
Inscrivez-vous gratuitement

Getting Started

Loading...

Managing an Agile Team

Université de Virginie

4.7 (490 notes) | 23K étudiants inscrits

Cours 1 de 5 dans Développement agile Spécialisation

While agile has become the de facto standard for managing digital innovation teams, many wonder if they’re doing it ‘right’. Twitter is full of jokes about how teams say they do agile but don’t ‘really’ do it. The reality is that getting the most out of agile is less about observing specific procedures and more about how a team focuses and measures their progress. Rather than just boring you with an accounting of agile methodologies, this course focuses on helping you better charter your team’s focus, definition of success, and practice of agile. While learning about agile mainstays like Scrum, XP, and kanban, you’ll also learn to help your team ask the right questions about how they’re working and facilitate good answers on how agile can help. By the end of this course, you will be able to: - Explain the definition of agile and why various agile methodologies may or may not make sense for your team - Create an agile team charter that helps your team define its focus and success criteria - Facilitate retrospectives with your team to iteratively, collaboratively improve your practice of agile 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.

Visualiser le programme de cours

Compétences que vous apprendrez

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

Avis

4.7 (490 notes)

5 stars
358 ratings
4 stars
104 ratings
3 stars
25 ratings
2 stars
2 ratings
1 star
1 ratings

SA

Jun 05, 2019

I've really enjoyed this course on Managing an Agile Team. Comprehensive with a mix of insights from industry experts, case studies and great instructions on best practices from Alex.

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.

À partir de la leçon

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.

Getting Started6:55

Yael Grushka-Cockayne on Transitioning from Traditional Project Management8:27

Spotify: Scaling Agile3:34

Salesforce: The Big Plunge8:30

Yael Grushka-Cockayne on Project Managers and Agile6:23

Enseigné par

Alex Cowan
Faculty & Batten Fellow

Transcription

This is an exciting time.

You're going to introduce Agile with your team or

your going to maybe reboot your practice of Agile.

You're going to make your company a better place.

You're going to learn a lot of new skills that are going to make you stronger in

your career, and probably more satisfied.

Let's talk a little bit about things you should think through as you get ready to

introduce Agile to your company team, whatever your scope of activity is.

The first question, I would ask, is why?

Now, why would you want to do Agile?

There are a lot of good reasons.

Maybe management looked at some companies that they admire and

they said, these guys are doing Agile, maybe we should do Agile.

And I would never fault a manager for making that kind of observation.

It's a good idea to look at companies you think are executing well and think about

whether some of their practices would make sense in your organization.

However this is not a good way,

this is a very arbitrary way to introduce it to an individual team.

So before you introduce it to the people that are going to actually be executing,

I would think about, we think this is a good idea, why

is it going to be good at our particular company or for our particular product?

What jobs, what problems do we think are a, important,

and b, things we could do, places we could do better?

What outcomes do we want to get from actually doing Agile?

And I would test that, think about it, and once you get something you like, I would

decompose that into what does that really mean for a product or project manager?

What does that mean for a developer, a tester,

all the roles that are going to be involved in this interdisciplinary team.

How do we take this outcome that we want to do better at and

what would it mean for all those different roles.

I would get to that level with your kind of Agile charter

before you go to a team and say we're going to go do this.

Otherwise, you run the risk of it feeling kind of arbitrary to them.

And it's very hard to have a self-organizing team that's

successfully self-organizing against an objective that they don't understand or

don't really buy into.

Next I would think about where to do this.

Now we talked about this before, everything else being

equal probably the best place to do it is a kind of Goldilocks project.

So, not so big that you are under enormous pressure to save the company or

the product, and not so small that it's a hobby and

people are working on it part-time.

So something that's important material, every team member,

the whole team is going to be focused on it.

That's probably the right place to start, and

then you kind of want to look at who is going to be on this team.

And ideally of course, you want volunteers,

people that think that this Agile experiment is a good idea, it's good for

the company, good for the product, good for them individually.

It's going to make their career better.

And I would take your Why and translate it forward to this Who.

Remember how we talked about how each user story should have it's own discreet

reward?

Something that we know the user got what we think that

they wanted from this little narrative, even if it's super small.

Well, think about that when you address the who.

So think about we have this success definition, what does that mean for

a product manager?

And what are the first few things that should start happening for

them in this practice of Agile where they know that it's working.

So is it that they're going to get more time to spend with customers or users and

really understand them in a way that they've been wanting to?

And for example, what does it mean for a software developer?

Are they going to get to see their product in action with customers sooner and

more frequently so they can understand the significance of what they're building?

Is it that they've been wanting to try some of these techniques from XP like

peer programming or test-driven development.

And they didn't have the time, or the training, or

the space to give those things a try and they like that idea.

What about the tester?

Is it that they now get to spend more time doing automation?

Or learning about some automation techniques they've been wanting to

learn about but haven't had the time or the space to do.

Those are just examples.

You need to figure out what those really mean in

collaboration with your prospective Agile participants, so

that you have a nice clear idea of what you're doing, who's doing it and why.

So that you can move forward into a strong self-organizing situation.

An Agile friendly environment where everybody's bought in to this idea that

these techniques, this working environment will help you

iterate to more valuable outcomes for your user.

And then you gotta figure out the how.

What Agile methodology are you going to use,

or what pieces from what methodologies are you going to use?

And everything else being equal, less is more here.

I would pick the Agile techniques that you think are really important.

Try those out, and as we discussed before,

I would apply them relatively specifically and rigorously while you're using them but

evaluate them frequently and collaboratively as an experiment.

And the worst thing that you can do is use a lot of these practices and

use for instance Scrum as a crutch.

Well just, you know, do everything the Scrum book says because that will work.

Those very people would tell you that it's really your judgement and

your application of those techniques and

the principles behind them that's going to make you successful.

So, don't use the methodologies as a crutch, or even worse,

a whip to make people do things that they're not bought into.

Think about how you're going to do it, agree on that as a team, try it out,

view it as an experiment.

And then, iterate.

And this is the important thing.

I think you've heard this a lot, and you will hear this from other practitioners.

It's important to iterate, no Agile practice is ever perfect,

it never ever is, it can always be better.

And especially in the early days, it's like maybe

if you've ever learned how to go skiing or surf, or maybe roller skating.

I mean you're going to fall down, bad things are going to happen,

you might even hit a tree.

But it's important to get up again, give it a try and evaluate what's working,

why things didn't go the way you wanted and figure out what makes sense.

So, in the subsequent material here we'll talk about a few examples of

how this happened at various companies.

And I would encourage you to talk to your friends,

talk to your peers if you're in the software business.

I'm sure you know lots of people.

What worked well for them with Agile, what didn't?

What did Agile mean to them?

All that stuff will really help you with this

thing that you know the one hand is extremely powerful and useful.

And on the other hand, takes a huge amount of individual judgment and

practice to get right.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2019 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play

Coursera
À propos
Direction
Carrières
Catalogue
Certificats
Certificats MasterTrack™
Diplômes
For Enterprise
For Government

Communauté
Learners
Partners
Developers
Beta Testers
Translators

Se connecter
Blog
Facebook
LinkedIn
Twitter
Instagram
YouTube
Blog Tech

Plus
Conditions
Confidentialité
Aide
Accessibilité
Presse
Contact
Répertoire
Filiales