Technical Product Owner

[rajma...@gmail.com]

Is the term "Technical Product Owner" new i only heard about Product Owner

This means that Product Owner with Technical knowledge ? I do see some PO not having much idea on technical knowledge mostly dominated by Team.

This new tern is same like Scrum Master with technical knowledge and PO with Technical knowledge.

Please help me with understand this and how many of you are PO with Technical knowledge and how this helps Scrum Team  ? 

--

Thank you and regards,
Rajmahendra (Raj)
Founder / Lead JUG Chennai/Hyderabad

NetBeans Dream Team Member

http://www.twitter.com/rajonjava
----------------------------------------------------------------------------------------------
"DREAM is not what you see in sleep;
is the thing which does not let you sleep" - APJ Abdul Kalam
Do the difficult things while they are easy and do the great things while they are small.
A journey of a thousand miles must begin with a single step. - Lao Tzu

[Ron Jeffries]

There is no Scrum Role called “Technical Product Owner”. If a Product Owner were notably technically competent, I might say “technically competent Product Owner”. I would not capitalize the first two words lest they be taken as a name.

On Apr 10, 2015, at 12:19 PM, rajma...@gmail.com wrote:

Is the term "Technical Product Owner" new i only heard about Product Owner

Ron Jeffries

ronjeffries.com

Don't ignore your dreams; don't work too much; say what you think; cultivate friendships; be happy. -- Paul Graham

[Ram Srinivasan]

Technical product owner exists only in FAKE Scrum :)

--
my primitive mobile device likes to mess with spelling and grammar

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[Alan Dayley]

In some large companies there is a need, real or imagined, for someone to guide the product from a technical point of view. Often in these cases there will be two people in the Product Owner role. One would be the "Technical Product Owner," who knows architecture, system capabilities and such. The other person is often titled a "Business Product Owner," who understands the needs of the users and the business vision for the product. These two are supposed to work as a tight pair and provide a single priority and product need view to the rest of the team. Some companies even call this situation "Two-in-a-box Product Owner" or something like that.

At best it is a bandaid and should be a temporary bridge to something better, something more like Scrum, if the company is claiming to follow Scrum. Often the idea continues dysfunctions and organizational impediments.

Organizational change to get to true product ownership in these situations often involves politics and hard choices. The existence of the "Technical Product Owner" in an organization is an indicator of various conversations to be had and improvements to be made.

Alan

[rajma...@gmail.com]

I got all your points and yes there is only 3 roles.  

Let me phrase the question in this way.

In some more technology involved project PO some time not sure wow to handle Team in technical talk he may know know what is XML, JSON, etc.. (just a example) so team or PO have to work hard in understanding things. 

IF PO who have background of Technology... is there any advantage or disadvantage you find  ? 

[Ron Jeffries]

Raj,

On Apr 10, 2015, at 10:54 PM, rajma...@gmail.com wrote:

IF PO who have background of Technology... is there any advantage or disadvantage you find  ? 

A PO with technical knowledge is more likely to tell the team HOW to do things rather than WHAT to do. This can hold back team creativity and results in too much power in the PO’s hands.

Ron Jeffries

ronjeffries.com

I try to Zen through it and keep my voice very mellow and low.

Inside I am screaming and have a machine gun.

Yin and Yang I figure.

  -- Tom Jeffries

[Alan Dayley]

The Product Owner is to focus on...

... what the user needs to accomplish

... what the market wants from the product

... how to get to value sooner by prioritizing features and capabilities

... working with the stakeholders or customers who are paying for the development

... guiding the experience of product use, often with the help of UX and other technical people

... knowing when to stop working on the product

... discovering new ways that the product can bring value

The Product Owner defines "What?" the product should do. The Developer Team members self-organize in answering "How?" the product will fulfill those capabilities. In short, the Product Owner is supposed to be focusing on defining a highly valuable product. Product Owners with a background in technology are often not good at the above important things or get too involved in technology discussions instead of doing the above important things. To the Product Owner, answering "How?" is a technology discussion secondary to the "What?" question.

A Product Owner with a technical background *can* be beneficial, as long as the user and product focus is not neglected. The better Product Owners I have seen have not had a technical background or purposefully stay away from technical discussions. They had too much to do in finding the answers to the "What?" questions.

Alan

[Dan Rawsthorne]

Since the PO is a member of the scrum team, and can work as part of the Development Team, it is often advantageous for the PO to be technical. This is especially true if the PO needs to balance technical chores (such as cleanup activities, team training, etc) along with the product-producing work. Remember that the PO is supposed to optimize the value of the team's work, as well as optimize the value of the product. It's a complicated thing and product ownership is done in many different ways... don't expect a recipe.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Michael James]

The relevant principle is here: http://agilemanifesto.org/principles.html
"The best architectures, requirements, and designs emerge from self-organizing teams."

Agile is uncomfortable for organizations that have legacy management roles with positional authority, so it's a bit too easy to sell them compromised approaches that feel safe.

--mj
(Michael)

[John Miller]

I agree the PO is complex and there is not a recipe. But, the PO roles has pretty clear boundaries that contains that complexity. 

I am not seeing why a PO would optimize the value of the Team's work & manage their time. That is up to the team to do. The team can decide if they need training and do so if needed without the PO's deciding. The PO is not their manager. The PO offers what she thinks are the highest "product" backlog items at any given time. She does not offer "team" development items. 

Am I hearing you correctly, Dan?

Not saying this is bad. As a Director, I was the PO for a while and used Scrum Sprints for everything, from management, team development, training, organizational  functions, and product. It was amazing the simplicity and clarity it brought. But, when I mixed in non-product goals, I was not operating as a PO, I was operating as a Director that used (benevolently highjacked perhaps) Scrum. 

Thank You,

John Miller

Agile Classrooms

Clarity.Choice.Collaboration

AgileClassrooms.com

[John Miller]

A TPO is a Manager in Scrum's clothing.

A translative use of Scrum to continue micromanage the team.

We could create a XPO for any team responsibility in order to kill self-organization at any level. A Quality PO, a Infrastructure PO, a Security PO, an Architecture PO....

But it is all cool. It has the word PO in it, so, life is all Scrummy.

Hmmm, perhaps a new scaled framework is about to be born.

Thank You,
John Miller
Agile Classrooms
Clarity.Choice.Collaboration
AgileClassrooms.com

[George Dinwiddie]

Raj,

On 4/10/15 10:54 PM, rajma...@gmail.com wrote:
>
> Let me phrase the question in this way.
>
> In some more technology involved project PO some time not sure wow to
> handle Team in technical talk he may know know what is XML, JSON, etc..
> (just a example) so team or PO have to work hard in understanding things.

I have met POs who didn't really know their product. This can happen
with technology products or other products, believe it or not. Often
these POs are merely proxies for those who really understand the
product. Occasionally there is no one person who really understands it.

