Bill Wake on Support Escalations

Loading...

From the course by University of Virginia

Managing an Agile Team

327 ratings

University of Virginia

Managing an Agile Team

327 ratings

Course 3 of 5 in the 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.

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

Meet the Instructors

Alex Cowan
Faculty & Batten Fellow
Darden School of Business

I'm here with Bill Wake, a 15 year plus veteran of Agile, and

major contributor and thought leader in the space.

Thanks for joining us Bill.

>> Hi, thanks Alex.

>> Let's talk about support escalations.

The team is trying to do Agile, and part of the premise is hey,

we're going to get good flow time here.

And you're going to have two weeks where you know what you're working on, you know

what success is, and then boom, all of a sudden all these unexpected, two or

three escalation, escalation development come into play, how do you manage that?

>> Well, I think it's just if you're a team like a Dev Ops type team,

you're doing development in operations, you're going to have those

>> Those things happen, so in some sense,

you're trying to be prepared for those as they come and just deal with them.

The fact is if we're spending half our time on support this sprint,

we're probably not going to be spending 100% of the time on

developing new features that we had hoped for.

>> You know over time you can kind of figure out the level at which

things tend to run and different teams handle this different ways.

I've seen a team that they sort of designate one person per sprint to

say you're the first line for the team and if something

comes in you deal with it if you need more help we'll give it to you but our team's

assumption is you're pretty much going to cover it for this time and sort of setting

a one team member expectation and adjusting the planning otherwise.

As the teams get more In the continuous deployment,

it becomes less of an issue that they're just taking whatever it comes next anyway.

They weren't going to be spending two weeks,

they were going to be spending a couple of hours or half a day or something and

if it turned out the next thing is a support thing Then, let's do that.

Or if we have to drop what we're doing then we'll do that and

get it moving through.

>> Let's talk about the relationship between those two things content wise.

Is it hard for teams to look at support issues and

get into the habit of saying, alright,well is there something we can do differently

about the way that we're building the product or deploying it to users?

That can reduce our support escalations versus okay, well,

we thought we wanted to develop this new stuff.

Is that a hard balance to strike?

There's this idea of new development, and Is different than sustaining engineering.

How do you find teams, strike the right balance so

that they reduce the amount of support escalations they get?

>> Well one thing is over time,

we're trying to build a better level of quality into things,

because we recognize that if we say something's done,

but it really isn't because we have this kind of quality gap.

And at some point we have to pay that back.

And we can either make it better now and leave out the gap.

Or we can leave the gap and then we have to

>> To go support it later and, you know,

it's interrupting it's a pain it's all that.

Then, you know, we can see justification for doing things now to find out that.

And, you know, the teams I know that do well on things,

they have retrospectives or more ongoing continuous kind of things.

And they try and explore.

We have in the lead startup there's this notion of like a five wise

analysis to say what caused this problem, or how did this occur?

And really dig in to say let's find something now,

we'll fix the immediate thing.

We'll invest in up the chain of the wise and fill in to say,

make this one a little better, a little better, a little better and

then the things that go wrong all the time tend to be less frequent.

Another one, the XP people that's been around a good long

while as he calls it the street light theory and says if you have a town and

there's, it's all dark and you're going to put in street lights.

Usually the two places are you'll put street lights on busy streets because

you get a lot of benefit from it for the people who are there all the time.

And you put them in the streets that are maybe a little crime ridden.

And. >> [LAUGH]

>> They need a little more safety

there and.

And that of corresponds to what we're doing here as the team goes through you

know the primary correspond to the defects, and as we hit and

support fixing those defects we add the extra supportive tests and

looking at our process and so on and you know

kind of get the street lights there to make the flow go a little better overall.

That's some great advice on managing the practical realities

of what happens in development cycle versus what we plan.

Thanks, Bill.

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.

Download on the App Store

Get it on Google Play