Ciklum Seminar Zurich June 25, 2013 Dmitry Kanevksy (Ciklum)

Post on 26-Jun-2015

184 views 1 download

Tags:

description

Why is the „Product Owner” role so important in agile development and particularly in nearshore team settings? What can and will go wrong, if roles, methods, and tools for proper requirements gathering, documentation and prioritization are missing? This session gives a brief overview of how an ideal setup looks like: Integrate your software development teams into the requirements development process, share business knowledge and responsibility for product delivery!

Transcript of Ciklum Seminar Zurich June 25, 2013 Dmitry Kanevksy (Ciklum)

Agile Product Management

Strategic considerations and successful patterns for nearshore

software development

Dima Kanevsky, Consulting Lead

We are going to talk about

• Strategic considerations of Agile Product development

• Product Owners role and key fallacies in a nearshore setup

• Four unsuccessful and five successful patterns in Agile Product Development which let product managers succeed with nearshore teams

NOT going too deep into the ‘right’ practices

We are too much overcomplicating software development

individuals Organizations

Complex ecosystems

Risk

Return

Problem is unknown

and solution is unknown

Problem is known,

solution is known

Problem – solution fit

Solution is known,

problem is not known

Effective

Efficient

Product success

Manager’s wet dreams

‘…aim at commanding positions within a given market segment’ - Davidow, Marketing High Technology

Monopoly or..

Lean principles to the rescue

• Mitigate risk

• Minimize inventory

• Eliminate waste

‘…68% of the features are used either once or never’, Gartner, 2008

How to produce value?

The number one the most critical for software success and return-on-investment is effective

user adoption - Sand Hill Group and Neochange, 2011

Three biggest challenges of a product owner in a nearshore setup

• creating a sense of ownership within the team

• sharing business context to engage the team in decision making

• inefficient and costly communication

What can and will go wrong

#1 PO is a bad representation of a user

# 2 too much focus on a product vision

‘Coming up with 15 or 20 product features proves to be easy. It's figuring out which 3 or 4 would cause someone to buy the product that is difficult’, - Hillsmith.

# 3 too much design documentation

Right approach

# 4 too much communication

The less people talk the better

How an ideal setup looks like

#1 collaborative requirements gathering and

validation

#2 inject business context holder in the team

#3 Opt out for a fully distributed scrum

#4 Bring the team together

#5 Treat people as adults