That said, it's not terribly important that the PO understand the
implementation of the product. The details of XML and JSON are
unimportant unless these interfaces are important to customers, and are
therefore business concerns.

>
> IF PO who have background of Technology... is there any advantage or
> disadvantage you find ?

I've witnessed a big disadvantage when the PO formerly played a
technical role and wanted to continue to make technical decisions. This
not only created dis-empowerment issues with the development team, but
distracted the PO from the business concerns. In some cases, the PO was
not as technically astute as they thought they were, and would discount
the warnings of the developers.

A non-technical PO can ask the developers to explain technical issues in
a way that they can understand. I've seen this work very well.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[John Miller]

I take the view Ideo does in product design for a PO. It is about the process of discovering what the needs are. Ideo rarely has pre-existing product knowledge yet designs amazing products because of their human centered design process.

I would rather a PO know next to nothing at first about the product but be relentless in learning about the people and the problems they are designing the product for.

But, that is just me. Not saying this is the definition of how a PO works. It does highlight that a technical PO is far from necessary.

Thank You,
John Miller
Agile Classrooms
Clarity.Choice.Collaboration
AgileClassrooms.com

[Leonhard Grugl]

In my opinion, it's not so much a question whether it is better to have a PO with technical knowledge or one without, but rather how to make the best of each situation. So far, I have only worked with PO's who had technical knowledge, so I don't have any actual experience when that is not the case.

In our team, the technical background of the PO has the advantage, that he generally doesn't question developer's estimations and easier understands how dependencies between stories (featues) need to be treated carefully. On the other hand, there is the little problem, that he sometimes falsely assumes technical complications and therefore splits user stories inappropriately. Im unsure if you understand what I mean with that, but however, this is an actual issue emerging from the PO being somewhat technically competent, but not being able to be 100% informed about the design of the application. This is due to him spending almast all of his day doing the intended PO-work and therefore not having much capacity to follow the technical details.

In means of roles, the role responsible for the technical realisation of the product would be a software achitect, I think. But that role being held by a single person dictating design does not comply with the idea of an emerging design.

So, as a conclusion, I think it might be a good idea to have a PO with a technical background or knowledge, as long as they use that only for a better understanding of problems at a certain level of detail, but not to make decisions on how to do something. In general, I think it's a bad idea to assign a single person responsible for the design, be it a Technical Product Owner, Technical Scrum Master, Architect, or whatsoever. Instead, while I do understand that there will always be experts for certain domains, I'm sure that the approach of letting the whole team work it out together - in other words let the design emerge from collaboration - is the favourable approach.

Leonhard

[John Miller]

>
> In means of roles, the role responsible for the technical realisation of the product would be a software achitect, I think. But that role being held by a single person dictating design does not comply with the idea of an emerging design.

Nor is it, in anyway, Scrum

[Dan Rawsthorne]

Well, the PO optimizing the value of the team's work is a direct quote from the scrum guide. She is accountable for all the work the team does.  Here are two good quotes:
 1. [The PO] spends half the time with the customer to define the product and half the time with team to help the team understand how to implement. This approach is as applicable today as it was in 1994. Companies that violate this introduce significant disfunction. (Jeff Sutherland).
 2. The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. (Scrum Guide, 1307)

Comments:
 - It is certainly true that the Scrum Team manages itself, as it is a self-organized team. In particular, this means that the SM and/or PO may be members of the Development Team (one of those "vary widely" things). Personally, I recommend that they are; some recommend that they aren't.
 - Sometimes, the PO is a member of the DevTeam, and sometimes she's not. Sometimes, the chores are done by the Team as a matter of self-organization; sometimes, the chores are on the Backlog and are thus prioritized by the PO. I would note Jeff's famous quote: "if it's not on the backlog, it doesn't exist," and the notion that the backlog consists of all the work anybody things should be done to deliver the Product... interesting... is cleanup or team training on the backlog or not? I say so, some say not... Varies widely, remember? I think that your first paragraph, John, is taking a stance - indicating a preference - that the Scrum Guide simply does not support.  I don't see that there are clear boundaries for the PO at all. For the SM, yes, since the SM is defined as a "servant leader", and this clearly sets some limits.
 - because of the previous paragraph, I think it would be very hard to write a CSPO exam that was consistent with the Scrum Guide. There are too many 'legal' options, and a test couldn't help but have preferences built in.

Dan :-)

Dan Rawsthorne, PhD, PMP, CST

3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Dan Rawsthorne]

There's a big difference between micro-managing the team and micro-managing the work... I have found the TPO to be a useful concept for teams that need one - this is a self-organization issue...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Dan Rawsthorne]

Why not? Is a scrum team that has not yet realized its self-organization not a scrum team? Can you tell me when a team crosses over from not-scrum to scrum? If the DevTeam grants an architect the power to make design decisions, is this not self-organization? Do you think it is actually possible to write 'bright-line' rules about this stuff? Is ti wise to even try to do so?

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Ron Jeffries]

Dan,

On Apr 11, 2015, at 10:46 PM, Dan Rawsthorne <draws...@gmail.com> wrote:

Why not? Is a scrum team that has not yet realized its self-organization not a scrum team? Can you tell me when a team crosses over from not-scrum to scrum? If the DevTeam grants an architect the power to make design decisions, is this not self-organization? Do you think it is actually possible to write 'bright-line' rules about this stuff? Is ti wise to even try to do so?

Perhaps it is true that there is no way to know what is Scrum and what is not: I do believe there is no bright line.

However, that does not mean that everything teams do in the name of Scrum is wise. You have a great ability to describe everything that happens in Scrum as if it were normal and advisable Scrum. That troubles me, because many of the things you recommend are not recommended by many of us, and many of the things you recommend are capable of very dangerous misuse.

In particular, it is not generally wise to have an empowered architect in Scrum and most teams that have one have not “granted” them power but had that power imposed.

In particular, it is not generally wise — at least according to many of us — to have the Product Owner as an implementor.

There are too many ways for the existence of an architect to be misused to recommend it willy-nilly. There are too many ways for an implementing Product Owner to be a problem to recommend that willy-nilly. 

I wish that you would add more caveats about possible (nay, in my view, probable) dysfunctions when you go around recommending things.

Ron Jeffries

ronjeffries.com

Perfectionism is the voice of the oppressor -- Anne Lamott

[Ron Jeffries]

Dan,

On Apr 11, 2015, at 10:39 PM, Dan Rawsthorne <draws...@gmail.com> wrote:

Here are two good quotes:
 1. [The PO] spends half the time with the customer to define the product and half the time with team to help the team understand how to implement. This approach is as applicable today as it was in 1994. Companies that violate this introduce significant disfunction. (Jeff Sutherland).

