Agile project management day 2

1

Welcome!

Agil Projektledning Dag 2

Agenda today

• Scrum and the Scrum team

• The project managers role towards the Scrum team.

• Scaling Agile

• Multiple teams and System Anatomy

• User stories

• Estimation and velocity

• Agile contracts

• Empower teams – managing delegation

2Agil Projektledning Dag 2

3

How do you manage

requirements?

Who owns the

requirement?


So what is agile?

• Agile Software Development is defined by the Agile

Manifesto.

• The base for Agile is Lean, Knowledge theory and

complexity theory.

• Agile is designed to manage uncertainty and changes.

• Core in agile is self-organizing and empowered teams,

cadence, interactions, transparency and visualization



Artifacts


Scrum – sprint releases

• Roles– Product Owner

– Scrum Master

– Team

• Artifacts– Product Backlog

– Sprint Backlog

– Product Increment

• Activities– Daily sprint

– Sprint review (Demo)

– Sprint retrospective


Kanban – continous releases (e.g. maintenance)

• Visualize the workflow

• Limit work in progress

(WIP)

• Measure lead time


9

Scrum – measure by

velocity

Kanban – measure by

mean lead time


Definition of project management

• Project management is the discipline of planning,

organizing, motivating, and controlling resources to

achieve specific goals. … The temporary nature of

projects stands in contrast with business as usual.


Source: Wikipedia

Projects in a line organization


Projects in an agile organization


Projekt

SCRUM Roles


When it comes to Agile Project Management it is worth

noting that most agile processes - and Scrum in particular -

do not include a role called “project manager”. Without a

specific person tasked with performing all managing duties,

those responsibilities are distributed among the other roles

on the project, namely the team, the ScrumMaster, and the

Product Owner.

Mike Cohn

Agil Projektledning Dag 2 14

Product Owner

The product owner has responsibility for deciding what work will be done. This is the single individual who is responsible for bringing forward the most valuable product possible by the desired date. The product owner does this by managing the flow of work to the team, selecting and refining items from the product backlog. The product owner maintains the product backlog and ensures that everyone knows what is on it and what the priorities are. The product owner may be supported by other individuals but must be a single person

(SCRUM alliance)


The SCRUM-master

The Scrum Master is responsible for ensuring Scrum is understood

and enacted. Scrum Masters do this by ensuring that the Scrum Team

adheres to Scrum theory, practices, and rules. The Scrum Master is a

servant-leader for the Scrum Team.

The Scrum Master helps those outside the Scrum Team understand

which of their interactions with the Scrum Team are helpful and which

aren’t. The Scrum Master helps everyone change these interactions

to maximize the value created by the Scrum Team.

(The SCRUM Guide, Sutherland/Schwaber)


Four scenaries

17

Projekt

SCRUM-team

SCRUM-team

Projekt

SCRUM-team

Projekt


SCRUM

SCRUM

SCRUM

SCRUM

SCRUM

SCRUM

Projekt


Development/maintainance team

Projekt

What function shall the Project Manager have towards the Srum team?

Agil Projektledning Dag 2 19

Scenario Scrum Master Product Owner Customer Stakeholder

1

2

3

4

Projekt

SCRUM-team

SCRUM-team

Projekt

SCRUM-team

Projekt

SCRUM

SCRUM

SCRUM

SCRUM

SCRUM

SCRUM

Projekt

1 2 3 4

Scaling Agile

Multiple teams

21

22

Scaled Scrum

PSI

• --------• --------• --------• --------• --------• --------

Increment

backlog

Build

release

candidate,

Demo &

Release

review

meeting

Joint teams

retrospectiv

e meetingHardening

period 3

weeks

RC

PSIPSIPSI PSI

PPB 1

(Project

Portfoli

o

Board) PPB 2

Sprint

plannin

g

meeting

Daily Scrum

Weekly Scrum of ScrumsYear 1 Year 2

Inc 1 Inc 2 Inc 3 Inc 4 Inc 5

Pre-

planning

meeting

Release

planning

meeting

PSI

Fiel

