From Project Manager to Product Owner 6 From...

10.5.2017

Copyright © Tieturi 1

From Project Manager to

Product Owner

PMI Agile Workshop 2017

Pentti and Tieturi

• Agile training house with long traditions

• Soprano Oyj • Tieturi, JTO, Infor

• Ph.D.

• IT-pro over 30 years• VTKK, Tietotehdas

• Stonesoft,Tieturi

• Certified Scrum Trainer

• youtube: Pentti Virtanen

• Google: lean developer

From Project Manager to Product Owner

2

Intro to the main

responsibilities of Product

Owner

3


Agile mindeset

Emerging requirements

Reversible

decisions

Emerging design


4

Agile manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan


5

AG

ILE

From values to behaviors

• Because we value < the value>

we have < this behavior>

• Because we value trust we don’t have

complicated controls to check

everything


6

10.5.2017


The 12 principles of Agile software

development

•


7

1. Satisfy customer through

early and frequent delivery

2. Keep development cycles short

(e.g. every couple of weeks)

3. Working software

is the primary measure of progress

4. Welcome changing requirements

even late in the project

5. Business people and developers

work together daily throughout the project

6. Build projects

around motivated individuals

7. Place emphasis on

face to face communication

11. Simplicity is essential

12. Team reflects regularly

where and how to improve

8. The best results emerge

from self organizing teams

9. Continuous attention to

technical excellence and good design

10. Promote sustainable

development pace

AG

ILE

Systems thinking, learning organization, management practices

Lean thinking: create value, avoid waste, WIP,

Agile practices: User stories, Planning Poker, Extreme Programming,

Test Driven Development

Core Scrum: Empirical Process, Scrum Framework, Values,

Flow, Roles, Activities, Artefacts

Scrum Practices: Release management, Scaling ..

Lean, Agile, Scrum, Core Scrum


8

ScrumGuide

LE

AN

SC

RU

MO

TH

ER

AG

ILE

SCRUM+

Scrum in One Slide

• Scrum is a framework for

developing and sustaining

complex products


9

• Roles: • ScrumMaster

• Product Owner

• Development Team Member

• Artefacts• Product backlog

• Sprint backlog

• Product increment

• Visual indicators of progress

• Activity• Product backlog refinement

• Events• Sprint

• Sprint planning meeting

• Daily Scrum

• Sprint review

• Sprint retrospective

• Agreement• Definition of done

Complex

Complicated

ComplicatedSimple

Anarchy

Close to Far from

Certainty Technology Certainty

Clo

se t

o

R

eq

uir

em

en

tsF

ar

from

Ag

reem

en

t

A

gre

em

en

t

SC

RU

M

Scrum Flow


10

Sprint review meeting

Burndown

chart

Product

Owner

Retrospective

meeting

Sprint planning meeting

Daily

Scrum Product

Backlog

Sprint

Backlog

Plan: Tasks

ScrumMaster

Product vision

Development team

SC

RU

M

Product

backlog

refinement

Potentially

shippable

increment

of

functionality

Impact of an agile approach on roles


11

Scrum Team

Product

Owner,

one person

ScrumMaster,

one person

Development

Team

3-9 persons

No

project

managers,

external

specialists,

steering

groups?

Stakeholders

SC

RU

M

Scrum Roles

• Product owner

• High-level vision of the product

• Funding, ROI

• Gathering requirements

• Stakeholder management

• Collaboration with the

development team

• Release management

• Development team

• Cross-functional, no roles

• 3-9 members

• Empowered, self-managing

• ScrumMaster

• Scrum process

• Servant leader not a manager

• Coach, change agent

• Removal of impediments

• Facilitates

12


10.5.2017


Scrum role: Product Owner

• Drives product success• Guides the Team with up-to-date information about

user and market needs

• Creates the product vision• What the project will create, for whom and why

• Optimizes the Return On Investment (ROI) • Obtaining funding for the development

• Authority to make decisions

• Release management• Does not overrule Teams estimates and commitments

• Owns the product backlog• Creates, maintains, updates regularly

• Orders, can reorder at any time

• Can add/change/remove items at any time

• Stakeholder collaboration• Represents the interests of all the stakeholders

• Who are stakeholders?

• Gathering input about the features and understanding their relative value

• Collaborates with the Team• Answers team’s questions


13

SC

RU

M

Who should be a Product Owner

• Has enough knowledge

• Power enough

• Real customer ?

• Time enough


14

Product champion

- Passion for the product

SC

RU

M+

Product vision

• Shared

• Broad and engaging


15

• ConciseSC

RU

M+

Business value for the customer

