Getting Started

Loading...

En provenance du cours de University of Virginia

Managing an Agile Team

335 notes

University of Virginia

Managing an Agile Team

335 notes

Cours 3 sur 5 dans Specialization Agile Development

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.

À 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

Rencontrer les enseignants

Alex Cowan
Faculty & Batten Fellow
Darden School of Business

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.

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

Télécharger dans l'App Store

Disponible sur Google Play