d

test

Software

integration

Sprint

retrospective

One-pager release report

• Aggregated increment

burndown

• Status &progress each Epic

• Improvements to be done

• Impediments

• --------• --------• --------• --------• --------• --------

NFI - Project Management in Agile

Organizations @ Tele2

23

24

Spotify

25NFI - Project Management in Agile


https://dl.dropboxusercontent.com/u/1018

963/Articles/SpotifyScaling.pdf

Who steers what?



Squad responsibilities



Dependencies between Squads



29

Release preparation &

verification

R n.1

Merge

Corrections

TG0 TG5

PD2Release content

decided

Which features to include in a

release, both developed, under

development and not yet started.

21 272019181716 ...12 .... 1511

GODecision

Verified “up and running” system version:

Feature

implementation

decision

R n.1

R n.2

Development

“Go” per

Decoupling of release projects

Desig

nR

ele

ase

Integration & Automated Regression Test (with load)

Streamlined Development



30

Product Owner Hierarchy or team?



DeLaval

32

33

Program and projects at DeLaval

Leveransprojekt

Affärsområden

Mjukvaruleverabel

Marknadsrelease

Support

Krav-

arbete

Program

NFI - Project Management in

Agile Organizations @ Tele2

De LavalContinuous Delivery of Multiple Projects

Where one release is interdependent of one or more teams

Where one release is directed at one or more projects

Inc n + 1 Inc n + 2 Inc n + 3 Inc n + 4

Project A

System Architecture

Quality Releases

Project B

Project C

Project D

System Releases



34

Portfolio Level



Program Level



http://scaledagileframework.com/

Team Level




Scaled Agile Framework™ Big Picture



38


System Anatomy to manage multiple teams



Visual Planning in the Fuel Reduction Team

2013-10-0240

GDP banner with major verification activities

Backlognext XX weeks

week

Fuel consumption

FC reduction ideas

Anatomy

Increment Plan

B20





ATM Functions

43

Cash withdrawal

Account balance

User interface

Authentication

Communication ATM - Bank

Handling of bills

ATM Functions

44

Cash withdrawal

Account balance

User interface

Authentication


Handling of bills

ATM Anatomy

45

Cash withdrawal

Account balance

User interfaceAuthentication


Eject bills

46

User Stories



Agile requirement hierarchy,Dean Leffingwell



Theme

Epic

Story

Feature

Story

Epic

Task Task

Epic

Feature

Mike Cohn



http://www.mountaingoatsoftware.com/presentatio

ns/introduction-to-user-stories

http://www.mountaingoatsoftware.com/presentations/introduction-to-user-stories












User stories are the primary object that

carry the customer’s requirements

through the value stream – from needs

analyses through code and

implementation.

User Story Format

A <role> can <action>

or

As a <role>

I want to <action>

So that <value>

A company can pay for a

subscription with a credit

card.

As a consumer I can see my

daily energy usage so that I

can lower my energy costs.



Card, Conversation, Confirmation



Why User Stories?

• User stories emphasize verbal communication.

• User stories are comprehensible by everyone.

• User stories are the right size for planning.

• User stories work for iterative development.

• User stories encourage deferring detail.

• User stories support opportunistic design.

• User stories encourage participatory design.

• User stories build up tacit knowledge.



User Stories should be:

• A function – not an implementation

• Independent– Not linked to other stories.

• Negotiable– A base for discussion.

• Valuable– For an identified user/customer/stakeholder.

• Possible to estimate– The developers must understand what is needed.

• Right size

• Verifiable



Everything is not user stories

• Descriptions of user interface (UI)

• Descriptions of (API)

• ..



Constraints & non-functional requirements



Source: www.agileproductdesign.com

56

Define constraints on cards.

• Do not make it hard to internationalize the software if

needed later.

• The new system must use our existing order database.

• The software must run on all versions of Windows.

• The system must achieve uptime of 99.999%.

• The system must manage 200 transactions / second.



Dean Leffingwells Model



Use Case /User Stories

• Use cases are often permanent artifacts that continue to

