Skit: Retrospective #6

Loading...

From the course by University of Virginia

Managing an Agile Team

473 ratings

University of Virginia

Managing an Agile Team

473 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

In this skit, the team is several cycles in.

So they've finished a few iterations, and

they're doing a retrospective on their last iteration.

You'll hear references to additional members of the team.

We didn't have people to be on camera, so

you're just going to see these three folks, even though I would normally

recommend that you have everybody on your core team in these retrospectives.

>> All right team, thanks for getting together again today.

We're here to do a retrospective on our last sprint.

We want to talk about what we think we should keep doing,

what we should change and do better.

Everyone makes mistakes, the point of this meeting is not to point the finger and

blame each other, we just want to have a productive discussion about our approach.

And see if we can refine and improve.

I'll start.

The product owner role is starting to take up more and more of my time.

It's probably 75% at this point.

I'm still doing the testing piece.

I've been staying pretty late.

And I think for more rapid scaling as we move forward,

we ought to think about how we're going to add some testing.

Further testing capability.

So Shri wanted to talk to you about whether or not we should hire someone,

whether you think we should maybe go with an outsource option.

I found an agency that can do some testing for us.

What do you think?

>> We definitely want to hire someone, but I think we should do an on-site hire.

We really want a tester who is here in person.

Testing is pretty complicated, or more complicated than it seems.

And we want to test at the lowest possible level, just so,

we don't want to catch something too far along during functional testing

that we could've caught way earlier during unit testing.

And it's pretty good to work with someone who's on-site rather than off-site.

>> Okay, but you still want to hire someone?

>> Yeah, definitely.

Since automation has been up with the one tester that we have,

another developer would actually be better than another tester.

>> Are you sure about that?

>> No, I'm not certain, but we'll have to see.

In about two weeks, honestly, I think that when we've gotten a lot more

automation we'll probably do fine with just one tester.

>> Okay.

Gotcha, so another question I have for you.

Velocity overall is up, we haven't seen much of an increase in the last two weeks.

Do you think we've plateaued at this point?

>> No, I don't think so, I think things are actually improving.

We've had a lot more bugs in the velocity, but it seems like a lot

of them might be due to little refinements or tunings that we need to make.

>> Okay.

Well, my fault on the tracking.

We'll get that fixed.

What do you think is causing more bugs in refinements?

Is testing struggling?

>> I honestly don't know.

No, testing is doing pretty well.

>> If I had to guess,

it's just that that the word's out, more of the techs are using the software, so

we're going to get some suggestions, we're going to see more bugs.

>> Right.

Okay, well that makes sense.

We haven't looked at the data recently but we should probably do that at the end of

this cycle to validate that hypothesis and track our ratio of bugs to usage somehow.

Shri, any issues?

>> No, things are going well.

I've spent a lot less time as score master and I think that's because everyone's just

doing a really good job of working independently.

>> Great. >> I can see a lot more potential for

our work, though, but I think I"m going to let everyone continue with their

self-organizing and independent work before I decide to make any changes.

>> Okay, well now that part ordering is looking good,

the big thing we'll be trying out our problem scenarios from dispatch.

Shri, what do you think there?

>> Well it looks like the inputs from dispatch seem a little light and

uncertain.

It's like the problem scenarios and

user stories just aren't as strong as they once were.

>> Yeah, no, I totally agree and I think what we should do is get out,

do another design sprint, and take everyone out in the field for

observation so we can tighten up our problem scenarios.

>> That's a good idea.

>> Do we take everybody?

The whole team?

>> Yeah, I think so.

I mean the developers could be working on refactoring or

they could be helping with the technical debt.

But honestly, I had so much like a good experience in the field, so

I think everyone should go.

>> Okay, cool.

Well, that's it for me, are there any other outstanding items?

>> Not on my end. >> I don't think so.

>> Okay, great.

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