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 Teams Meet Waterfall Processes
Loading...
From the course by University of Virginia
Managing an Agile Team
356 ratings
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.
Meet the Instructors
Alex CowanFaculty & Batten Fellow
Darden School of Business
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.
© 2018 Coursera Inc. All rights reserved.
