Greg Cohen on Prioritization

Loading...

From the course by University of Virginia

Managing an Agile Team

334 ratings

University of Virginia

Managing an Agile Team

334 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

Learning and Deciding

One of the major promises of agile is to manage the complexities of software development for the best possible outcomes and working environments. Part and parcel of that is strong interdisciplinary collaboration paired with lightweight self-organizing management practices. This week, you’ll learn practical tactics from scrum and XP to promote faster learning and smarter decisions, and how you can use kanban to improve your workflow.

Valuable Decisions4:34

Slicing the Lasagna6:25

Managing Work in Progress: Part 15:25

Managing Work in Progress: Part 27:56

The Quagmire of Estimation, the Power of Flow8:08

Demo: Using Trello for Agile2:31

Bill Wake on Estimates and Prioritization3:20

Greg Cohen on User Stories10:33

Bill Wake on Burndown2:27

Greg Cohen on Prioritization4:26

Agile Methodologies and the Job of Deciding6:08

Skit: Iteration Planning4:38

Meet the Instructors

Alex Cowan
Faculty & Batten Fellow
Darden School of Business

I'm here with Greg Cohen, 20 year project management veteran and

an author of Agile Excellence for Product Managers.

Greg, let's talk about prioritization.

It's a pretty important job for a project manager.

How do you do that?

>> So the simple explanation is you prioritize the things of

highest business value first, and it's easy to understand.

But that's extremely hard once again to implement well.

So it really helps to understand what is your goal or objective with each release.

because if you understand that then usually that prioritization

falls out of it.

>> And would you agree that a lot of problems are exacerbated by not really

being sure what's valuable to the user and just trying to cream in lots of stuffs,

instead of being focused on doing a few things really well?

>> [CROSSTALK] That stuff is only our really big challenge and

everyone has their pep thing that they want to prioritize within the company.

So that's where socialization of the backlog becomes really important.

It is also as you said really understanding what is of value

to the user.

It reminds me of an experience I had when I was a younger product manager.

I was working on contract management systems and I came into this company,

it was a new role and they said in 90 days I had to have this product out to

three customers, this was a commitment, we couldn't break it.

It was in that time understand actually what was really needed for

the users and also what the capability in my team was.

And I had a small team which I think at the time I thought was a deficient but

it's probably what allowed us to hit our deadline, but I also had to leave a major

capability out of that system, and I lost so much sleep about this.

And it's really rare I think, when I think about my experiences to

have something that was so binary as this decision.

because often products succeed or fail on hundreds and

thousands of smaller design decisions.

But you put in there, but we left this out.

Our customers were furious, the three users,

they said they would abandon the product, if we didn't fix it.

But the reality is from an MVP standpoint, what was the minimum viable?

My goal was to deliver value to those users.

And they realized value from this more limited release and

when I say they realized value, they saved hundreds of thousands and

millions of dollars using the product as is.

And they opted to use the product as is over not use the product.

I lost a lot of sleep on this decision, thought about it for many years since.

I think for me the true test here, was the fact that when we did release the next

version, it took us nine months to get our

customers to adopt the new version of migrate over to it, which to me says,

the first version did a very good job of delivering early value to them.

>> And- >> I wish the decisions were that simple

and went that well but I think that was one

that was very clear that there was an enormously tough trade-off to be made.

But it was necessary to hit the deadline and get value delivered to that user and

our customers sooner rather than later.

>> And was it understanding that there was a going and talking to customers and

watching what they did and understanding that there was enough value there

without that feature that gave you that confidence to finally make the decision,

or what is just strictly a matter of necessity?

How did you get there with that decision?

>> Well, on these it's tough because you actually,

I went out and talked to customers and spent a lot of time with them but

at some point it becomes a judgement call.

>> Mm-hm. >> And it's a conviction and

I don't think you can know that a priority whether that decision was right.

What I do know is that the amount of time it took us to build version one was just

about the same amount of time as it took us to build version two.

because this capability added that much more complexity to the design and

testing of the product.

So in that sense I had a choice.

I could leave this capability out and get this product to my users in 90 days.

Or I could, actually it took us four months to do that the second version or

they could sit seven months without us delivering any value through them and

we were broken contract.

>> I see.

Great.

Well, that is some great advised on making a hard decisions about your backlog

from Greg Cohen.

Thank so much, Greg.

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