agile bi congres - bi-podium€¦ · management; sector experience in finance, telco and supply...
TRANSCRIPT
Agile BI Congres
Product Owner, the impossible job?
Utrecht | December 13th
Axel Suetens
Axel Suetens
Proven track record in Business Intelligence consultancy and Project
Management;
Sector experience in Finance, Telco and Supply Chain Management;
Held several delivery management positions in ICT industry top companies;
Program and project management (setup BI Competence Centers).
Introduction
Introduction
Who is in the
room?
AGENDA
Agile in a nutshell
Agile process
The Product Owner
PO Flavors
The project manager
The right PO
PO the impossible job?
Conclusion
Questions & Answers
Agile in a nutshell
Agile in a nutshell
AGILE MANIFESTO
Iterative
Agile is iterative in nature in that it assumes that we do not know
everything at the beginning of a project, and that we will learn as we
explore and refine our understanding together.
Agile is incremental in nature in that it aims to deliver value to the business
on a regular basis, in small increments. And in doing so it allows us to
reflect on our work, learn from our shared experience, and modify our
priorities to accommodate changes in our environment.
Incremental
Agile teams work in a highly collaborative way with a focus on collective
ownership and collective responsibility. Collaborative
Agile teams understand that by being honest about our current state, past
experiences, and future expectations, we can make better decisions and are
more likely to achieve the desired project outcome.
Transparent
Agile in a nutshell
Guiding principles
Some of my observations
Many companies are starting to implement Scrum in one way or another but
a lot of them seem to forget that Agile is about delivering “VALUE”!
Scrum is considered something for the technical people and project managers
and nothing for the business.
“We don’t need to do <blank>, we’re doing Scrum”.
Agile in a nutshell
Agile in a nutshell
“Working software is the primary
measure of success!”
Project Plans
Test Plans
Requirements Docs
Architectural Diagrams
Analysis Models
Security Reports
Deployment Plans
…
… are of no value to the customer!
Agile process
Agile process
Agile process
WHAT
WHEN
HOW +
DOING
FRAMEWORK
The Product Owner
A Product Owner should own the product on behalf of the company.
You can think of the product owner as the individual who champions the product,
who facilitates the product decisions, and who has the final say about the product,
for instance, if feedback is integrated into the product backlog, or when which
features are released.
“Starting teams often
confuse the two!”
≠
The Product Owner
Manage profitability and ROI
o Baseline target ROI
o Prioritize Product Backlog
o Measure business value
Call for releases
Guides product development
Product Owner
The Product Owner
The Proxy PO
Technical debt
Innovation
Infrastructure
Architecture
Sales
Customer
support
Marketing
Competition
Proxy
PO
Architectural
Feature A
Technical debt
Feature B
Product
Backlog
Tech
no
log
y Bu
sine
ss
• Balance needs
• Bring goals, not solutions
• Not a manager
• The big picture / strategy
• Good quality product backlog
• Acceptance
• Schedule Feature C
Th
e P
rod
uct
Th
e C
usto
me
r
PO Flavors
PO flavors
Product Owner flavors I have come across:
Release
Manager
Information
analystUnit Manager
Product
ManagerProject Manager
The project manager
Where did the PM role go?
Group discussion
The right PO
The right PO
The big word here is Business Case. The business case describes the benefits of the
deliverables of the project. Perhaps we should call him ‘Business Case Owner’?.
The reverse is also true, if your Product Owner isn’t accountable for realizing the Business
Case, he is not your real Product Owner. But if you can transfer accountability to the product
owner, what kind of competences does the Product Owner need to posses to perform
Business Case driven steering?
Business Case Value
Financial
Some domain knowledge
Time (availability)
PO the impossible job?
PO the impossible job?
IT and the business have different levels of interest for transitioning to Scrum.
Technology is more interested in Scrum than the business. Eliminating all other certification combinations¹, there are:
121,100 Certified ScrumMasters
14,162 Certified Product Owners
There is about one PO class for every five SM classes
Gap between the business (typically driven by financials ) and IT with Scrum involvement. The business often doesn’t understand how Scrum (when done right) can deliver value.
1 Data provided by Scrum Alliance May 2011
PO the impossible job?
Reality check: a fundamental problem with the Scrum Product Owner role outside of
product development companies: good Product Owners are too rare.
Scrum selling argument that it is a lightweight process. It provides a helpful structure, mind
set and best practices for a single development team. However, it does not for instance help
you on how to create user stories, manage architecture and scale over multiple teams.
In a larger organization, we need user stories, architecture and multiple teams. So, rather
than switching to a heavyweight process that covers all of these, we need to extend Scrum
with additional processes and best practices for the challenges at hand.
Story
MappingStory refinement
PO craftsmanship: Story mapping
Start with understanding the process
flow and the needs.
Create Epics and Stories and map these
to the process flow.
Break sprintable Stories into Tasks.
Level 1 – Minimum viable product
Level 2 – Next release
Level 3 – Next release
Level .. – Next release
Without this no value is created what so ever!
Day 1: …
Day 2: …
Day 3: …
PO craftsmanship: Story mapping
Start with understanding the process
flow and the needs.
Create Epics and Stories and map these
to the process flow.
Break sprintable Stories into Tasks.
Level 1 – Minimum viable product
Level 2 – Next release
Level 3 – Next release
Level .. – Next release
Without this no value is created what so ever!
Day 1: …
Day 2: …
Day 3: …
RISK VALUE
Story CStory CStory CStory C
DEMAND
CREATION
PRODUCT
CREATION
PLAN
MERCHANDISE SELL DELIVER INVOICE
Story BStory BStory BStory B
Story AStory AStory AStory A Story DStory DStory DStory DEEEE
Story FStory FStory FStory F Story JStory JStory JStory J Story L Story L Story L Story L Story M Story M Story M Story M
GGGGHHHH
IIII
KKKK
Task 1Task 1Task 1Task 1
Task ..Task ..Task ..Task ..
Task ..Task ..Task ..Task ..
Process Flow
Product Backlog
PO craftsmanship: Story mapping
Sprint
Agile BI
From Standard plug & play
reports to Self Service
Common Agile Scrum pitfalls
No support from business leadership
PO's are not available enough for strategy and planning meetings
PO's are too busy for training and education (uninformed)
PO's have multiple hats on
PO's are not the right person
PO's are not empowered
Lack of trust between PO and the Team
Backlogs are not ready
No prioritization mechanism
Delivery capacity and allocation is not known
…. the last 3 bullet points imply the need for a Framework.
Demand Management framework
“Make everything as simple as possible, but not simpler.”
Conclusion
I have explained when the Product Owner role didn’t work as it should have and also what
a good Product Owner should be concerned with to maximize the project effectiveness by
focusing on the business value of it’s features.
I conclude that the role is hard to fill in the right way which makes Scrum hard to kick-start
and makes the process feel either broken or too heavy.
Food for thought
Perhaps we need a special “non-product-development” version of Scrum? Or redefine the
Product Owner role to fit large organizations so that we can start the process immediately
and then gradually move towards the ultimate vision of true collaboration between the
business and development.
Conclusion
Questions & Answers
