Explore
For Enterprise
Join for Free
Log In

Arts and Humanities
Business
Computer Science
Data Science
Information Technology
Health
Math and Logic
Personal Development
Physical Science and Engineering
Social Sciences
Language Learning
Degrees
Certificates

Explore all of Coursera

Browse
Search
For Enterprise
Log In
Join for Free

Agile Teams Meet Waterfall Processes

Loading...

Managing an Agile Team

University of Virginia

4.7 (492 ratings) | 23K Students Enrolled

Course 3 of 5 in the Agile Development Specialization

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.

Skills You'll Learn

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

Reviews

4.7 (492 ratings)

5 stars
360 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.

From the lesson

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

Taught By

Alex Cowan
Faculty & Batten Fellow

Transcript

Let's talk about using Agile with non-Agile stakeholders.

So those could be audiences inside your company or external customers,

other partners that you're collaborating with.

Here we have this Gantt chart again, this sort of non-Agile thing.

And to draw a parallel, I will have entrepreneurs creating new ventures

come to me and say, well I know there's a lot of uncertainty inherent in my venture.

And that, from my prospective, the right investment of my time and

the guiding items I want to use to manage my team, it's not a business plan.

I know that it's overly elaborate for what I have visibility into.

But, I have an investor that I need to have and

they're demanding a business plan.

Well, what I would tell them is if that's the case and you really have to do it

make sure you understand what they need out of that business plan and

do your best to give it to them.

But, don't necessarily go back and run your company with that plan now.

It doesn't need to change the way that you operate.

You have an idea about how you should operate, and

then you have certain audiences that you need to satisfy,

so the job is not to change the way you do business,

it's to satisfy the stakeholder with whatever it is exactly that they need.

So use your design thinking tools, for instance, finding the right problem and

then driving forward to the right solution instead of just saying,

okay they need a business plan.

I'll go and write a business plan.

Because that's very wasteful.

A. You may not be

giving them exactly what they need, and B.

You're going to be spending a lot of time and confusing the issue for

yourself internally.

We want, and let's say this is a manger inside your company.

Well, we want our managers to be perfect.

We want to go to them and say hey, I have these ideas for

using Agile and product design principles, isn't this really great,

we're going to fail fast and they say no, my God,

I think I'm going to get in trouble with my boss because this is too crazy.

You know, make sure you know your audience and nobody's perfect.

A lot of these ideas may be new to them.

They may not have had the time to understand them in the way that you have.

So make sure you understand what they need and

go to them with an audience specific message.

And if they need things from you that are sort of contrary to Agile in certain ways,

figure out what the real problem is that they need to solve and

then figure out what the right solution is.

And focus on that and doing the right thing rather than completely following

some arbitrary script that was created for, who knows why and

probably doesn't conform with Agile.

So here are a few specific examples and

a little bit of sort of mini narrative to describe the situation.

The first one is ask for generalized budgets vs specific headcounts.

Where does this come into play.

Well, very frequently, I'll work with a big company and we have an Agile team.

They're doing a new product or a new system internally and

they've done their first couple releases and they're killing it.

It's great.

So their manager says hey, nice job guys, and congratulations.

I'm going to take your team from seven to 28 next month so

we can pour fuel on the fire and scale this thing up.

Now Agile absolutely scales, but as you know it scales in small teams.

So they can't immediately go from seven to 28 people,

it's not that kind of situation.

So they know that that'll kill the golden goose, and what does this manager do?

If it's a big company they don't want to miss out on the budget cycle.

On the other hand they know that they're going to be mostly

spending time trying to figure out what these other 21 people should do, and

they're going to be expected to dramatically ramp up their output,

which they're not sure they'll be able to do.

It really is a difficult situation.

So, one tip is to ask for a generalized budget versus a specific head count,

kind of like if you were managing your own PNL almost.

And the idea is they're going to say hey,

great job, we want to ramp up the team and you're like what am I going to do.

And you want to explain to them that Agile can scale because you don't want them

to come to the conclusion that your team is permanently small and they can't

invest in it because it probably is a good place for both them and for you to expand.

Just not quite that quickly.

So instead, they may tell you hey I need to submit a budget.

And then that's you know their specific problem.

Well do they really need to submit individual role by role head counts or

can they just submit a general number?

You don't talk to them about that because you're probably not sure exactly how many

devs versus testers versus whatever else you may need.

And maybe you need money to go travel and

see your offshore team or go on a research visit to look at users.

