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

Product Owner and retrospectives

Expand Messages
  • Ram Srinivasan
    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
    Message 1 of 6 , Oct 19, 2012
    • 0 Attachment
      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


      [Non-text portions of this message have been removed]
    • Chet Hendrickson
      Hello Ram, XP doesn t have a Product Owner role and its does not require retrospectives. XP does have a Customer, and she is a full member of the Whole Team.
      Message 2 of 6 , Oct 19, 2012
      • 0 Attachment
        Hello Ram,

        XP doesn't have a Product Owner role and its does not require retrospectives.

        XP does have a Customer, and she is a full member of the Whole Team. Her participation in a the Team's retrospective should be the same as any other member's.

        chet

        Friday, October 19, 2012, 9:48:03 AM, you 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

        [Non-text portions of this message have been removed]






        --
        Best regards,
        Chet Hendrickson mailto:lists@...
        Check out our upcoming CSM Plus courses @
        http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28

        [Non-text portions of this message have been removed]
      • Michal Svoboda
        ... (1) Is prefered variant for me. Big advantage - people act as a team and build trust in each other. Anybody who is involved with the product should be part
        Message 3 of 6 , Oct 19, 2012
        • 0 Attachment
          Ram Srinivasan wrote:
          > 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?

          (1) Is prefered variant for me. Big advantage - people act as a team and
          build trust in each other. Anybody who is involved with the product
          should be part of the team. For inexperienced teams, watch for tendencies
          to override the discussion, leaving not enough space for everyone to
          express themselves freely.

          (2) Anybody who does not participate fully may give an enigmatic
          appearance of taker and not giver and may make the team uncomfortable.

          (3) They will lose contact with the team.

          As for anything else, it may be useful, for example due to experience,
          that (4) they facilitate the meeting.
        • Succi Giancarlo (P)
          Dear All, we are currently performing a research on the successful evolution of Agile Methods and on understanding the possible related impediment. Along these
          Message 4 of 6 , Oct 25, 2012
          • 0 Attachment
            Dear All,
            we are currently performing a research on the successful evolution of Agile Methods and on understanding the possible related impediment.

            Along these lines we have written and presented a paper at SPLASH 2012 on what we call "The Dark Side of Agile Software Development" http://darkagilemanifesto.org/dark-side-of-agile-janes-succi-splash-2012.pdf. The video of the presentation is in youtube: (http://www.youtube.com/watch?v=McSROabNbdU).

            To move ahead in our research we have developed a questionnaire based on what we call the "Dark Manifesto for Agile Software Development" (http://darkagilemanifesto.org) and we kindly ask you to fill it and to distribute it into your network. It is at URL:https://docs.google.com/spreadsheet/viewform?formkey=dHZIbkNYMUQxOU03cjBCUnZIWDZXSWc6MQ.

            We have also created a Facebook (http://www.facebook.com/darkagilemanifesto) page and a LinkedIn group (http://www.linkedin.com/groups/Dark-Side-Agile-4688911?gid=4688911) to discuss further the subject.

            We kindly ask you to fill the questionnaire and to pass it to other people that you feel could be interested, and to join the facebook and/or the linkedin groups to continue there the discussion.

            Thanks a lot!
            Alberto, Andrea, and Giancarlo



            ________________________________
            Giancarlo Succi, PhD, PEng
            Professor and Director
            Center for Applied Software Engineering (CASE)
            Free University of Bolzano/Bozen
            Dominikanerplatz 3 Piazza Domenicani
            I-39100 Bozen/Bolzano, Italy
            ph: +39(0471)016-131 - fax: +39(0471)016-009 - m: +39(320)922-4192
            e-mail: Giancarlo.Succi@...<blocked::mailto:Giancarlo.Succi@...>
            www.case.unibz.it<blocked::http://www.case.unibz.it/>

            Importante: Il presente messaggio contiene informazioni riservate al solo destinatario. Se avete ricevuto questo messaggio per errore, Vi chiediamo di avvertire immediatamente il mittente e di cancellarla assieme agli eventuali allegati. Qualsiasi uso, comunicazione o diffusione non autorizzata delle informazioni riportate nel messaggio assieme agli eventuali allegati è rigorosamente proibita.
            Wichtig: Diese Mitteilung enthält vertrauliche Informationen, die einzig für den Empfängers bestimmt sind. Falls Sie diese Nachricht irrtümlich erhalten haben, werden Sie ersucht, sofort den Absender darüber zu informieren und diese Mitteilung samt Anhang zu löschen. Die unbefugte Nutzung, Weiterleitung oder Verbreitung der Informationen dieser Mitteilung und deren Anhang ist streng verboten.
            Warning: The information contained in this e-mail is confidential or may otherwise be legally privileged. It is intended for the named recipient only. If you have received it in error, please notify us immediately by reply or by calling the telephone number above and delete this message and all its attachments. Please note that any unauthorised review, copying, disclosing or otherwise making use of the information is strictly prohibited.
          • marcodorantes
            Let me also post here my responses for further discussion: Part 1 ... If doing it is removed then there are lesser chances to reflect, to inspect, and to
            Message 5 of 6 , Nov 9, 2012
            • 0 Attachment
              Let me also post here my responses for further discussion:

              Part 1
              >Do you think that instead of "We are uncovering better ways of developing software by doing it and helping others do it." people tend to adopt "We are uncovering the only ways of developing software teaching others."?

              If "doing it" is removed then there are lesser chances to reflect, to inspect, and to adapt on the search for the specific business value —which often is a moving target— in a given context. Key parts of software development could be seen as epistemological endeavors; thus, if the empirical or experimental part is removed then the justification of the achieved business value could be dramatically diminished.

              >Do you think that instead of "Individuals and interactions over processes and tools" people tend to adopt "Individuals and interactions and not processes and tools"?

              If the processes and tools do not help for better communication between individuals then those processes and tools should not be followed or used. Instead, an open dialog among practitioners should define proper processes and tools that help them to practice their values and professional principles.

              >Do you think that instead of "Working software over comprehensive documentation" people tend to adopt "Working software and not comprehensive documentation"?

              The lack of a proper way to remember or to communicate relevant things to future or distant people is certainly a problem that should be solved in a project or product. That is a different problem than the problem of effort wasted in obscure and ineffective documents that nobody read. Besides, there is a plethora of recording technologies that could help to preserve and transmit relevant and valuable things about a project.

              >Do you think that instead of "Customer collaboration over contract negotiation" people tend to adopt "Customer collaboration and not contract negotiation"?

              And for that matter: who, on the face of the Earth, is going to listen to the end-user?

              >Do you think that instead of "Responding to change over following a plan" people tend to adopt "Responding to change and not following a plan"?

              If «a plan» no longer follows discovered and corroborated reality, then it is wise to make all sort of proactive adjustments or an entire new plan. The key to follow, of course, is not the outcome —a plan— but the frequent practice of planning. Conversely, blind reactions to whimsical moves, without awareness of the related costs, pave the path to diminished business value or business failure.

              >Do you think that instead of "That is, while there is value in the items on the right, we value the items on the left more." people tend to adopt "That is, while since there is no value in the items on the right, we value only the items on the left."?

              A part of the problem is a psychological pattern of neglected interpretation. It is not, of course, something exclusive of agile methods but it is a pervasive lack of education that permeates politics, economics, and many more spheres of society. The root cause is a very, very poor foundation in important areas of life, whereas is it called science, philosophy, history, mathematics, ethics, etc.
              What prevents us from learning a new concept is the preconception that usurps its place. See what Derek A. Muller has to say in the case of scientific concepts: youtu.be/eVtCO84MDj8
            • marcodorantes
              ... Yes, I have often seen a kind of indoctrination into the new «one and only true agile cult». But that is because people do not actually read and reflect
              Message 6 of 6 , Nov 11, 2012
              • 0 Attachment
                This is my take 2 on the survey:

                >Do you think that instead of "We are uncovering better ways of developing software by doing it and helping others do it." people tend to adopt "We are uncovering the only ways of developing software teaching others."?

                Yes, I have often seen a kind of indoctrination into the new «one and only true agile cult». But that is because people do not actually read and reflect on what writing software and agile are about. So the problem is radical dogmatism: people imposing unquestionable ideas over other people; that kind of dogmatism has the consequence you are contrasting. There is another kind of dogmatism that is chosen by an individual upon herself provisionally, as a stage in her apprentice path; about this look for `Shu-Ha-ri' in the agile literature.

                >Do you think that instead of "Individuals and interactions over processes and tools" people tend to adopt "Individuals and interactions and not processes and tools"?

                Yes, I have recently seen a development director that forced their teams to use Post-it on the wall whereas they have a fully functional development suite of wonderful tools to have a `single system of record' of project reality; one consequence is that those teams now have two systems to keep in synchrony, wasting effort that could otherwise be in more useful activities.

                >Do you think that instead of "Working software over comprehensive documentation" people tend to adopt "Working software and not comprehensive documentation"?

                I have seen no significant change with the problem of documentation. I still see much of both, too much ineffective documents and too little concise and useful forms of documents that help to communicate, and to preserve, important justifications of why the software is as it is.

                >Do you think that instead of "Customer collaboration over contract negotiation" people tend to adopt "Customer collaboration and not contract negotiation"?

                I would be interested to see what might come out of such a tendency: "Customer collaboration and not contract negotiation". I still see too much protectionist focus on the terms of the contract, out of pure fear from both the customer and the provider. I would like to see more about designing value-streams that end at the end-user level.

                Do you think that instead of "Responding to change over following a plan" people tend to adopt "Responding to change and not following a plan"?

                I see that teams must respond to change but they do it in different ways depending of their context, and with different business consequences. Some, by contract restrictions, certainly must wait until the current plan ends; others, who provisioned proper contract clauses, can adapt to new business priorities more quickly. Many could respond to change quickly but also can break things more quickly; I still see fewer teams who are able to actually change quickly and not breaking a single feature at the same time.

                >Do you think that instead of "That is, while there is value in the items on the right, we value the items on the left more." people tend to adopt "That is, while since there is no value in the items on the right, we value only the items on the left."?

                I think that we people fool ourselves into thinking that we understand something new without proper application of the tenets of critical thinking. We often fail to challenge properly our own presuppositions and then misread new concepts, relating them with what we already have in our memory; mere opinion is misinterpreted as knowledge. So, little or nothing new is actually learned. For example, an agile development process is seen as a sequence of steps or discrete iterations instead of an integrated set of value streams.

                Thoughts?

                --- In extremeprogramming@yahoogroups.com, "marcodorantes" <marcodorantes@...> wrote:
                >
                > Let me also post here my responses for further discussion:
                >
                > Part 1
                > >Do you think that instead of "We are uncovering better ways of developing software by doing it and helping others do it." people tend to adopt "We are uncovering the only ways of developing software teaching others."?
                >
                > If "doing it" is removed then there are lesser chances to reflect, to inspect, and to adapt on the search for the specific business value —which often is a moving target— in a given context. Key parts of software development could be seen as epistemological endeavors; thus, if the empirical or experimental part is removed then the justification of the achieved business value could be dramatically diminished.
                >
                > >Do you think that instead of "Individuals and interactions over processes and tools" people tend to adopt "Individuals and interactions and not processes and tools"?
                >
                > If the processes and tools do not help for better communication between individuals then those processes and tools should not be followed or used. Instead, an open dialog among practitioners should define proper processes and tools that help them to practice their values and professional principles.
                >
                > >Do you think that instead of "Working software over comprehensive documentation" people tend to adopt "Working software and not comprehensive documentation"?
                >
                > The lack of a proper way to remember or to communicate relevant things to future or distant people is certainly a problem that should be solved in a project or product. That is a different problem than the problem of effort wasted in obscure and ineffective documents that nobody read. Besides, there is a plethora of recording technologies that could help to preserve and transmit relevant and valuable things about a project.
                >
                > >Do you think that instead of "Customer collaboration over contract negotiation" people tend to adopt "Customer collaboration and not contract negotiation"?
                >
                > And for that matter: who, on the face of the Earth, is going to listen to the end-user?
                >
                > >Do you think that instead of "Responding to change over following a plan" people tend to adopt "Responding to change and not following a plan"?
                >
                > If «a plan» no longer follows discovered and corroborated reality, then it is wise to make all sort of proactive adjustments or an entire new plan. The key to follow, of course, is not the outcome —a plan— but the frequent practice of planning. Conversely, blind reactions to whimsical moves, without awareness of the related costs, pave the path to diminished business value or business failure.
                >
                > >Do you think that instead of "That is, while there is value in the items on the right, we value the items on the left more." people tend to adopt "That is, while since there is no value in the items on the right, we value only the items on the left."?
                >
                > A part of the problem is a psychological pattern of neglected interpretation. It is not, of course, something exclusive of agile methods but it is a pervasive lack of education that permeates politics, economics, and many more spheres of society. The root cause is a very, very poor foundation in important areas of life, whereas is it called science, philosophy, history, mathematics, ethics, etc.
                > What prevents us from learning a new concept is the preconception that usurps its place. See what Derek A. Muller has to say in the case of scientific concepts: youtu.be/eVtCO84MDj8
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.