exist as long as the product is under active development

or maintenance.

• Stories, on the other hand, are not intended to outlive the

iteration in which they are added to the software. While it

is possible to archive story cards, many teams simply rip

them up.



Personas



60

Virtual customer visits



61



Estimating

requirements

Story Points and velocity



• Story Point can be equal to Ideal

Development Day

• Velocity = (average) storypoints per sprint



Agile contracts

An Agile System



Your vendors

Your customers

Your company

The Agile System

Basics in an agile agreement

• Delivery in frequent releases.

• Demo of progress per release.

• The customer re-prioritize the backlog before each sprint.

• The project can be started before a complete

specification is ready.

• Requirements (backlog) may change.

• Time and cost fixed, not scope.

67Agila kontrakt, Knowit 2013.05.29

Would you use an agile agreement?


Agile – from customer perpective

Plus

• Flexibility – adaptive to

changes in scope

• Time to market

• Exploratory approach.

• Matches internal agile way

of working

• Innovative vendor

feedback

Minus

• No warranty for delivery of

scope within time and

cost.

• Requires an active buyer.

• Requires knowledge on

agile.


Agile – from vendor perspective

Plus

• Minimized risk

• Encourages innovation

• Closer customer relation

Minus

• Value bases pricing will

not work.


Risks with agile contracts

• Price and time control!

– To much flexibility

– Unclear constraints


Agreement models

• Fixed price

• T&M

• T&M with shared risk

• Almegas “Agila standardavtal”

• Vested



74

1. Focus on Outcomes, Not Transactions

2. Focus on the What, Not the How

3. Agree on Clearly Defined and Measurable

Outcomes

4. Optimize Pricing Model Incentives

5. Governance Structure Should Provide Insight,

not Merely Oversight

Agila kontrakt, Knowit 2013.05.29

Fixed Price or T&M

Passive

buyerActive

buyer

Fixed Scope

Open Scope

FP FP

T&M

T&M

Agilt

Vested


How to select vendor

• Trust

• Cultural fit

• Team competence

• Team productivity

• Price per hour


Empower Teams

© Jurgen Appelo version 1.05 management30.com

Management 3.0

78

View #2: Empower Teams

Teams can self-organize, and this requires empowerment,

authorization, and trust from management.

79

self-organizing teamsAgile software development works because of

80

self-organization is often complex, not chaotic

Sometimes it needs a little management

management self-organization

81

Delegation“Delegation (or deputation) is the assignment of authority

and responsibility to another person (normally from a

manager to a subordinate) to carry out specific activities.”

http://en.wikipedia.org/wiki/Delegation

82

http://en.wikipedia.org/wiki/Self-organization

http://en.wikipedia.org/wiki/Delegation

Situational

Leadership

http://en.wikipedia.org/wiki/Situational_leadership_theory

Four different “leadership

styles”

1. Telling

2. Selling

3. Participating

4. Delegation

Work your way to level 4

83

http://en.wikipedia.org/wiki/Situational_leadership_theory

Situational

LeadershipHowever…

It might be good to distinguish

between informing people

(push your opinion) vs.

consulting them (pull their

opinions)

84

1. Tell: make decision as the manager

2. Sell: convince people about decision

3. Consult: get input from team before decision

4. Agree: make decision together with team

5. Advise: influence decision made by the team

6. Inquire: ask feedback after decision by team

7. Delegate: no influence, let team work it out

The Seven Levels of Authority

85

flow from left to right 86

controlled by the

manager

Authority boards are

87

1. Find Delegation Poker Cards, and Delegation Poker

Stories

2. One person picks a story and reads it out loud

OR tell a story from personal experience

3. Everyone choose (privately) one of the 7 cards

4. After everyone has decided, show all cards

5. Everyone earns points except the highest minority

(see examples…)

Game: Delegation Poker

88

5. Keep track of the points people earned (optional)

6. Let both highest and lowest motivate their choices

7. Play it again for the same topic (optional)

30 minutes

Game: Delegation Poker

89

Technology

Agile project management day 2