• Multiple releases with learning by feedback

• Better IT solutions - more business value

• Reduced risk

• Earlier time to market and payback


16

Return - investment

-2000

-1000

0

1000

2000

3000

4000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Month

1000

€

Scrum Waterfall

Minimum viable

product

Investment is 100 000€/month. Scrum team starts to earn after 1 month and the waterfall teal after the whole

12 months. Return on investments have increasing payback times. First investment is paid back in 2 months

and the final in 13 months. The only difference is the start of the payback period

SC

RU

M+

• Lower effort /costs in requirements development

• Faster thru put time due to better value stream

• Better quality

• Financed by the return on investment (ROI)

Product backlog

• Ordered and emerging list of deliverables

• Owned by the Product Owner


17

Ord

er

SC

RU

M

Release management

• Bring the vision to life in the best

possible way

• Schedule backlog items

• Continuous delivery?

• 1000 releases in a day

• Updated Frequently in review meetings

• Plans are dynamic and change

• Emergent forecasts, no promises


18

Sp

rint 1

Sp

rint 2

Sp

rint 3

Sp

rint 4

Sp

rint 5

Sp

rint 6

Rele

ase 1

Rele

ase 2

Releases

10.5.2017


Large Product Backlog


19

Games

Navigation

Pac man

Sudoku

Maps

Cameras

Play game

Theme Epic Feature

Tracking

results

Create

game

Ord

er

AG

ILE

Three C – Key Elements of a User Story

Card The card reminds to describe the user story with just a few

sentences that captures the crucial points: who, what and

why.

Conversation A user story is just the beginning – it is not meant to be a

full-blown traditional requirement description.

A user story is a promise for further discussion between the

customer, the team(s) and the stakeholders. The

discussion will provide the necessary details.

Confirmation Acceptance criteria and tests define the conditions of

satisfaction. They help evaluate whether the developed

user story meets the user needs, expectations and

specifications.


20

AG

ILE

Decomposition


21

Games Pac man

Create Pacmans

Theme Epic Feature/Story

Create enemies

Create walls

Move Pacman

Move enemies

Compose music

1. Create

walls

2. Create

Pacmans

Story Tasks

walls UI

programming

Database

Graphical design

Game engine

User

documentation

Grid design

Floors UI

programming

Create menus

Program

documentation

SC

RU

M+

Handle garbage

Start counting

Show explosions

Change points

Handle PR

Add points

Acceptance testing

Performance

testing

Product backlog Sprint backlog

To do Doing Done

Move in

sprint

planning

Sudoku

From Project Manager (PM)

to Product Owner (PO)

22


What Changes


23

The old way - Taylorism


24

Planning A

modelForeign

sales

Domestic

sales

Invoicing,

accounting

Management

T model

Inventory

10.5.2017


Gradual Product Funding


25

Concept

Feasibility

Internal release

Alfa release

Beta release

Production release

Upgrade

Product funding

Major release

No projects plans – create value instead of

realizing a plan

Openness – keep your work visible

• Complex systems are

driven by feedback

• Product development ,

design, …

• Transparency of the result

and the way of working

• Inspect and adapt


26

Measure

AdaptScrum is based on

empirical process

control

You are not a manager, no authority

• Respect people near you

• Colleague, customer, sub contractor

• They all need your appreciation and respect

• Command and control does not work

• You can’t buy commitment to a common goal


27

Double the results in half of the time -

Agile vs Waterfall


28

Traditional project: Avoid unnecessary

work with comprehensive planning

Agile: Improve learning by early and

frequent feedback

Requirements

Bidding

Design

Implementation

Testing

Architecture

R

D

I

T

R

D

I

T

R

D

I

T

Vision

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Error corrections,

additions, change requests

AG

ILE

Work In Progress: Limit work to capacity

• Decrease batch size


29

• To get things done

• Pressure does not help

• Incentives do not help

LE

AN

What Remains


30

10.5.2017


Manage the Coordination chaos


31

Product

Backlog

Project 1

Customer 1

Project 2

Customer 1

Project 3

Customer 2

Project 4

Customer 3

Project 5

Customer 4

Work pair ( in some cases and kind of)

• Customer’s project manager Vendors Project manager


32

• Product Owner ScrumMaster

Scrum is a light framework for developing

and sustaining complex products

• Does not contain:• Recruiting

• HR

• Contractors, legal

• Invoicing

• Managing cash flow, budgeting

• Management practices

• Marketing, sales, sales support

• It can be used here but quite often it is not the case


33

Difference between Product

Owner and (traditional) Product

Manager

34


No Baseline

• Optimizes value

