Loading ...
Sorry, an error occurred while loading the content.

56093Re: [scrumdevelopment] Product Owner and retrospectives

Expand Messages
  • Kevin Callahan
    Oct 23 7:22 AM
    • 0 Attachment
      Perhaps if the topic of discussion/level of detail is not valuable for all retro participants, it's not the appropriate topic or level of detail? While I agree 100% that the retro topics are emergent and brought to the table by the team, there are facilitation strategies to dig into the underlying issues of topics (i.e. accuracy vs. precision). For instance if the programmers are getting deep into improving a specific engineering practice that's leaving some team members (PO, tester, etc) disengaged, perhaps that's a good reason to change the focus of the discussion from the actual implementation (precision) to the motivation for the change (accuracy). By ensuring the topic is accurate (talking about the right thing in that moment), the entire team will more likely engage. 

      For instance the topic of code smells is raised, and the team starts talking about single responsibility and how specific bits of code don't comply, etc. That's a very precise topic of discussion, and the PO will likely take out his phone (even if it violates working agreements) and check email :) However, if the questions are asked "why is single responsibility important? why does it matter to quality? what are the short and long-term implications of building it in?" the context shifts from being very domain-specific to a higher level of abstraction that is more accessible. The conversation topic is now less precise, though more accurate; the PO can definitely engage in a discussion about development cycle length and building in quality. Additionally, this is solution-based and looks toward progress rather than hashing out why a particular developer checked in or didn't adequately review some code.

      In this case by focusing on strategies for quality the entire team can achieve alignment, and the PO can understand why there's value in the team taking sufficient time for refactor cycles and can radiate that information out to the rest of the organization, and the tester can understand where and how to improve defining behavior, assessing test coverage, and improving automation. If the programmers need to have their own sessions to hash out the implementation details they should. That's the beauty of self-organization!

      Generally speaking, as the SM I'm joined at the hip with the PO; he's not a proxy, not a manager, he's a full time, hugely valuable core member of the team and deeply invested in collaboration. If, for whatever reason, this were not the case, then I'd suspect some deeper issues were at work along the lines of what some other folks have been suggesting…


      On Oct 23, 2012, at 9:07 AM, Pierre Neis wrote:


      Reacting of "Proxy PO".

      I can agree that the way to do scrum can be a journey and we need to handle with the existing organisation structure.
      But, in my small experience as Coach and Scrum Improver, a question emerges : who does the job? Usually, you got a PO working in Product Development Department and the proxy working with the Development team.
      Regarding effectiveness of working scrum, you can see that proxy is in reality "the PO" and the other joins "Chicken Trib".

      Thinking about the initial question of "does the PO attend Retrospective", is Retrospective not "Pigs Meeting?"

      On my side, I never did consider Scrum as Software Development "method/framework". There are enough amazing frameworks doing a much better job.
      If you consider Scrum as Product Development "method/framework", then I can understand scrum. But, if this is true and we shall improve randomly ourselves the way how we did it (during the Sprint) and the only person who is not involved in this process is the Product Manager (PO) and we discuss only about engineering practices, then I have a problem Houston!

      Years ago, I co-trained CSM Classes and the well-known trainer tell to the audience to make one Retrospective only with the Dev Team and a second including the PO (and only if this makes sense). Does this make sense?
      The opposite could be making a Demo with the team and the stakeholders, a Sprint Review without the Developers. Scrum non-sense! 

      But this is only my point of view

      Pierre E. Neis Scrum/Lean Improver

      WE & Co , the Collab Lab |  PLöRK 
      Mobile: (+352) 661 SCRUMS
      Luxembourg - Brussels - Paris - Zürich - London - Amsterdam - Barcelona - Hanoi

      Blogger Twitter LinkedIn SlideShare XING Google Plus Viadeo
      Contact me: Skype pierre.neis

      On 23 October 2012 12:09, Gercel Silva <gercel@...> wrote:

      I agree that the PO participating in the retrospective can be very beneficial. However as Michael Mallete pointed out there are impediments in some organizations that cause him not to be there. 

      The one I've observed recently is this:
      - PO got bored a lot of times as there were too much talk about engineering practices improvement

      Since the PO is usually a 'very busy' person, some people tend to think that him participating in the retrospective is a waste his valuable time. Considering there is much talk about engineering practices, 
      what should we be doing to make this meeting more appealing to the PO? Maybe split it in two?


      On Mon, Oct 22, 2012 at 10:06 PM, Michael James <mj4scrum@...> wrote:

      Of course Scrum does not imply we need any manager role at all (in fact, nudges us away from that).  But nearly all organizations still have managers, and usually the only people with sufficient authority to be Product Owners also happen to be managers.  The alternative, called "proxy Product Owner," is a dysfunction in my opinion.


      On Oct 22, 2012, at 4:40 PM, Alan Dayley <alandd@...> wrote:



      Your description of a normal organization implies that the PO is a manager of the Scrum Team.  While that might be the case in some places, I see that as a problem.  The PO should be a peer of the rest of the Scrum Team.

      Or did you not mean to imply this?


      On Mon, Oct 22, 2012 at 4:23 PM, Michael James <mj4scrum@...> wrote:

      Let's say there are two kinds of organizations interested in this question: 

      In a low fear organization, even the lowliest, least confident newhire is comfortable admitting that his behavior might be colored by having a person with management power in the room.  I think when people are truly honest with themselves they realize they're not immune to "looking good for the boss" type behavior even (or especially) when the boss is a nice guy.  And if I'm sympathetic to my teammate, I'm less likely to tell him he needs to brush up his skills in a certain area in the presence of a person with management power (such as the power to influence who's retained in the event of a layoff, who gets raises, etc.).  So a team in a low fear organization may say they sometimes benefit from doing some of their standups or retrospectives without the Product Owner -- assuming we've got a real Product Owner with actual management authority and not a proxy.

      In a normal organization (medium-to-high fear), everyone's got to buck up and pretend people with management power don't affect their behavior, out of fear or a lack of self awareness.  Teams in these organizations are even less likely to reach higher levels of self management if we make a hard and fast rule that the PO must always attend every team meeting.

      Are there zero fear organizations?  Maybe, but if that's what people are claiming we have (especially the high-status people), it's more likely we have a medium-to-high fear organization.


      On Oct 22, 2012, at 2:05 PM, Steve <steve@...> wrote:


      Hello Michael

      Given the lack of a 'smilely', I cannot tell wheteher you are being ironic or not.

      So I'll 'play dumb'!

      Which 'team' - Scrum or Development?

      --- In scrumdevelopment@yahoogroups.com, Michael James <mj4scrum@...> wrote:
      > Perhaps the team should decide.
      > --mj
      > (Michael)
      > On Oct 22, 2012, at 10:45 AM, Steve wrote:
      > > Hello Mike
      > >
      > > The Scrum Primer was written at least 5 years ago since when there have been at leat 2 'upgrades' to the Scrum Guide.
      > >
      > > The latest version of the Scrum Guide has (at last) sorted out the difference between 'team' (small 't') and 'Team' (capital 'T'); this has been causing all sorts of confusion over the years!
      > >
      > > There are 2 teams in Scrum - the 'Development Team' and the 'Scrum Team'; the Scrum Team is made up of the the Development Team, the PO and the Scrum Master.
      > >
      > > In my opinion, all the Scrum Team memmbers should attend all the retrospectives.
      > >
      > > If it is considered that having the PO at the retrospective would reduce the 'safe' environment, then this would be an impediment that he Scrum Master should be doing something about!
      > >
      > > My 2-penny-worth
      > >
      > > --- In scrumdevelopment@yahoogroups.com, Michael Mallete <mrmallete@> wrote:
      > > >
      > > > If you refer to the Scrum Guide, the scrum team does partake in this
      > > > meeting.
      > > >
      > > > Scrum Primer on the other hand makes it distinctly a team + Scrum Master
      > > > and only optionally the Product Owner.
      > > >
      > > > Given that, I guess that just shows how polarizing, or at least debatable,
      > > > this thing is.
      > > >
      > > > I would personally decide based on:
      > > >
      > > > - safety (does the team feel safer if it's only them in the meeting, or
      > > > it's ok to have more people in there)
      > > > - non-divisiveness (what does the PO feel if he/she is excluded)
      > > > - overall value the participants felt (more value when everyone is there)
      > > >
      > > > HTH.
      > > >
      > > > salamat,
      > > > mike mallete
      > > >
      > > > On Sat, Oct 20, 2012 at 3:15 AM, Alan Dayley <alandd@> wrote:
      > > >
      > > > > **

      > > > >
      > > > >
      > > > > In Scrum:
      > > > > - The Product Owner is a member of the Scrum Team.
      > > > > - The Scrum Team has a retrospective every Sprint.
      > > > > - People not on the Scrum Team do not attend the retrospectives.
      > > > >
      > > > > Therefore:
      > > > > - The Product Owner participates in the retrospectives.
      > > > > - Directors, VPs and others do not participate nor attend the
      > > > > retrospectives.
      > > > >
      > > > > There can be reasonable and even beneficial exceptions to the above.
      > > > > However, IMO deviations from the above should be rare, for many reasons.
      > > > >
      > > > > Are you looking for reasons to deviate from the above definitions and why
      > > > > or why not to deviate?
      > > > >
      > > > > Alan
      > > > >
      > > > >
      > > > > On Fri, Oct 19, 2012 at 6:48 AM, Ram Srinivasan <vasan.ram@>wrote:
      > > > >
      > > > >> **

      > > > >>
      > > > >>
      > > > >> I am curious to know the different ways in which a PO can participate/not
      > > > >> participate in a team's retrospective. Some of the ways that I can think of
      > > > >> include
      > > > >>
      > > > >>
      > > > >> 1. PO is a participant there might be valuable input from/for PO.

      > > > >> Also POs help might be needed to resolve some impediments beyond the scope
      > > > >> of the team.
      > > > >> 2. PO can be an observer
      > > > >> 3. PO not being in the team's retrospective

      > > > >>
      > > > >> Is there anything else that you can think of (may be not just PO, but
      > > > >> someone in a position of authority e.g. Director/V.P of development) ?
      > > > >>
      > > > >> Obviously these are context dependent, but what would be the pros/cons
      > > > >> and smells in these approaches?
      > > > >>
      > > > >> -Ram
      > > > >>
      > > > >>
      > > > >
      > > > >
      > > >
      > >
      > >

      Kevin Callahan
      Scrum Master & Agile Coach
      LiveWorld Inc.
      Direct+1 (207) 691-2997
      Follow UsFacebook Twitter LinkedIn

    • Show all 27 messages in this topic