Reference, please? I strongly suspect that Jeff does not mean here that POs all know how to code, and I plan to follow up with him to find out.

Ron Jeffries

ronjeffries.com

An Agile method is a lens. The work is done under the lens, not by the lens.

[Dan Rawsthorne]

Have I recommended anything, or only stated that in some situations I would recommend them? There are no bright lines. I remember a very wise XP guru who told me once: "doing the simplest thing that could possibly work does NOT mean doing the stupidest thing you can think of." Good advice. Anything that is working is empirically good, anything that is not working should be changes, no? But if you don't know what options you have in your knapsack, or have purposely small knapsack, you limit what you can do...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Dan Rawsthorne]

This quote comes from this list, last year, I think. And, of course, most POs don't write code. Many of them used to, though. I think the key word here is "understand"...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[John Miller]

Thanks Dan, it does say that! I did say optimize the teams work & "manage their time". I realize now that my phrasing might be confusing. I am meaning that optimizing the teams work does not mean managing their time. This is what I am gleaming from your statements, but, correct me if I am wrong.

Perhaps it is a preference, and interpretation, one I believe better aligns the principles of self-organizing teams of the Agile Manifesto than with being a Technical PO or deciding when they get training.

I do not think it means managing the DT time and everything they do outside of the product. They may have departmental meetings, a vacation, training, volunteering etc....

This would not be the PO's realm to manage. Be informed of yes, make it visible,  and even negotiated. But, not the PO is not final decision make like they are on the Product.

I see merit in what you say, I think making it visible is a good thing. I am not so sure if that is the PO's call, though.

John Miller | Chief Empowerment Officer | Agile Classrooms  

Deepening Learning | Enriching Relationships | Broadening the Future.

Phone: (602) 753-6468

Email: agiles...@gmail.com

Website: www.agileclassrooms.com

Want to Talk, Request a Time on Doodle here https://doodle.com/JohnMiller

[Dan Rawsthorne]

Of course, it's never the PO's call. People have free will. However, the PO is accountable for it...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[John Miller]

Dan,

Free will. Perhaps Determinism. How do we know?

Still....

The PO is accountable the results of the product.

Not to the actions of the team. 

PO stands for Product Owner not People Owner. 

Thank You,

John Miller

Agile Classrooms

Clarity.Choice.Collaboration

AgileClassrooms.com

[Dan Rawsthorne]

Yes, it's a terrible name. the way it's defined nowadays, the PO should rightly be called the Team Owner, I reckon... like many things in scrum, the name belies its actual definition... Many people think that the PO is like a Product Manager, but that's not really the current definitions. The job, as defined by the Scrum Guide, is largely focused on the work of the team. Here is the SG's definition of the PO (sorry for the length):

"The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
...

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
  •  Clearly expressing Product Backlog items;
  •  Ordering the items in the Product Backlog to best achieve goals and missions;
  •  Optimizing the value of the work the Development Team performs;
  •  Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  •  Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says."

Now, a lot has been written about the PO by a lot of people (including myself), expressing guidance about how the writer sees the role. But, what we see above is the official definition. As you can see from the definition, it is a highly tactical role; the PO is the scrum team member who is accountable for optimizing the value of the team's work, makes sure the team understands the work, and assures that the work represents the organization's goals and missions. There is nothing here about creating a vision statement, determining the goals and missions, or any of that strategic stuff.

Let me use traditional terms for a a second... Sometimes the Team's Product Owner is also the Product's Product Manager, but it's not required. What is required is that the Team's Product Owner be more like the Team's Team Leader. The terms "Product Manager" and "Team Leader" both have baggage, which is why we use the term "Product Owner". It's a new term, so we get to define it. Unfortunately, the current definition of "Product Owner" is not the definition many of us have in our heads...

Here are a couple of blogs I've written on the subject:
 - http://blog.3back.com/product-owners/product-ownership-hard/
 - http://blog.3back.com/product-owners/product-ownership-overloaded-product-owners/
 - http://blog.3back.com/scrum-patterns/another-kind-overloaded-po/

Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[George Dinwiddie]

Dan,

You make the Product Owner sound like a tin-pot dictator. It's my
experience that such start single point of responsibility thinking leads
to a poorer product that costs more to develop.

The teams I've seen thrive are much more collaborative, even in deciding
what to build. While the PO may have the right to a final decision, the
best POs I've seen don't have to exercise that right. In fact, in the
very best, the team discovers what works for the end customer using the
techniques from lean startup.

I don't know why you're pushing for such strict separation of duties.
Sure, the Scrum Guide is worded to permit that, but it often makes
things go pear-shaped when that approach is taken.

- George

