Agile Project Management Training

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
SCR
UM
SCR
UM
SCR
UM
SCR
UM
SCR
UM
SCR
UM
Projekt
1 2 3 4

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 Scrums
Year 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

Spotify
25NFI - Project Management in Agile
https://dl.dropboxusercontent.com/u/1018
963/Articles/SpotifyScaling.pdf

Who steers what?

Squad responsibilities

Dependencies between Squads

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
GO
Decision
Verified “up and running” system version:
Feature
implementation
decision
R n.1
R n.2
Development
“Go” per
Decoupling of release projects
DesignRelease
Integration & Automated Regression Test (with load)
Streamlined Development
30

Product Owner Hierarchy or team?

33
Program and projects at DeLaval
Leveransprojekt
Affärsområden
Mjukvaruleverabel
Marknadsrelease
Support
Krav-
arbete
Program
NFI - Project Management in
Agile Organizations @ Tele2

De Laval
Continuous 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

Team Level

Scaled Agile Framework™ Big Picture
38

System Anatomy to manage multiple
teams

Visual Planning in the Fuel Reduction Team
2013-10-02
40
GDP banner with major verification activities
Backlog
next 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
Communication
ATM - Bank
Handling of bills

ATM Anatomy
45
Cash withdrawal
Account balance
User interfaceAuthentication
Communication
ATM - Bank
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

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

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
buyer
Active
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

View #2: Empower Teams
Teams can self-organize, and this requires empowerment,
authorization, and trust from management.
79

self-organizing teams
Agile 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

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

Situational
Leadership
However…
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

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

Agile Project Management Training

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Agile Project Management Training

Semelhante a Agile Project Management Training (20)

Mais de Knowit_TM

Mais de Knowit_TM (20)

Último

Último (20)

Agile Project Management Training

Notas do Editor