• Realizing a plan not so important

• Beyond budgeting


35

Collaboration with the development team

• Traditional product managers outsource the development • Disconnects the feedback loop from users to development

• Developers does not understand the where the product is used


36

10.5.2017


Agile Leadership

• Meaning of work has changed

• Maslow’s first levels are

satisfied

• Physiological needs

• Safety needs

• Belonging needs

• Esteem

• Self-actualization

• Now

• Challenges

• Purpose

• Respect


37

Monitoring progress

• Tangible results• Working software

• Daily builds

• Review meetings

• Information radiates• Reports are not printed and sent to people

• Long ineffective status meetings are depreciated• Everyone can see the status when needed

• User experience with easy, often manual, tools• Kanban tables are operative systems not reporting systems

• Better quality of the data

• Users do not resist the use of systems

• Avoids double-entering data to separate systems

• Avoids waste in specific reports (that no-one reads)

• Scaling requires coordination• Systems help by visualization of the work flow

• Handovers are visible (not hidden deep in the databases)


38

Information is

available

Fixed price, fixed date or

latest date, maximum cost

Fixed price possible but not

recommended

• Refined product backlog typical

• Fast change management to

add/swap requirements

Contract provisions:

1. Any requirement that hasn’t already been worked on can be swapped out for another of equal value

2. Order of requirements can be changed

3. Customer may request additional releases at any time at prevailing time and material fees

4. Customer may terminate contract early if value has been satisfied for 20% of remaining unbilled contract value

39


AG

ILE

Budgeted costBonus if the budget is

undercut

Discount if the budget

is exceeded.

Changes the incentives of the customer and the vendor

Amount of features in

an epic is unknown

Budget contract

Product Owner as a

representative of Customers


40

Product Owner as a representative of

Customers

• Internal development

• Process owner of the business process that will use the product

• Outsourced development

• Customer’s business person or

• Vendor’s product owner who has authority to do the business

decisions

• Vendor offering a commercial off-the-self product

• Product manager with connections to sales and marketing

• No project managers or agile product managers in Scrum

• Delegation of responsibilities to them introduces risk, dysfunction

and waste

• Scrum addresses their prior responsibilities thru Scrum roles


41

SC

RU

M+ Product Owner as a representative of

Customers End users

• Product vision

• Quality attributes

• Product backlog

• Users and scenarios

• Stories

• Examples

• Paper prototypes

• Automated tests

• Computer prototypes

• Programming


42

Breadth

Depth

Growing software using feedback

10.5.2017


Product Owner as a Representative of Other

Stakeholders

• Other silos

• Customer’s customers

• Legal

• Community

• Communication


43

Communication between teams


44

DD

DD

D

D

DPO SM

D DPO SM

Product owner

teams

synchronize

product

backlogs

and releases

Minimize

Scrum of

Scrums level

DD

DD

D

D

DPO SM

SC

RU

M+

Support that Product Owner

Requires from Own

Organization

45


Growth mindset

• https://www.mindsetworks.com/science/


46

Organization’s culture

• Organizational support• executive sponsor

• Old processes and tools

• Empowered PO

• Contractual way of working

• Communication• Trust

• Technical problems

• Cultural problems

• Inability to scale• Too much specialization?

• Wild “requirements”• Eternal iteration?

• Continuous improvement• Is it allowed to fail?


47

Focus on

processes and tools

OT

HE

R

Technical capability

• To avoid rework, use

• Automated testing

• Refactoring

• Continuous integration

• Architecture

• Vision

• Organizational match

• Conway’s law

• Cost of change small

• Life, business criticality

• No technical debt

• Reversible decisions


48

OT

HE

R

10.5.2017


Working as Product Owner with

or within traditional

organizations

49


Traditional stranglehold

• Yearly budgeting

• Financial incentives

• Personal responsibility

• Reporting, bureaucracy

• Execrated planning

• Silos


50

Skunkworks, SWAT teams

• Disconnect

• Independence


51

Agile with waterfall milestones

• This is not Scrum but it is happening in real life

• Fixed price, schedule based on requirements

• Development Sprints might be official

• Organizations love detailed process guides

• Stabilization Sprints are not planned, but actually happen

• Consequences?

• Why is this bad?


52

Requirements Development Testing Transition

Summary


53

Conclusions

• Change is more gradual than what theory tells

• Global drivers in the world of work

• Poverty disappearing – prosperous mankind

• Meaning of work for the people is changing

• New threats & surprises

• More software – scarcity of programmers may continue


54

From Project Manager to Product Owner 6 From...

Documents

Transcript of From Project Manager to Product Owner 6 From...