> 3Back.com <http://www.3back.com/>
> 1-855-32-3BACK x323
> Author of:
> /Exploring Scrum: the Fundamentals/ <http://www.amazon.com/dp/1461160286>
> /Exploring Scrum: Patterns that Make Scrum Work/**
> <https://leanpub.com/PPSAD>

> On 4/12/2015 12:20 AM, John Miller wrote:
>> Dan,
>>
>> Free will. Perhaps Determinism. How do we know?
>> Still....
>> The PO is accountable the results of the product.
>> Not to the actions of the team.
>> PO stands for Product Owner not People Owner.
>>
>>
>> Thank You,
>> John Miller
>> Agile Classrooms
>> Clarity.Choice.Collaboration

>> AgileClassrooms.com <http://AgileClassrooms.com>

>>
>> On Apr 11, 2015, at 11:16 PM, Dan Rawsthorne
>> <dan.raw...@drdansplace.com

>> <mailto:dan.raw...@drdansplace.com>> wrote:
>>
>>> Of course, it's never the PO's call. People have free will. However,
>>> the PO is accountable for it...
>>> Dan Rawsthorne, PhD, PMP, CST

>>> 3Back.com <http://www.3back.com/>
>>> 1-855-32-3BACK x323
>>> Author of:
>>> /Exploring Scrum: the Fundamentals/ <http://www.amazon.com/dp/1461160286>
>>> /Exploring Scrum: Patterns that Make Scrum Work/**
>>> <https://leanpub.com/PPSAD>

>>> On 4/11/2015 9:29 PM, John Miller wrote:
>>>> Thanks Dan, it does say that! I did say optimize the teams work &
>>>> "manage their time". I realize now that my phrasing might be
>>>> confusing. I am meaning that optimizing the teams work does not mean
>>>> managing their time. This is what I am gleaming from your
>>>> statements, but, correct me if I am wrong.
>>>>
>>>> Perhaps it is a preference, and interpretation, one I believe better
>>>> aligns the principles of self-organizing teams of the Agile
>>>> Manifesto than with being a Technical PO or deciding when they get
>>>> training.
>>>>
>>>> I do not think it means managing the DT time and everything they do
>>>> outside of the product. They may have departmental meetings, a
>>>> vacation, training, volunteering etc....
>>>> This would not be the PO's realm to manage. Be informed of yes, make
>>>> it visible, and even negotiated. But, not the PO is not final
>>>> decision make like they are on the Product.
>>>>
>>>> I see merit in what you say, I think making it visible is a good
>>>> thing. I am not so sure if that is the PO's call, though.
>>>>
>>>> John Miller | Chief Empowerment Officer | Agile Classrooms
>>>>

>>>> <http://www.agileclassrooms.com/>
>>>>
>>>> *Deepening Learning | Enriching Relationships | Broadening the Future.*
>>>>
>>>> Phone: (602) 753-6468
>>>> Email: agiles...@gmail.com <mailto:agiles...@gmail.com>
>>>> Website: www.agileclassrooms.com <http://www.agileclassrooms.com/>

>>>> 3Back.com <http://www.3back.com/>
>>>> 1-855-32-3BACK x323
>>>> Author of:
>>>> /Exploring Scrum: the Fundamentals/
>>>> <http://www.amazon.com/dp/1461160286>
>>>> /Exploring Scrum: Patterns that Make Scrum Work/**
>>>> <https://leanpub.com/PPSAD>

>>>> On 4/11/2015 9:19 AM, John Miller wrote:
>>>>> I agree the PO is complex and there is not a recipe. But, the
>>>>> PO roles has pretty clear boundaries that contains that
>>>>> complexity.
>>>>>
>>>>> I am not seeing why a PO would optimize the value of the Team's
>>>>> work & manage their time. That is up to the team to do. The
>>>>> team can decide if they need training and do so if needed
>>>>> without the PO's deciding. The PO is not their manager. The PO
>>>>> offers what she thinks are the highest "product" backlog items
>>>>> at any given time. She does not offer "team" development items.
>>>>>
>>>>> Am I hearing you correctly, Dan?
>>>>> Not saying this is bad. As a Director, I was the PO for a while
>>>>> and used Scrum Sprints for everything, from management, team
>>>>> development, training, organizational functions, and product.
>>>>> It was amazing the simplicity and clarity it brought. But, when
>>>>> I mixed in non-product goals, I was not operating as a PO, I
>>>>> was operating as a Director that used (benevolently highjacked
>>>>> perhaps) Scrum.
>>>>>
>>>>> Thank You,
>>>>> John Miller
>>>>> Agile Classrooms
>>>>> Clarity.Choice.Collaboration

>>>>> AgileClassrooms.com <http://AgileClassrooms.com>

>>>>>
>>>>> On Apr 11, 2015, at 12:19 AM, Dan Rawsthorne
>>>>> <dan.raw...@drdansplace.com

>>>>> <mailto:dan.raw...@drdansplace.com>> wrote:
>>>>>
>>>>>> Since the PO is a member of the scrum team, and can work as
>>>>>> part of the Development Team, it is often advantageous for the
>>>>>> PO to be technical. This is especially true if the PO needs to
>>>>>> balance technical chores (such as cleanup activities, team
>>>>>> training, etc) along with the product-producing work. Remember
>>>>>> that the PO is supposed to optimize the value of the team's
>>>>>> work, as well as optimize the value of the product. It's a
>>>>>> complicated thing and product ownership is done in many
>>>>>> different ways... don't expect a recipe.
>>>>>> Dan Rawsthorne, PhD, PMP, CST

>>>>>> 3Back.com <http://www.3back.com/>
>>>>>> 1-855-32-3BACK x323
>>>>>> Author of:
>>>>>> /Exploring Scrum: the Fundamentals/
>>>>>> <http://www.amazon.com/dp/1461160286>
>>>>>> /Exploring Scrum: Patterns that Make Scrum Work/**
>>>>>> <https://leanpub.com/PPSAD>

>>>>>> On 4/10/2015 8:04 PM, Ron Jeffries wrote:
>>>>>>> Raj,
>>>>>>>
>>>>>>>> On Apr 10, 2015, at 10:54 PM, rajma...@gmail.com

>>>>>>>> <mailto:rajma...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> IF PO who have background of Technology... is there any
>>>>>>>> advantage or disadvantage you find ?
>>>>>>>
>>>>>>> A PO with technical knowledge is more likely to tell the team
>>>>>>> HOW to do things rather than WHAT to do. This can hold back
>>>>>>> team creativity and results in too much power in the PO’s hands.
>>>>>>>
>>>>>>> Ron Jeffries

>>>>>>> ronjeffries.com <http://ronjeffries.com>

>>>>>>> I try to Zen through it and keep my voice very mellow and low.
>>>>>>> Inside I am screaming and have a machine gun.
>>>>>>> Yin and Yang I figure.
>>>>>>> -- Tom Jeffries
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the
>>>>>>> Google Groups "Scrum Alliance - transforming the world of
>>>>>>> work." group.
>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>> it, send an email to
>>>>>>> scrumallianc...@googlegroups.com

>>>>>>> <mailto:scrumallianc...@googlegroups.com>.

>>>>>>> To post to this group, send email to
>>>>>>> scruma...@googlegroups.com

>>>>>>> <mailto:scruma...@googlegroups.com>.

>>>>>>> Visit this group at http://groups.google.com/group/scrumalliance.
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the
>>>>>> Google Groups "Scrum Alliance - transforming the world of
>>>>>> work." group.
>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>> it, send an email to
>>>>>> scrumallianc...@googlegroups.com

>>>>>> <mailto:scrumallianc...@googlegroups.com>.

>>>>>> To post to this group, send email to
>>>>>> scruma...@googlegroups.com

>>>>>> <mailto:scruma...@googlegroups.com>.

>>>>>> Visit this group at http://groups.google.com/group/scrumalliance.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>> --
>>>>> You received this message because you are subscribed to the
>>>>> Google Groups "Scrum Alliance - transforming the world of
>>>>> work." group.
>>>>> To unsubscribe from this group and stop receiving emails from
>>>>> it, send an email to scrumallianc...@googlegroups.com

>>>>> <mailto:scrumallianc...@googlegroups.com>.

>>>>> To post to this group, send email to
>>>>> scruma...@googlegroups.com

>>>>> <mailto:scruma...@googlegroups.com>.

>>>>> Visit this group at http://groups.google.com/group/scrumalliance.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the
>>>> Google Groups "Scrum Alliance - transforming the world of work."
>>>> group.
>>>> To unsubscribe from this group and stop receiving emails from
>>>> it, send an email to scrumallianc...@googlegroups.com

>>>> <mailto:scrumallianc...@googlegroups.com>.

>>>> To post to this group, send email to
>>>> scruma...@googlegroups.com

>>>> <mailto:scruma...@googlegroups.com>.

>>>> Visit this group at http://groups.google.com/group/scrumalliance.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Scrum Alliance - transforming the world of work." group.
>>>> To unsubscribe from this group and stop receiving emails from it,
>>>> send an email to scrumallianc...@googlegroups.com

>>>> <mailto:scrumallianc...@googlegroups.com>.

>>>> To post to this group, send email to scruma...@googlegroups.com

>>>> <mailto:scruma...@googlegroups.com>.

>>>> Visit this group at http://groups.google.com/group/scrumalliance.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Scrum Alliance - transforming the world of work." group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to scrumallianc...@googlegroups.com

>>> <mailto:scrumallianc...@googlegroups.com>.

>>> To post to this group, send email to scruma...@googlegroups.com

>>> <mailto:scruma...@googlegroups.com>.

>>> Visit this group at http://groups.google.com/group/scrumalliance.
>>> For more options, visit https://groups.google.com/d/optout.
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Scrum Alliance - transforming the world of work." group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to scrumallianc...@googlegroups.com

>> <mailto:scrumallianc...@googlegroups.com>.

>> To post to this group, send email to scruma...@googlegroups.com

>> <mailto:scruma...@googlegroups.com>.

>> Visit this group at http://groups.google.com/group/scrumalliance.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Scrum Alliance - transforming the world of work." group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scrumallianc...@googlegroups.com

> <mailto:scrumallianc...@googlegroups.com>.

> To post to this group, send email to scruma...@googlegroups.com

> <mailto:scruma...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/scrumalliance.
> For more options, visit https://groups.google.com/d/optout.

--

[Vernon Stinebaker]

Interesting, but not at all how I understand the Product Owner role. The Product Owner’s authority — even as I read it described in the Scrum Guide as you have quoted below — is limited to the product and does not extend to having any authority over the development team. 

And, frankly speaking, if that’s the way it works, that’s not a team (Scrum Team or otherwise) that I’d be interested in being a member of. I respect that the Product Owner has authority over the what; over the product. They have no authority over the how. How work is going to be accomplished is a decision made by the development team. If we have a healthy Scrum Team these roles are working together in a collaborative fashion. Collaboration is not “teams team leader”.

For the same reason the ScrumMaster has no authority (having such would impair the ability of the development team to self-organize), the same thing is true for the Product Owner. For the development team to be effectively self-organizing no one can tell them how do do their work; not the ScrumMaster, and not the Product Owner. The Product Owner specifies the order that work will be performed (which optimizes the value being produced by the development team). They make sure the team development team understands the Product Backlog items to the level needed. Their authority ends with the what, not the how.

I respect you’re challenging my thinking on this topic. 

Thanks,

Vernon

[John Miller]

On Sun, Apr 12, 2015 at 7:00 AM, Dan Rawsthorne <draws...@gmail.com> wrote:

Yes, it's a terrible name. the way it's defined nowadays, the PO should rightly be called the Team Owner, I reckon...

I am scared when I read you think that Team Owner should rightly be called the Team Owner, as it threatens the foundations of the value of team autonomy and trust that I believe Scrum is built on and I value. Perhaps Product Owner is the term because it  actually describes what the role is. It is hard for me to believe, Dan, that, you really think that Team Owner is a better description...are you saying this in jest or for purpose of wit that I missed?

 

like many things in scrum, the name belies its actual definition... Many people think that the PO is like a Product Manager, but that's not really the current definitions. The job, as defined by the Scrum Guide, is largely focused on the work of the team. Here is the SG's definition of the PO (sorry for the length):

"The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
...
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
  •  Clearly expressing Product Backlog items;
  •  Ordering the items in the Product Backlog to best achieve goals and missions;
  •  Optimizing the value of the work the Development Team performs;
  •  Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  •  Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says."

It looks like you have take this one part of the Scrum Guide "Optimizing the value of the work the Development Team performs" to make your conclusions that she own the teams work. If we look at the context of the rest of the description of the PO role in the Guide, the rest of the Guide itself, and within the context of the Agile Manifesto it seems pretty clear "Optimizing the value of the work the Development Team performs" is about their work "on the product", not, "all of the teams work."

[Wouter Lagerweij]

On Sat, Apr 11, 2015 at 6:32 PM, George Dinwiddie <li...@idiacomputing.com> wrote:

I've witnessed a big disadvantage when the PO formerly played a technical role and wanted to continue to make technical decisions. This not only created dis-empowerment issues with the development team, but distracted the PO from the business concerns. In some cases, the PO was not as technically astute as they thought they were, and would discount the warnings of the developers.

A non-technical PO can ask the developers to explain technical issues in a way that they can understand. I've seen this work very well.

I think that this is the most important part of this discussion. Many agile ways are influenced by bad experiences with the inverse. A PO should be focused on product and not technical questions, because many times if a PO is technical he tries to force decisions on technical matters. That is somewhat related to the fact that in many organisation the PO still has a somewhat hierarchical relation to the development team (even if only in his own mind).

The other side of that discussion is something like the Product Champion as described in the Poppendiecks' books, as the combination of product and technical insight leading a product development effort. It doesn't have to devolve into its architypical anti-pattern. They even recommend either that combination of knowledge, or the combination of two people to supply both those sides as leadership for a product. Scrum assumes that that technical input/leadership comes from the development team as a whole, and that can work perfectly well, if the team has the required technical seniority.

The Architecture Owner, or Technical Product Owner is something that I've seen in different places. It's always a workaround. Either a workaround to the team not having the required experienced developers in it so that they can't carry the technical ownership, or, more frequently, the organisation unable to trust their development teams to carry that ownership even if the skills are there.

I actually think that in a healthy organsation, it would be a good thing for a PO to have technical skills/insight. I don't think most organisations are healthy, so approach the concept with a healthy (sorry...:-) measure of distrust.

Wouter

--

Wouter Lagerweij          | wou...@lagerweij.com

http://www.lagerweij.com  | @wouterla

linkedin.com/in/lagerweij | +31(0)6 28553506

[Ron Jeffries]

Wouter,

On Apr 12, 2015, at 6:35 PM, Wouter Lagerweij <wou...@lagerweij.com> wrote:

The other side of that discussion is something like the Product Champion as described in the Poppendiecks' books, as the combination of product and technical insight leading a product development effort. It doesn't have to devolve into its architypical anti-pattern.

Yes … but when you sit and talk with Mary, she really has in mind that the Champion totally trusts the team to figure out what to build, doesn’t direct them.

Ron Jeffries

ronjeffries.com

Apparently, this IS my circus, and, quite probably, these ARE my monkeys.

[Dan Rawsthorne]

Yes, Team Owner is a terrible name - that's why we don't use it. But Product Owner is worse because it's no longer an accurate description of the role; it's not one Product Owner per product, it's one Product Owner per team. I think that the Product Owner as described in the Scrum Guide is the right role - that it should be tactical rather than strategic - but I don't know what the right name should be; so we're stuck with PO...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Dan Rawsthorne]

Why would a technical PO make technical decisions? Is the PO not a member of the  self-organized scrum team? Doesn't the team determine how to make its decisions? Do you think there is some sort of adversarial relationship between the PO and the rest of his team? Where is your ScrumMaster when all this bad stuff is going on?

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Dan Rawsthorne]

Yes, the Product Champion is more like a Product Product Owner, not the Team's Product Owner as in Scrum. In fact, it works quite nicely when the Product Champion is working with a Scrum Team that has its own Product Owner. The Product Champion optimizes the value of the Product by sitting between the Stakeholders and the Scrum Team, and the Product Owner optimizes the value of the Team's work by sitting between the Product Champion and the Development Team...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Dan Rawsthorne]

I find this comment funny; I can't understand how you can think the Scrum Guide is describing the PO as  "tin-pot dictator". The most important line, IMHO, in the Scrum Guide's definition of the PO is "The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable." In other words, the scrum team is responsible for Product Ownership, but the PO is accountable for it. On high-performing Scrum Teams, all the Team Members are working together on Product Ownership, ScrumMastering, and Product Development. On the inside of the Scrum Team, there is no "us vs them"; however, from the outside only the PO and SM are visible. This is what the scrum guide is trying to tell us, IMHO.

Dan Rawsthorne, PhD, PMP, CST
3Back.com

1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals

   Exploring Scrum: Patterns that Make Scrum Work

[John Miller]

I am at a loss, Dan. 

I can only think that you are describing a universe where everything is backwards. Where Scrum is backwards. Kind of like the pic attached...

[John Miller]

Hi Dan,

John Miller | Chief Empowerment Officer | Agile Classrooms  

Deepening Learning | Enriching Relationships | Broadening the Future.

Phone: (602) 753-6468

Email: agiles...@gmail.com

Website: www.agileclassrooms.com

Want to Talk, Request a Time on Doodle here https://doodle.com/JohnMiller

On Sun, Apr 12, 2015 at 10:31 PM, Dan Rawsthorne <dan.raw...@drdansplace.com> wrote:

I find this comment funny; I can't understand how you can think the Scrum Guide is describing the PO as  "tin-pot dictator".

 am hearing, as you have been describing it, as the PO has the rights and power of a "dictator", and seemingly should exercise those rights at the expense of what I see as the independent right for a team to self-organize itself. Perhaps you are not meaning it as such, but, that is how I am, and it seems others, are  hearing it.

 

The most important line, IMHO, in the Scrum Guide's definition of the PO is "The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable." In other words, the scrum team is responsible for Product Ownership, but the PO is accountable for it.

 

A often forgotten part of the PO that is important, that the PO can delegate, with consent of Development Team. I point this out often, and glad to see you stress this.

On high-performing Scrum Teams, all the Team Members are working together on Product Ownership, ScrumMastering, and Product Development.

I do love this about your description of a team. The team is an entity with these shared properties. This is something that you have mentioned before and has positively influenced my view of Scrum teams.

On the inside of the Scrum Team, there is no "us vs them"; however, from the outside only the PO and SM are visible. This is what the scrum guide is trying to tell us, IMHO.

Yes! It seems we are agreeing on these principles. But, I am puzzled, as the tactics you describe, to me, violate these principles.

 

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.

[Dan Rawsthorne]

It does look that way as you look at the history of scrum, doesn't it? Particularly when it comes to the PO, who has gone from a relatively disconnected outsider to a fully integrated member of the scrum team. It was fun to watch, and it was especially fun to listen to the conversations at the early scrum gatherings, when Ken and the rest of us early trainers had great conversations about how scrum had to change - how it was changing - as more and more teams started to do it.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Dan Rawsthorne]

I don't know you hear that "the PO has the rights and power of a "dictator", and seemingly should exercise those rights at the expense of what I see as the independent right for a team to self-organize itself" from me, as I am always stressing the self-organization of the scrum team. I don't get how you can hear this... just sayin'...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Ron Jeffries]

Dan,

On Apr 13, 2015, at 1:00 AM, Dan Rawsthorne <dan.raw...@drdansplace.com> wrote:

Yes, Team Owner is a terrible name - that's why we don't use it. But Product Owner is worse because it's no longer an accurate description of the role; it's not one Product Owner per product, it's one Product Owner per team. I think that the Product Owner as described in the Scrum Guide is the right role - that it should be tactical rather than strategic - but I don't know what the right name should be; so we're stuck with PO... 

Unless I am mistaken, Scrum is a product development framework. Thus having “Product” in the name of that role is appropriate. 

The bug is in the word “Owner”.

Ron Jeffries
www.XProgramming.com
Sometimes you just have to stop holding on with both hands, both feet, and your tail, to get someplace better. 

Of course you might plummet to the earth and die, but probably not: you were made for this.

[Ron Jeffries]

Dan,

On Apr 13, 2015, at 1:04 AM, Dan Rawsthorne <dan.raw...@drdansplace.com> wrote:

Why would a technical PO make technical decisions? Is the PO not a member of the  self-organized scrum team? Doesn't the team determine how to make its decisions? Do you think there is some sort of adversarial relationship between the PO and the rest of his team? Where is your ScrumMaster when all this bad stuff is going on?

CAUTION: The following message contains sarcasm. 

It is true that the Dev Team (and Scrum Team, finally) is self-organizing. It is therefore true that they could decide to give a despotic demon from hell all authority over what they do. Now that you’ve heard those words, I expect this to happen soon:

Questioner: 

I ran across a Scrum team the other day that was completely controlled by their Product Owner, a despotic demon from hell, name of Maxwell. Maxwell controlled everything the team did, down to saying when team members could use the facilities and which booth to use. I believe Maxwell was also controlling the room temperature (it was very hot) by forcing fast molecules of air to stay in the room while requiring slow moving ones to leave. This did not seem to me to be in the spirit of Scrum, but I have to admit it seemed quite orderly. What do you all think about using a demon from hell in the Product Owner role?

Dan Rawsthorne:

Since the Scrum Team is self-organizing, if they want to be completely controlled by a demon from hell, this is perfectly normal Scrum. There is nothing to be concerned about. Move on.

Several days later, after OP has gone out and sold his soul to a demon, and after others of us have objected, we can expect to hear:

Dan Rawsthorne:

Where did I recommend using demons as Product Owners? I said that under self organization it was a possible configuration, and it is. I recall one time a wise Manifesto author said to me “Go to hell, Dan”, so clearly the Manifesto Authors considered this possibility and thought it to be quite reasonable. In addition, responding to a question about whether a demon from hell could be Product Owner, Jeff said “What the devil?”, so obviously he is on board as well.

It seems to me to be important, in our answers, to be mindful of the fact that many people here are new to Scrum, or relatively inexperienced. As such, we need to be conservative in what we seem to recommend, suggesting things which tend to lead toward the more effective use of all the team’s people, and pointing out the drawbacks to approaches that are problematic.

Scrum includes very little advice, and it is rather nicely balanced, but not perfectly balanced, in giving the What to the PO and the How to the Dev Team. In this case, putting technical power in the hands of the PO endangers that balance. As such, it is not against the law in any nation.

It’s just not a very good idea. We have a responsibility to make the implications of ideas clear, because our readers have not seen as much as we have.

Technical Product Owner: Technical knowledge can be good but is easily misused to direct solutions. Devising solutions is the job of the Dev Team. Even if the PO is a member of the Dev Team, which is strictly legal, this can be damaging to the creation of the best solutions.

Ron Jeffries

ronjeffries.com

[Ron Jeffries]

Well, Dan, no.

On Apr 13, 2015, at 1:09 AM, Dan Rawsthorne <dan.raw...@drdansplace.com> wrote:

Yes, the Product Champion is more like a Product Product Owner, not the Team's Product Owner as in Scrum. In fact, it works quite nicely when the Product Champion is working with a Scrum Team that has its own Product Owner. The Product Champion optimizes the value of the Product by sitting between the Stakeholders and the Scrum Team, and the Product Owner optimizes the value of the Team's work by sitting between the Product Champion and the Development Team... 

The thing Mary talks about is the real person, who comes into the team all the time, explains to them what needs to happen, and sets them free to do it. I sat on a stage with her in California as she explained this notion, and at that time I said that the Scrum Product owner, with responsibility for What and not for How, was, could be, and should be exactly that thing.

There is only one role of this kind in Scrum, not two. I am suggesting that the name should be changed. The thing you describe, with two people in between stakeholders and team is not Scrum, and is a step away from what Scrum is trying to do.

Scrum already has too many people between stakeholders and the Dev Team. Having the Product Owner is a compromise that allows accountability to be focused (which companies want even though they likely should not) and allows for creation of a single thread of work. It has the drawback of distancing the Dev Team from the need, which the Scrum creators apparently felt was acceptable. They didn’t put more people in the way. I’d suggest that that’s because people in the way between builders and users are invariably a problem.

So starting your reply with “Yes” and then saying something which is exactly not what I said? Well, no.

Ron Jeffries

ronjeffries.com

[Ron Jeffries]

Dan,

On Apr 13, 2015, at 1:31 AM, Dan Rawsthorne <dan.raw...@drdansplace.com> wrote:

I find this comment funny; I can't understand how you can think the Scrum Guide is describing the PO as  "tin-pot dictator”.

George didn’t say that the Scrum Guide describe a tin-pot dictator. He said that what YOU were describing sounded that way. Sounded almost that way to me as well, since you said that the [Technical] Product Owner (not a Scrum role at all) could tell the Dev Team how to build things, which means that that individual has despotic control over both what is done and how it is done. 

The most important line, IMHO, in the Scrum Guide's definition of the PO is "The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable." In other words, the scrum team is responsible for Product Ownership, but the PO is accountable for it.

No, they may be responsible for this PO work or they may not. First of all, “the above work” is

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

This says that the Scrum team may do that work (be responsible), not that they must do that work. And it says nothing about the actual work of building at all.

I would add this quote from the Scrum Guide, under the heading of The Development Team:

No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

By my understanding of the phrase “no one”, that means that the President, CIO, Product Owner, Technical Product Owner, Technical Lead, Lead Architect, Some Guy Down The Hall, and the Benevolent Demon From Hell may not tell the Development Team how to do the building.

I think that may be the most clear sentence in the whole Scrum Guide.

On high-performing Scrum Teams, all the Team Members are working together on Product Ownership, ScrumMastering, and Product Development. On the inside of the Scrum Team, there is no "us vs them"; however, from the outside only the PO and SM are visible. This is what the scrum guide is trying to tell us, IMHO.

Agreement: I believe that the working together part of this is the way things should be, and that inside the Scrum Team there should be all collaboration. This would mean, as an aside, that:

• The Product Owner would never, ever, decide what the highest priority was: the team would do that;
• The Technical Product Owner, if some idiot had declared one, would never, ever, decide how to do something: the team would do that.
• … and so on.

Disagreement: As for visibility outside the team, I suspect you go too far. It’s not good for team members to be invisible to the company: that way lies “resource” thinking, and that’s not a good thing.

Ron Jeffries

ronjeffries.com

It's true hard work never killed anybody, but I figure, why take the chance?

-- Ronald Reagan

[Ron Jeffries]

Dan,

On Apr 13, 2015, at 2:18 AM, Dan Rawsthorne <draws...@gmail.com> wrote:

It does look that way as you look at the history of scrum, doesn't it? Particularly when it comes to the PO, who has gone from a relatively disconnected outsider to a fully integrated member of the scrum team. It was fun to watch, and it was especially fun to listen to the conversations at the early scrum gatherings, when Ken and the rest of us early trainers had great conversations about how scrum had to change - how it was changing - as more and more teams started to do it. 

You have a way of pretending that Scrum and Ken and Jeff agree with you when there is no reason to believe that they do.

I do agree that it would work well with PO as a fully integrated member of the Scrum team. What you seem to miss out is that to be a fully integrated member of the Scrum team, they can no longer command: their authority has to be given to the Scrum team. If they retain their power, then they are not fully integrated, and this is not the case of a fully integrated Scrum team after all.

Can’t have it both ways. Either the PO has power, in which case it is the power of What, or they release that power to the team, in which case the PO has neither the power of What, nor the power of How, which she never had to begin with.

Ron Jeffries

ronjeffries.com

If not now, when? -- Rabbi Hillel

[Ron Jeffries]

Dan,

On Apr 13, 2015, at 2:21 AM, Dan Rawsthorne <draws...@gmail.com> wrote:

I don't know you hear that "the PO has the rights and power of a "dictator", and seemingly should exercise those rights at the expense of what I see as the independent right for a team to self-organize itself" from me, as I am always stressing the self-organization of the scrum team. I don't get how you can hear this... just sayin'...

It was that place where you said explicitly that the Product Owner could tell the team how to do their work.

Ron Jeffries

ronjeffries.com

Impossible is not a fact. It is an opinion.  -- Muhammad Ali

[Wouter Lagerweij]

On Mon, Apr 13, 2015 at 2:30 AM, Ron Jeffries <ronje...@acm.org> wrote:

Wouter,

On Apr 12, 2015, at 6:35 PM, Wouter Lagerweij <wou...@lagerweij.com> wrote:

The other side of that discussion is something like the Product Champion as described in the Poppendiecks' books, as the combination of product and technical insight leading a product development effort. It doesn't have to devolve into its architypical anti-pattern.

Yes … but when you sit and talk with Mary, she really has in mind that the Champion totally trusts the team to figure out what to build, doesn’t direct them.

Ah, that is interesting. I will have to re-read that book.

I do think that that trust is always necessary. I just don't think technical knowledge would disqualify someone for a PO role, and that it can be a very useful thing. It should not (and could not) replace knowledge/skills in the team.

Wouter

[Ron Jeffries]

Hi Wouter,

On Apr 13, 2015, at 11:32 AM, Wouter Lagerweij <wou...@lagerweij.com> wrote:

I do think that that trust is always necessary.

Yes, though that’s not an easy topic ...

I just don't think technical knowledge would disqualify someone for a PO role, and that it can be a very useful thing.

Knowledge is always good to have, but whether it does good depends on how it’s used. I’ve seen POs imposing solutions, all unknowing, just because they know stuff. That’s not so good ...

It should not (and could not) replace knowledge/skills in the team.

Just so ...

Ron Jeffries

ronjeffries.com

I don't necessarily agree with everything I say. -- Marshall McLuhan

[Dan Rawsthorne]

Well, I think the word "owner" is ok, as the PO certainly owns (is accountable for) something - this is his/her defining characteristic. The question is: "what does he/she own?" In original scrum it was the Product: the PO established the Vision, Goals and Objectives. Nowadays, however, the PO is the scrum team member who is accountable for ordering the Backlog in order to achieve the Goals and Objectives... maybe he/she should be called the "Backlog Owner" :)

Seriously, though, PO is a bad name as it makes people think of a Product Manager-type position, rather than a team member. To put it in military terms, the phrase "product owner" makes you think of a General, not a Squad Leader...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Dan Rawsthorne]

Nice, Ron... this discussion is one we've had many time in the military, when discussing Generals such as Patton, Bradley, and Eisenhower... and the answer in those discussion is that it is the NCO's (SM's) job to keep the demons from being demons.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Dan Rawsthorne]

Of course it's not scrum to have two people, unless you've self-organized to get there. What you need, ideally, is to have one person who spends half his/her time with the stakeholders, and half his/her time with the team... just like Jeff said. Everything else is a compromise of some sort. But, agility is all about making compromises, understanding why they are compromises, and why they are the compromises you made...

I don't think that scrum distances the team from the need. The scrum team is supposed to have all the knowledge and skills necessary to develop the product, and this includes understanding the need. When the team doesn't adequately understand the need, they need to bring SMEs into the team as honorary team members. To do otherwise is ineffective, but it's a compromise you might make, yes? BTW, note that I said "bring SMEs in" not "let Stakeholders interrupt you with suggestions"... just sayin'...

Clearly, there should be no one between the developers and SMEs, but we want distance between the developers and wanna-be prioritizers. Different things...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Dan Rawsthorne]

Yes, we're in total agreement. what's the issue? I didn't talk about the Technical Product Owner at all, it's just the title of the thread... as an aside, I do think Technical Product Owners are useful, but their role is to set standards, not tell people how to do things. Note, a Technical Product Owner is not a technical Product Owner, which is also useful at times...

Oh, I see you are confused by the sentence: "the scrum team is responsible for Product Ownership, but the PO is accountable for it." I stand by this; it is the definition of "responsible" that we disagree on, I guess. Responsible means "does the work", and the PO, SM and Devs are all part of the Scrum Team. Therefore, the Scrum Team is responsible for all of it. However, the PO is accountable for the Product Ownership stuff, the SM is accountable for the ScrumMastering stuff, and each developer is accountable for development. This concept is also a consequence of the team being self-organized.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.

[Dan Rawsthorne]

I can't find where I said that. show me the money...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Dan Rawsthorne]

No. The Product Owner (and SM) are fully integrated members of the Scrum Team. They may, or may not, also be part of the DevTeam, which is the subset of the Scrum Team that is actually working on Backlog Items (personally, I prefer that they are). The PO is the captain of the Scrum Team (see http://en.wikipedia.org/wiki/Captain_%28sports%29 )

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[Mark Levison]

Dan have you ever found it interesting, noteworthy that few (if any) other scrum trainers agree with your definition of product owner?

Cheers
Mark

[Dan Rawsthorne]

No, but I do find it interesting that we understand the definition so differently.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work

[David Grant]

Hi Raj,

On Friday, 10 April 2015 18:26:55 UTC+1, Rajmahendra wrote:

Please help me with understand this and how many of you are PO with Technical knowledge and how this helps Scrum Team  ? 

I'm a product owner with a technical background, so I suppose one might call me a "technical Product Owner".  

From the team's point of view, it's a mixed blessing.  On the positive side, I'm able to understand the team's need to plan technical improvements, e.g. continuous delivery, refactoring, etc. which simplifies our negotiation for constructing a sprint backlog.  Furthermore, I also have the most knowledge about a particular technology in the team, so I'm asked for technical advice and to review code which helps to improve the team's performance.

On the negative side, it's a distraction for both sides.  I don't specify solutions to the team, but I do question the team over their choices if I think there's a possibility of rework in the future (and therefore fewer features).  I'm sure the team would come up with a lot more negatives if any of them read this list!

Like any aspect of Scrum, the PO role requires discipline.  Having a technical background just adds to the discipline you need to learn.

Dave

[Alan Dayley]

Great comments, Dave!

Alan

--

[MJ]

Thank you for that example.  We have a lot of coaches and trainers here, and I especially like hearing from active practitioners. 

--mj 

(Michael) 

--

[miked]

Technical competence begs a lot of questions.

What Technology?  Is the competency in the business domain such as finance, blowing up balloons or computers?

How current is the person in the technology?  Do you want some one who used to be competent guiding you into the future?

On Friday, April 10, 2015 at 1:26:55 PM UTC-4, Rajmahendra wrote:

Is the term "Technical Product Owner" new i only heard about Product Owner

This means that Product Owner with Technical knowledge ? I do see some PO not having much idea on technical knowledge mostly dominated by Team.

This new tern is same like Scrum Master with technical knowledge and PO with Technical knowledge.

Please help me with understand this and how many of you are PO with Technical knowledge and how this helps Scrum Team  ? 

--

Thank you and regards,
Rajmahendra (Raj)
Founder / Lead JUG Chennai/Hyderabad

NetBeans Dream Team Member

http://www.twitter.com/rajonjava
----------------------------------------------------------------------------------------------
"DREAM is not what you see in sleep;
is the thing which does not let you sleep" - APJ Abdul Kalam
Do the difficult things while they are easy and do the great things while they are small.
A journey of a thousand miles must begin with a single step. - Lao Tzu