And so, as for generalized budget, explain to them why and

see how that goes rather than just filling out the template.

And here's a second tip.

Collaborate on specific objectives and

agree to a process rather than an arbitrary schedule.

And this is for the situation where management has come to you and

said, look we have this big initiative.

Let's say, we're rolling out a new sales force into the marketplace and

your software is going to be the thing that they use to manage all of this stuff.

So I need a detailed schedule with dates because that's what I think I need to

make sure this whole thing is going to fit together and be okay.

Well,it's not a completely unreasonable thing for them to ask.

They know that they need software to power the sales force and, yet,

you know that if you lock up all the specific details and

that's what everybody thinks is the definition of success.

You're very likely to build something that's very inferior to what you could've

delivered if you were using these Agile processes.

So my recommendation is, instead, to work with them

on what is it that we exactly know that we need for this audience.

I mean, do the things that you've learned how to do already.

Go learn about those salespeople, learn about the channel,

show them how you're going to find out what makes sense and tell them about.

Not in great detail, but tell them about your iterative process and

how you can keep them informed about how things are going and

then thirdly, focus on those thin slices.

So remember, think about first, okay, let's talk about what we know about this.

What would we absolutely, positively, have to have on day

one of this sales force being out in the field to make sure they're okay?

Because it may be that their mindset is, well,

we should try to cram as much software in as we can because that increases

the odds that this sales force is successful.

But as you know, that's a fallacy,

especially if you're trying to schedule this out in advance.

Instead focus on nice, thin slices.

Try to test those early.

Tell them hey, I want to see these sales people before we even roll out the whole

grand scheme of how they're going to use the software and what they're going to do.

Let's try to get them in in two weeks and test some initial stuff with them, and

make sure they can use it, so that is my recommendation.

The tension will often be, well the Agile team doesn't want to agree to anything

because they're doing Agile, and I have all this stuff I have to orchestrate.

Well, agree to a specific process to help work with them and

make sure they get what they need instead of a specific schedule with

lots of detail that's predicted in advance.

Here's another example, here this happens all the time but

we need more specific dates for a marketing or PR thing.

The same basic thing applies.

What do we want to be able to say about ourselves?

Let's talk about that and then I'll figure out what functionality and

work with you on it is going to be impressive, and link with your

narrative the story you want to tell through these marketing and PR channels.

And, okay.

This is sort of the solution of last resort.

If all else fails, if your ability to find the right problem and

work iteratively with your stakeholder to get to the right solution just fails.

And they say look, it's your job to make a schedule.

Just get me a schedule.

Then keep your deliverables very general because

you don't know enough to be more specific.

It's unclear what they need to be able to do with this schedule.

So, their going to tell you, look I just need dates,

give me a schedule, I don't care about your Agile, or whatever.

So, if that's the case, give them a schedule, put items in there, and

make them as general and implicitly make them as sort of problem-focused

as possible, so for instance.

Let's go back to the sales channel example.

So let's say, hey, release 1.x is a solution for account entry.

Well, there are going to be accounts, they're going to have to be entered.

Let's say you feel like you know that, that's probably okay.

Now that doesn't stop you from saying all right, well let's step back,

look at the problem of what these people need to do, they need to sell stuff and

back into this.

It's probably sufficiently general that it's not going to

pin you down into something that doesn't make sense.

Do you want to do account stuff first as your first iteration, maybe, maybe not.

But it probably won't be something terrible so think about how you can frame

the deliverables in terms of problems, implicitly or explicitly.

And then create the best schedule you can, but try to avoid having it giving up and

having it dictate exactly what you do each step of the way.

And then continue, don't give up on your stakeholder either,

continue to try and understand better as you go along how things are working for

them, use short cycles, try to put working software in front of them so

that you can learn about what they really need.

So those are a few techniques for working with internal stakeholders

who are not operating with Agile principles and cadences and

how to get them what they need while still being successful with Agile.

And we're also going to look at here shortly

how you can work with big customers.

This is another thing a lot of big companies have.

And solve a similar type of problem where they feel they need advanced dates.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.

© 2019 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play

Coursera
About
Leadership
Careers
Catalog
Certificates
MasterTrack™ Certificates
Degrees
For Enterprise
For Government

Community
Learners
Partners
Developers
Beta Testers
Translators

Connect
Blog
Facebook
LinkedIn
Twitter
Instagram
YouTube
Tech Blog

More
Terms
Privacy
Help
Accessibility
Press
Contact
Directory
Affiliates