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

Re: Weakness in Product Management?

Expand Messages
  • jamesjhawkins
    The following reminded me of a discussion I had with a Scrum Coach ... I said that the Product Owner should review the test cases, during the Sprint. I also
    Message 1 of 24 , Sep 7, 2012
    • 0 Attachment
      The following reminded me of a "discussion" I had with a Scrum Coach

      --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...> wrote:
      > In my experience, product management sets
      > up the product definition, hands that off to the development
      > team/group/department and then walks away. The problems come from this
      > lack of consistent connection between product management and product
      > development.

      I said that the Product Owner should review the test cases, during the Sprint. I also said that I had done so when I was doing product owning.

      The coach yelled at me that I wasn't allowed to comment on the quality of the Scrum's work or tell them how to do their jobs.

      The main reason that I wanted to review the test cases was to get evidence that I had explained the user stories correctly, and that the stories had been understood by the Scrum. If I found that they were testing the wrong things, then I knew that I hadn't explained the user story well enough.

      Reviewing the test cases seems like an efficient way of doing this, since it doesn't entail the Scrum producing any additional documentation. Instead, I'm looking at a document that they will have to produce anyway.

      To me, one of the fundamentals of Agile is engagement, what the previous poster called consistent connection. Everybody has to engage, including the Product Owner.

      Stepping back, my impression of the problem in product management is that nobody wants to get their hands dirty and do actual analysis. They're all too busy thinking strategically when they should focus on execution with quality.

      Cheers, Jim
    • Charles Bradley - Scrum Coach CSP CSM PSM
      Michael, I don t disagree with you, but I fear that people might interpret unacceptable as meaning We can t do Scrum because having a Proxy PO is
      Message 2 of 24 , Sep 7, 2012
      • 0 Attachment
        Michael,

        I don't disagree with you, but I fear that people might interpret "unacceptable" as meaning "We can't do Scrum because having a Proxy PO is unacceptable."  I don't think this is the right message to send.

        I do agree with identifying a "Proxy PO" as an impediment. 

        I in no way have ever said having a Proxy was good, so I agree with your statement that it is an impediment.  It is just one of many impediments we have in the Scrum world right now, and in my experience, it's not always the the most value impediment that must be worked on at the moment.

        OTOH, for a team that works on multiple products, it is possible that the Scrum PO is not the PdM for all of those products.  Thus, the PO has to act as a Proxy in that way for the other PdM's for those products, no?

         
        -------
        Charles Bradley
        http://www.ScrumCrazy.com




        From: Michael Vizdos <mvizdos@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Thursday, September 6, 2012 6:18 PM
        Subject: Re: [scrumdevelopment] Weakness in Product Management?



        Charles,
        I hear the word proxy being thrown around like that is acceptable for a Product Owner.
        It's not.
        If a Scrum Team does not have the right person in the role of Product Owner (for example a business analyst is a proxy) that is an impediment.
        This is a huge problem today and it's like people accept it.
        It's wrong. So people need to step up and do what is right.
        This is not easy in most places.
        Mike Vizdos
        On Sep 6, 2012 2:41 PM, "Charles Bradley - Scrum Coach CSP CSM PSM I" <chuck-lists2@...> wrote:
         
        Alan,

        I've had some similar experiences to yours, though in recent years on Scrum implementations, I've made it a priority to get as many of the relevant and important PdM folks involved as possible, and as many of the relevant/important users as I can feasibly get my hands on.

        One pattern that I'm noticing is that some Scrum Dev teams try to take on more of PdM responsibilities -- deciding what *they* think is more valuable or should be worked on -- and I don't think that's a good thing long term.  Should they have input?  Oh heck ya, but when they think they know better than the PdM types, that seems to be a bad thing to me.  It seems like some of these dev teams have this view because of the lack of involvement of PdM, or maybe a lack of confidence in the PdM.

        As to who in PdM fits into the PO role, it's very different in every organization it seems.  Sometimes it is a PdM type person, and sometimes it's not a PdM type -- it's a proxy.

        It seems to me that the PO role has two primary sub-categories of responsibility.  One is "business facing", and the other is "Scrum Team facing."
         
        -------
        Charles Bradley
        http://www.ScrumCrazy.com




        From: Alan Dayley <alandd@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Thursday, September 6, 2012 9:43 AM
        Subject: Re: [scrumdevelopment] Weakness in Product Management?



        Charles,

        It is interesting how we have this separation between defining a product and developing that product.  The lean startup ideas are mashing these two areas together.

        In reading your response I realized that I can now better characterize my product management experience.  In my experience, product management sets up the product definition, hands that off to the development team/group/department and then walks away.  The problems come from this lack of consistent connection between product management and product development.  I can't remember how many times I have been a software engineer on a product that has been in development for many months only to have product management suddenly show up and tell us we are building it wrong.

        Interesting discussion.

        Alan

        On Wed, Sep 5, 2012 at 4:55 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
         
        Alan,


        > What has been your experience with good product management?

        I don't think most of my experiences with Product Management(Pdm) are good ones to draw conclusions from in terms of success, because I haven't had very much visibility into the ROI or TCO of a system.  My guess is that many Pdm's also don't have this visibility and that is part of the problem.

        The only examples I can come up with of good Pdm's are people like Bill Gates(assuming he was the effective Pdm at some point) and Steve Jobs. Both of those ended up with wild profits on most of what they did.  I imagine others on this list might come up with reasons why these two shouldn't be considered successful.  Maybe the Instagram Pdm should be considered successful?

        I also witnessed one PO/Pdm who I felt like was really good at understanding what her users really wanted, and was a great communicator with her team.  Unfortunately, she was also a command and control type which meant her team was no longer doing Scrum and was really doing a more traditional c&c type project(there were a lot of other Scrum buts too).  Having said all of that, the products she presided over were very successful in the market, so she and her company must have been doing something right with those.

        What I can speak to is the good habits and successes of Product Owners from the point of view of their interactions with Scrum Development Teams, and how well those teams have produced something that the PO was happy with.  However, PO happiness is not always correlated with true product success.

         
        -------
        Charles Bradley
        http://www.scrumcrazy.com/




        From: Alan Dayley <alandd@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Friday, August 31, 2012 3:50 PM
        Subject: Re: [scrumdevelopment] Weakness in Product Management?



        In my experience weak product management is not a trend.  It is the norm.  It has been the norm for my entire working life.  In fact, in most companies I have seen, just having a part-time Product Owner is a significant improvement over what they had before.  And improvement is true even at companies that have full-time "product managers" before attempting Agile.

        What has been your experience with good product management?

        Alan

        On Thu, Aug 30, 2012 at 12:34 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
         

        I'm starting to see a trend in the industry on this, and I'm curious if others are seeing similar trends.

        Now that we've got the software dev a lot more predictable and transparent, it seems the transparency has shed light on the fact that many Product Managers/Owners(if they really exist) are really unsuccessful at predicting product success(though the blame chain might not stop there).  Further, it seems that many companies do not invest enough in this space (product research, collaborative feedback from users, usability, product visioning, marketing, etc).

        At the Agile2012 conference, Jim Highsmith (one of the AM authors), was highly quoted in his presentation as saying something like this, "[Business]You're not going to measure value?  Fine, we[Dev] won't measure cost, then." 

        I think SW dev has gotten pretty good at measuring cost, but it seems often to me that the business side of the house hasn't gotten any better at measuring value.  It used to be that the business could hide behind the delays, defects, and high cost overruns of the software development department.  In places where Agile software dev is done well, we've fixed those problems, and now the next layer of the onion is turning those costs into a justifiable ROI.

        I've seen possible signs(smells?) of this problem in the following ways:
        • The dev team outstrips the business' ability to come up with new features/products.
        • Shakeups in product management departments due to the missing of forecasted ROI of new features
          • Subpoint: Not building in enough validations in a product to optimize the value of features delivered.
        • Not valuing the product management field enough to hire dedicated Scrum Product Owners and similar personnel
        Obviously all of these could be caused by other things.  I'm not convinced this is a real trend or a real problem.  It's just something I've been pondering lately after witnessing some of the above scenarios and after hearing of Jim's quote.

        -------
        Charles Bradley
        http://www.scrumcrazy.com/
















      • Mark Levison
        James, I m delighted when a product owner is engaged enough to review test cases. I m delighted anytime they engage with the team. However it it s important to
        Message 3 of 24 , Sep 7, 2012
        • 0 Attachment

          James, I'm delighted when a product owner is engaged enough to review test cases. I'm delighted anytime they engage with the team. However it it's important to remember first and foremost they need to be the person with vision. They also need the authority to make decisions about spending budget (ie the teams time). My concern from the way you described the interaction was that the PO sounded like BA with a new title. That really works well.

          Cheers
          Mark Levison writing from my phone at 30,000 ft.

          On Sep 7, 2012 2:05 AM, "jamesjhawkins" <jhawkins@...> wrote:
           

          The following reminded me of a "discussion" I had with a Scrum Coach

          --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...> wrote:
          > In my experience, product management sets
          > up the product definition, hands that off to the development
          > team/group/department and then walks away. The problems come from this
          > lack of consistent connection between product management and product
          > development.

          I said that the Product Owner should review the test cases, during the Sprint. I also said that I had done so when I was doing product owning.

          The coach yelled at me that I wasn't allowed to comment on the quality of the Scrum's work or tell them how to do their jobs.

          The main reason that I wanted to review the test cases was to get evidence that I had explained the user stories correctly, and that the stories had been understood by the Scrum. If I found that they were testing the wrong things, then I knew that I hadn't explained the user story well enough.

          Reviewing the test cases seems like an efficient way of doing this, since it doesn't entail the Scrum producing any additional documentation. Instead, I'm looking at a document that they will have to produce anyway.

          To me, one of the fundamentals of Agile is engagement, what the previous poster called consistent connection. Everybody has to engage, including the Product Owner.

          Stepping back, my impression of the problem in product management is that nobody wants to get their hands dirty and do actual analysis. They're all too busy thinking strategically when they should focus on execution with quality.

          Cheers, Jim

        • Mark Levison
          Too funny, my clever phone auto corrected rarely to really inverting the meaning of I was saying. Cheers Mark
          Message 4 of 24 , Sep 7, 2012
          • 0 Attachment

            Too funny, my clever phone auto corrected rarely to really inverting the meaning of I was saying.

            Cheers
            Mark

            On Sep 8, 2012 12:44 AM, "Mark Levison" <mark@...> wrote:

            James, I'm delighted when a product owner is engaged enough to review test cases. I'm delighted anytime they engage with the team. However it it's important to remember first and foremost they need to be the person with vision. They also need the authority to make decisions about spending budget (ie the teams time). My concern from the way you described the interaction was that the PO sounded like BA with a new title. That really works well.

            Cheers
            Mark Levison writing from my phone at 30,000 ft.

            On Sep 7, 2012 2:05 AM, "jamesjhawkins" <jhawkins@...> wrote:
             

            The following reminded me of a "discussion" I had with a Scrum Coach

            --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...> wrote:
            > In my experience, product management sets
            > up the product definition, hands that off to the development
            > team/group/department and then walks away. The problems come from this
            > lack of consistent connection between product management and product
            > development.

            I said that the Product Owner should review the test cases, during the Sprint. I also said that I had done so when I was doing product owning.

            The coach yelled at me that I wasn't allowed to comment on the quality of the Scrum's work or tell them how to do their jobs.

            The main reason that I wanted to review the test cases was to get evidence that I had explained the user stories correctly, and that the stories had been understood by the Scrum. If I found that they were testing the wrong things, then I knew that I hadn't explained the user story well enough.

            Reviewing the test cases seems like an efficient way of doing this, since it doesn't entail the Scrum producing any additional documentation. Instead, I'm looking at a document that they will have to produce anyway.

            To me, one of the fundamentals of Agile is engagement, what the previous poster called consistent connection. Everybody has to engage, including the Product Owner.

            Stepping back, my impression of the problem in product management is that nobody wants to get their hands dirty and do actual analysis. They're all too busy thinking strategically when they should focus on execution with quality.

            Cheers, Jim

          • Adam Sroka
            I read the whole thing and thought the intent was pretty clear. I didn t notice the accidental contradiction. In fact, the last sentence is great if you take
            Message 5 of 24 , Sep 7, 2012
            • 0 Attachment
              I read the whole thing and thought the intent was pretty clear. I didn't notice the accidental contradiction. In fact, the last sentence is great if you take it sarcastically ;-)

              On Fri, Sep 7, 2012 at 10:15 PM, Mark Levison <mark@...> wrote:
               

              Too funny, my clever phone auto corrected rarely to really inverting the meaning of I was saying.

              Cheers
              Mark

              On Sep 8, 2012 12:44 AM, "Mark Levison" <mark@...> wrote:

              James, I'm delighted when a product owner is engaged enough to review test cases. I'm delighted anytime they engage with the team. However it it's important to remember first and foremost they need to be the person with vision. They also need the authority to make decisions about spending budget (ie the teams time). My concern from the way you described the interaction was that the PO sounded like BA with a new title. That really works well.

              Cheers
              Mark Levison writing from my phone at 30,000 ft.

              On Sep 7, 2012 2:05 AM, "jamesjhawkins" <jhawkins@...> wrote:
               

              The following reminded me of a "discussion" I had with a Scrum Coach

              --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...> wrote:
              > In my experience, product management sets
              > up the product definition, hands that off to the development
              > team/group/department and then walks away. The problems come from this
              > lack of consistent connection between product management and product
              > development.

              I said that the Product Owner should review the test cases, during the Sprint. I also said that I had done so when I was doing product owning.

              The coach yelled at me that I wasn't allowed to comment on the quality of the Scrum's work or tell them how to do their jobs.

              The main reason that I wanted to review the test cases was to get evidence that I had explained the user stories correctly, and that the stories had been understood by the Scrum. If I found that they were testing the wrong things, then I knew that I hadn't explained the user story well enough.

              Reviewing the test cases seems like an efficient way of doing this, since it doesn't entail the Scrum producing any additional documentation. Instead, I'm looking at a document that they will have to produce anyway.

              To me, one of the fundamentals of Agile is engagement, what the previous poster called consistent connection. Everybody has to engage, including the Product Owner.

              Stepping back, my impression of the problem in product management is that nobody wants to get their hands dirty and do actual analysis. They're all too busy thinking strategically when they should focus on execution with quality.

              Cheers, Jim


            • Charles Bradley - Scrum Coach CSP CSM PSM
              Jim, That s an interesting story.  I could imagine a situation where the PO reviewing the test cases could be seen as inappropriately micro-managing the Dev
              Message 6 of 24 , Sep 8, 2012
              • 0 Attachment
                Jim,

                That's an interesting story.  I could imagine a situation where the PO reviewing the test cases could be seen as inappropriately micro-managing the Dev Team, but there would have to be several other factors at play(more context) that you did not mention, so I'll assume those factors didn't exist.  Also, I have seen cases in the past of a PO who has a technical background trying to poke into the "How?", which as we all know, is owned by the Dev Team.

                > evidence that I had explained the user stories correctly,

                My first curiosity question about your situation would be: When you collaborated with the Dev Team, did you and the Dev Team come to a shared understanding as to the Story Tests before development began? 

                My second curiosity question would be: Were you, as the PO, "accepting" stories during the sprint, as soon as the Dev Team thought the story was "Done?"

                -------
                Charles Bradley
                http://www.ScrumCrazy.com




                From: jamesjhawkins <jhawkins@...>
                To: scrumdevelopment@yahoogroups.com
                Sent: Friday, September 7, 2012 2:04 AM
                Subject: [scrumdevelopment] Re: Weakness in Product Management?

                The following reminded me of a "discussion" I had with a Scrum Coach

                --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...> wrote:
                > In my experience, product management sets
                > up the product definition, hands that off to the development
                > team/group/department and then walks away.  The problems come from this
                > lack of consistent connection between product management and product
                > development.

                I said that the Product Owner should review the test cases, during the Sprint. I also said that I had done so when I was doing product owning.

                The coach yelled at me that I wasn't allowed to comment on the quality of the Scrum's work or tell them how to do their jobs.

                The main reason that I wanted to review the test cases was to get evidence that I had explained the user stories correctly, and that the stories had been understood by the Scrum. If I found that they were testing the wrong things, then I knew that I hadn't explained the user story well enough.

                Reviewing the test cases seems like an efficient way of doing this, since it doesn't entail the Scrum producing any additional documentation. Instead, I'm looking at a document that they will have to produce anyway.

                To me, one of the fundamentals of Agile is engagement, what the previous poster called consistent connection. Everybody has to engage, including the Product Owner.

                Stepping back, my impression of the problem in product management is that nobody wants to get their hands dirty and do actual analysis. They're all too busy thinking strategically when they should focus on execution with quality.

                Cheers, Jim



                ------------------------------------

                To Post a message, send it to:  scrumdevelopment@...
                To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                <*> To visit your group on the web, go to:
                    http://groups.yahoo.com/group/scrumdevelopment/

                <*> Your email settings:
                    Individual Email | Traditional

                <*> To change settings online go to:
                    http://groups.yahoo.com/group/scrumdevelopment/join
                    (Yahoo! ID required)

                <*> To change settings via email:
                    scrumdevelopment-digest@yahoogroups.com
                    scrumdevelopment-fullfeatured@yahoogroups.com

                <*> To unsubscribe from this group, send an email to:
                    scrumdevelopment-unsubscribe@yahoogroups.com

                <*> Your use of Yahoo! Groups is subject to:
                    http://docs.yahoo.com/info/terms/



              • Charles Bradley - Scrum Coach CSP CSM PSM
                I m not sure that better governance is the answer, though I guess it depends on how you define governance.  In general, I m for getting rid of almost all
                Message 7 of 24 , Sep 8, 2012
                • 0 Attachment
                  I'm not sure that better governance is the answer, though I guess it depends on how you define governance.  In general, I'm for getting rid of almost all traditional governance(except the parts that help us conform to laws and other outside the company standards that we cannot get away from).

                  There is sometimes a group that is responsible for "green lighting" projects, and that probably still needs to exist to some degree, but that too can be minimized -- because we focus more now on products and features instead of projects, and we have people in the PO business who should be looking at ROI and TCO. 

                  So, at the big picture (for now, we'll call it)project level, there could be improved emphasis on whether to build it or not.  I agree!

                  But, I'm actually just as concerned about the "small picture" -- at the feature/epic/story level.  I think PdM needs to get better at judging ROI and TCO there too.

                  -------
                  Charles Bradley
                  http://www.ScrumCrazy.com




                  From: Steve <steve@...>
                  To: scrumdevelopment@yahoogroups.com
                  Sent: Thursday, September 6, 2012 3:26 AM
                  Subject: [scrumdevelopment] Re: Weakness in Product Management?

                  Hi Charles

                  >>Someone at Agile2012 tweeted something that stuck with me and it continues to bother me some... it was along the lines of "Seems like most [Agile2012] sessions are still about building things right instead of deciding whether the thing is worth building at all."<<

                  I think that this is because nearly all conference seesions focus on the project activities and even though there is plenty of 'business value' talk in all of the frameworks there is little said about governance.

                  My understanding of XP (little) suggests that governance is not needed but someone has to come up with the 'big-picture idea' and have it validated.

                  I spend a lot of time with my clients getting their governance processes aligned with what Agile projects need.

                  Maybe I need to write a paper and get myself on the conference circuit platforms!

                  Governance is the next Agile aspect that we have to crack to reduce your tweeter perceptions.

                  Steve





                  ------------------------------------

                  To Post a message, send it to:  scrumdevelopment@...
                  To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                  <*> To visit your group on the web, go to:
                      http://groups.yahoo.com/group/scrumdevelopment/

                  <*> Your email settings:
                      Individual Email | Traditional

                  <*> To change settings online go to:
                      http://groups.yahoo.com/group/scrumdevelopment/join
                      (Yahoo! ID required)

                  <*> To change settings via email:
                      scrumdevelopment-digest@yahoogroups.com
                      scrumdevelopment-fullfeatured@yahoogroups.com

                  <*> To unsubscribe from this group, send an email to:
                      scrumdevelopment-unsubscribe@yahoogroups.com

                  <*> Your use of Yahoo! Groups is subject to:
                      http://docs.yahoo.com/info/terms/



                • jamesjhawkins
                  Hello Charles, ... [Jim] Personally, I think there should be overlap. Without overlap, how can there be engagement? In other words, I think the PO should be
                  Message 8 of 24 , Sep 10, 2012
                  • 0 Attachment
                    Hello Charles,

                    > I have seen cases in the past of a PO who has a technical background trying to poke into the "How?", which as we all know, is owned by the Dev Team.

                    [Jim] Personally, I think there should be overlap. Without overlap, how can there be engagement?
                    In other words, I think the PO should be allowed to ask how it works because that's a form of engagement.

                    > > evidence that I had explained the user stories correctly,
                    > My first curiosity question about your situation would be: When you collaborated with the Dev Team, did you and the Dev Team come to a shared understanding as to the Story Tests before development began? 
                    [Jim] Here's some background on the project that I'm using as my example.
                    The required product was a port of an existing application to a new platform. None of us knew the details of the new platform with respect to the capabilities that we would need.
                    Every time around the Sprint, we would have Sprint Planning and initial discussion and estimation of the details of the candidate user stories. Then the Scrum coders would start investigating relevant platform capabilities, while the Scrum testers started writing tests.
                    Obliquely, because of the need to do platform capability investigation, the team started doing test-led design. They liked it.
                    I'm not sure if you'd count this as a shared understanding.

                    > My second curiosity question would be: Were you, as the PO, "accepting" stories during the sprint, as soon as the Dev Team thought the story was "Done?"
                    [Jim] That's easier to answer: No. Stories were only ever marked Done at the End-of-Sprint Demo.

                    Cheers, Jim
                  • jamesjhawkins
                    ... This sounds like requirements analysis to me, and I m a big fan. It doesn t seem to be too much different to saying that the requirements analyst should be
                    Message 9 of 24 , Sep 10, 2012
                    • 0 Attachment
                      --- In scrumdevelopment@yahoogroups.com, Mike MacMillan <michael.j.macmillan@...> wrote:
                      >
                      > One thing I've done to curb the issue of weak user stories and poor vision
                      > is hire someone into the Software Engineering team as a full time coach to
                      > the Product Management org. This individual helps groom backlogs, asks
                      > questions that illicit deeper thought on the user experience, and then
                      > assists with getting those visions onto the backlog.

                      This sounds like requirements analysis to me, and I'm a big fan.

                      It doesn't seem to be too much different to saying that the requirements analyst should be the Product Owner though.

                      Cheers, Jim
                    Your message has been successfully submitted and would be delivered to recipients shortly.