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

Re: [scrumdevelopment] A question of what constitutes a valid "feature"

Expand Messages
  • Laurent Bossavit
    Sam, ... Now what well-known software development process, which I m dead sure isn t Scrum, does that remind me of ? ;) I suspect you already know the answer
    Message 1 of 15 , Nov 2, 2005
    • 0 Attachment
      Sam,

      > He says once he gets these documents, he will let the team know his
      > next set of features.

      Now what well-known software development process, which I'm dead sure
      isn't Scrum, does that remind me of ? ;)

      I suspect you already know the answer to your own question. I further
      suspect, but check me if I'm jumping to conclusions, that you're
      looking for a way to steer the conversation with this person back to
      something that respects the spirit of Scrum, not just its letter (and
      that barely).

      Cheers,

      -[Laurent]-
      Divide and Conquer is a very powerful strategy to overcome your.
      enemies. A wise manager will not willingly apply it to his own team.
      Don Wells
    • Sam Edwards
      I m not as wise as you suggest. I actually do NOT know what to say to him. If I say That s not how we do things in the New Millennium , he s going to
      Message 2 of 15 , Nov 2, 2005
      • 0 Attachment

        I’m not as wise as you suggest.  I actually do NOT know what to say to him.  If I say “That’s not how we do things in the New Millennium”, he’s going to complain that as the customer, he should be able to ask for anything at all, and I am not allowed to question his wants.  In fact, that IS what he has been telling me.  Obviously he doesn’t trust this new methodology, and doesn’t feel he has to buy in on it.  What would you say to him?

         

        Sam

         


        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Laurent Bossavit
        Sent: Wednesday, November 02, 2005 11:11 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: Re: [scrumdevelopment] A question of what constitutes a valid "feature"

         

        Sam,

        > He says once he gets these documents, he will let the team know his
        > next set of features.

        Now what well-known software development process, which I'm dead sure
        isn't Scrum, does that remind me of ? ;)

        I suspect you already know the answer to your own question. I further
        suspect, but check me if I'm jumping to conclusions, that you're
        looking for a way to steer the conversation with this person back to
        something that respects the spirit of Scrum, not just its letter (and
        that barely).

        Cheers,

        -[Laurent]-
        Divide and Conquer is a very powerful strategy to overcome your.
        enemies. A wise manager will not willingly apply it to his own team.
        Don Wells



      • Keith Sader
        What Laurent said... You might ask this customer if he/she wants working software in 30/14 days or a ream of paper? You can probably drop by the supply closet
        Message 3 of 15 , Nov 2, 2005
        • 0 Attachment
          What Laurent said...

          You might ask this customer if he/she wants working software in 30/14
          days or a ream of paper? You can probably drop by the supply closet
          and get the first sprint done in a day.

          On 11/2/05, Laurent Bossavit <laurent@...> wrote:
          > Sam,
          >
          > > He says once he gets these documents, he will let the team know his
          > > next set of features.
          >
          > Now what well-known software development process, which I'm dead sure
          > isn't Scrum, does that remind me of ? ;)
          >
          > I suspect you already know the answer to your own question. I further
          > suspect, but check me if I'm jumping to conclusions, that you're
          > looking for a way to steer the conversation with this person back to
          > something that respects the spirit of Scrum, not just its letter (and
          > that barely).



          --
          Keith Sader
          ksader@...
          http://www.saderfamily.org/roller/page/ksader
          http://www.jroller.com/page/certifieddanger
        • Stephen J. Bobick
          ... Sounds like a chicken-and-egg problem to me. How are you going to generate a design and functional specification without the feature list? Try and get
          Message 4 of 15 , Nov 2, 2005
          • 0 Attachment
            >From: Sam Edwards <sedwards@...>
            >We currently have a project whose Product Owner is verytechnical. He is requesting as features the following: an overall design ofthe product, and a functional specification. He says once he gets thesedocuments, he will let the team know his next set of features. Is the customeralways right in this case?

            Sounds like a chicken-and-egg problem to me. How are you going to generate a design and functional specification without the feature list? Try and get this customer to focus on a prioritized feature list, and negotiate the top few to work on. Explain that you *can* generate the requested artifacts for this small set of features - but at the expense of less functioning code. Try and make the case for evolving design, and only incorporate the minimal amount of design needed to implement the first set of highest-priority features.

            -- Stephen
          • Ron Jeffries
            ... Features are running, tested code. Those aren t features. The customer might be right ... but I don t think so, if you re doing Scrum. Ron Jeffries
            Message 5 of 15 , Nov 2, 2005
            • 0 Attachment
              On Wednesday, November 2, 2005, at 10:44:27 AM, Sam Edwards wrote:

              > We currently have a project whose Product Owner is very technical. He
              > is requesting as features the following: an overall design of the
              > product, and a functional specification. He says once he gets these
              > documents, he will let the team know his next set of features. Is the
              > customer always right in this case?

              Features are running, tested code. Those aren't features. The
              customer might be right ... but I don't think so, if you're doing
              Scrum.

              Ron Jeffries
              www.XProgramming.com
              The fact that we know more today, and are more capable today,
              is good news about today, not bad news about yesterday.
            • Ron Jeffries
              ... I m sorry, my team can t help you. Ron Jeffries www.XProgramming.com The central e in Jeffries is silent ... and invisible.
              Message 6 of 15 , Nov 2, 2005
              • 0 Attachment
                On Wednesday, November 2, 2005, at 11:38:48 AM, Sam Edwards wrote:

                > I'm not as wise as you suggest. I actually do NOT know what to say to
                > him. If I say "That's not how we do things in the New Millennium", he's
                > going to complain that as the customer, he should be able to ask for
                > anything at all, and I am not allowed to question his wants. In fact,
                > that IS what he has been telling me. Obviously he doesn't trust this
                > new methodology, and doesn't feel he has to buy in on it. What would
                > you say to him?

                "I'm sorry, my team can't help you."

                Ron Jeffries
                www.XProgramming.com
                The central "e" in "Jeffries" is silent ... and invisible.
              • kane_sfo
                ... As others have suggested, educating the PO is really the long term solution to your problem. I have a feeling that won t solve your short term problem.
                Message 7 of 15 , Nov 3, 2005
                • 0 Attachment
                  --- In scrumdevelopment@yahoogroups.com, "Sam Edwards" <sedwards@c...>
                  wrote:
                  >
                  > We currently have a project whose Product Owner is very technical. He
                  > is requesting as features the following: an overall design of the
                  > product, and a functional specification. He says once he gets these
                  > documents, he will let the team know his next set of features. Is the
                  > customer always right in this case?

                  As others have suggested, educating the PO is really the long term
                  solution to your problem. I have a feeling that won't solve your short
                  term problem.

                  What I might suggest is to make the PO entirely responsible for the
                  budget *and* for him to have to defend it. Then explain to the PO that
                  every dollar spent on defining the overall design and func spec, is a
                  dollar not spent on delivering code, and hence a dollar wasted.

                  Hope that helps,
                  Kane Mar
                  --------
                  U: http://www.danube.com/
                  E: Kane at Danube dot com

                  ps. Mary Poppendieck's book (Lean Software Development) elequently
                  argues that anything that doesn't add value is waste. It's a good
                  reference if you're preparing for a debate.
                • Hubert Smits
                  Hi Sam, I don t know your product owner, most are human though and may respond to requests like: - Okay, I ll do your design, can you help me compose a list of
                  Message 8 of 15 , Nov 6, 2005
                  • 0 Attachment
                    Hi Sam,

                    I don't know your product owner, most are human though and may respond to requests like:

                    - Okay, I'll do your design, can you help me compose a list of features?
                    - Man! Big features you specify here, how do you envisage a customer uses this?
                    - To write your spec I'd like to understand better how this product works, can you draw it on the board for me?
                    - If I understand you right you want <this> for the customer. Can you elaborate on <this>.
                    - Etc.

                    In other words, don't dismiss the request for a spec, you can work out later what that looks like. Draw him to the thinking process, to the discussion. Once you have an understanding of some features, propose to build a prototype or a model, or just do it. Show him (must be a man, women are much smarter :-) ) that it actually works to build working software in small increments. And don't try to win all battles at once, if you have to write a spec for the first release then so be it. Pick your battles carefully.

                    --Hubert

                    On 11/2/05, Sam Edwards <sedwards@...> wrote:

                    We currently have a project whose Product Owner is very technical.  He is requesting as features the following: an overall design of the product, and a functional specification.  He says once he gets these documents, he will let the team know his next set of features.  Is the customer always right in this case?

                     

                     



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




                    SPONSORED LINKS
                    Scrum


                    YAHOO! GROUPS LINKS




                  • Jim Hyslop
                    ... Hash: SHA1 ... Who decided to adopt Scrum for this project? To me it sounds like your PO may have been forced, against his will, to use Scrum instead the
                    Message 9 of 15 , Nov 6, 2005
                    • 0 Attachment
                      -----BEGIN PGP SIGNED MESSAGE-----
                      Hash: SHA1

                      Sam Edwards wrote:
                      > We currently have a project whose Product Owner is very technical. He
                      > is requesting as features the following: an overall design of the
                      > product, and a functional specification. He says once he gets these
                      > documents, he will let the team know his next set of features. Is the
                      > customer always right in this case?

                      Who decided to adopt Scrum for this project? To me it sounds like your
                      PO may have been forced, against his will, to use Scrum instead the
                      waterfall methods he's accustomed to. If that's the case, you'll have to
                      find a way to overcome his objections and help him feel comfortable with
                      the process.

                      - --
                      Jim Hyslop
                      Dreampossible: Better software. Simply. http://www.dreampossible.ca
                      Consulting * Mentoring * Training in
                      C/C++ * OOD * SW Development & Practices * Version Management
                      -----BEGIN PGP SIGNATURE-----
                      Version: GnuPG v1.4.2 (MingW32)
                      Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

                      iD8DBQFDbqWsLdDyDwyJw+MRAvdMAJ4gNu5NBByPBKH5fRzscdeTxKM84ACeNazh
                      aDxoxG96Y5luSbYuMLYXG1w=
                      =+jVO
                      -----END PGP SIGNATURE-----
                    • Dave Bly
                      Sam, I would suggest you put together a presentation that shows him how agile is for his benefit more than anyone s: earlier delivery of usable software,
                      Message 10 of 15 , Nov 6, 2005
                      • 0 Attachment

                        Sam,

                         

                        I would suggest you put together a presentation that shows him how agile is for his benefit more than anyone’s: earlier delivery of usable software, flexibility in accommodating change as the solution becomes more clear, etc.  Then, having done your best to show him that you are only trying to help him be successful with these techniques, that you would be happy to take longer and cost more if that’s what he really wants.

                         

                        Dave

                         

                         


                        From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Sam Edwards
                        Sent: Wednesday, November 02, 2005 11:39 AM
                        To: scrumdevelopment@yahoogroups.com
                        Subject: RE: [scrumdevelopment] A question of what constitutes a valid "feature"

                         

                        I’m not as wise as you suggest.  I actually do NOT know what to say to him.  If I say “That’s not how we do things in the New Millennium”, he’s going to complain that as the customer, he should be able to ask for anything at all, and I am not allowed to question his wants.  In fact, that IS what he has been telling me.  Obviously he doesn’t trust this new methodology, and doesn’t feel he has to buy in on it.  What would you say to him?

                         

                        Sam

                         


                        From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Laurent Bossavit
                        Sent: Wednesday, November 02, 2005 11:11 AM
                        To: scrumdevelopment@yahoogroups.com
                        Subject: Re: [scrumdevelopment] A question of what constitutes a valid "feature"

                         

                        Sam,

                        > He says once he gets these documents, he will let the team know his
                        > next set of features.

                        Now what well-known software development process, which I'm dead sure
                        isn't Scrum, does that remind me of ? ;)

                        I suspect you already know the answer to your own question. I further
                        suspect, but check me if I'm jumping to conclusions, that you're
                        looking for a way to steer the conversation with this person back to
                        something that respects the spirit of Scrum, not just its letter (and
                        that barely).

                        Cheers,

                        -[Laurent]-
                        Divide and Conquer is a very powerful strategy to overcome your.
                        enemies. A wise manager will not willingly apply it to his own team.
                        Don Wells




                      • Jef Newsom
                        I wonder whether it is the project or the product owner that is new. I had originally interpreted Sam s note to suggest that the Product Owner wanted
                        Message 11 of 15 , Nov 7, 2005
                        • 0 Attachment

                          I wonder whether it is the project or the product owner that is new. I had originally interpreted Sam’s note to suggest that the Product Owner wanted design/functional spec for an existing product rather than a from-scratch project. Is it an existing product? Is the product owner new to the product?

                           

                          I completely agree with Hubert’s notion of humanity – I don’t think you want to show your product owner disrespect, and if he insists on receiving the information, then you might earn a little trust by giving him what he wants. Then help him understand your concerns about whether it adds [business] value or not. Time box the effort and deliver the best design/functional spec that your team can in an (hour | day | week | …).

                           

                          -- Jef


                          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Hubert Smits
                          Sent: Sunday, November 06, 2005 10:29 AM
                          To: scrumdevelopment@yahoogroups.com
                          Subject: Re: [scrumdevelopment] A question of what constitutes a valid "feature"

                           

                          Hi Sam,

                          I don't know your product owner, most are human though and may respond to requests like:

                          - Okay, I'll do your design, can you help me compose a list of features?
                          - Man! Big features you specify here, how do you envisage a customer uses this?
                          - To write your spec I'd like to understand better how this product works, can you draw it on the board for me?
                          - If I understand you right you want <this> for the customer. Can you elaborate on <this>.
                          - Etc.

                          In other words, don't dismiss the request for a spec, you can work out later what that looks like. Draw him to the thinking process, to the discussion. Once you have an understanding of some features, propose to build a prototype or a model, or just do it. Show him (must be a man, women are much smarter :-) ) that it actually works to build working software in small increments. And don't try to win all battles at once, if you have to write a spec for the first release then so be it. Pick your battles carefully.

                          --Hubert

                          On 11/2/05 , Sam Edwards <sedwards@...> wrote:

                          We currently have a project whose Product Owner is very technical.  He is requesting as features the following: an overall design of the product, and a functional specification.  He says once he gets these documents, he will let the team know his next set of features.  Is the customer always right in this case?

                           

                           



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


                          SPONSORED LINKS

                          Scrum

                           


                          YAHOO! GROUPS LINKS

                           

                           





                        • Sam Edwards
                          Excellent advice, Hubert. Thanks for taking the time to respond to my concerns. Sam _____ From: scrumdevelopment@yahoogroups.com
                          Message 12 of 15 , Nov 7, 2005
                          • 0 Attachment

                            Excellent advice, Hubert.  Thanks for taking the time to respond to my concerns. 

                             

                            Sam

                             


                            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Hubert Smits
                            Sent: Sunday, November 06, 2005 8:29 AM
                            To: scrumdevelopment@yahoogroups.com
                            Subject: Re: [scrumdevelopment] A question of what constitutes a valid "feature"

                             

                            Hi Sam,

                            I don't know your product owner, most are human though and may respond to requests like:

                            - Okay, I'll do your design, can you help me compose a list of features?
                            - Man! Big features you specify here, how do you envisage a customer uses this?
                            - To write your spec I'd like to understand better how this product works, can you draw it on the board for me?
                            - If I understand you right you want <this> for the customer. Can you elaborate on <this>.
                            - Etc.

                            In other words, don't dismiss the request for a spec, you can work out later what that looks like. Draw him to the thinking process, to the discussion. Once you have an understanding of some features, propose to build a prototype or a model, or just do it. Show him (must be a man, women are much smarter :-) ) that it actually works to build working software in small increments. And don't try to win all battles at once, if you have to write a spec for the first release then so be it. Pick your battles carefully.

                            --Hubert

                            On 11/2/05, Sam Edwards <sedwards@...> wrote:

                            We currently have a project whose Product Owner is very technical.  He is requesting as features the following: an overall design of the product, and a functional specification.  He says once he gets these documents, he will let the team know his next set of features.  Is the customer always right in this case?

                             

                             



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



                            SPONSORED LINKS

                            Scrum

                             


                            YAHOO! GROUPS LINKS

                             

                             




                          • Dymond, Robin
                            Sam, You are experiencing a classic behavior. People know how to do things a certain way, asking them to change pushes them out of their comfort zone. The
                            Message 13 of 15 , Nov 7, 2005
                            • 0 Attachment
                              Message
                              Sam,
                               
                              You are experiencing a classic behavior. People "know" how to do things a certain way, asking them to change pushes them out of their comfort zone. The curious, feeling uncomfortable, will start to ask questions to learn their way back to familiarity. Others will react defensively and try to "get back" to what they know. Asking for a requirements document and design specification is exactly this defensive behavior.
                               
                              I suggest you read Cohn's "user stories applied", (a fast read), and use your first iteration (iteration 0) to determine the business requirements in this format. This will give you a framework for defining the features in the product backlog. You can tell your customer that Agile requirements are user stories, show them some examples, and involve them in writing the stories.
                               
                              Another question: Do you have the actual business customer, or a "proxy" customer? You need someone who understands the business needs first and foremost.
                               
                              Hubert's suggestions are great. Use the mechanics of writing user stories to move your customer away from the waterfall method's intermediate work products and towards asking for tangible software features.
                               
                              cheers,
                              Robin Dymond
                              Agile Coach
                              -----Original Message-----
                              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Sam Edwards
                              Sent: Monday, November 07, 2005 2:17 PM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: RE: [scrumdevelopment] A question of what constitutes a valid "feature"

                              Excellent advice, Hubert.  Thanks for taking the time to respond to my concerns. 

                               

                              Sam

                               


                              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Hubert Smits
                              Sent: Sunday, November 06, 2005 8:29 AM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: Re: [scrumdevelopment] A question of what constitutes a valid "feature"

                               

                              Hi Sam,

                              I don't know your product owner, most are human though and may respond to requests like:

                              - Okay, I'll do your design, can you help me compose a list of features?
                              - Man! Big features you specify here, how do you envisage a customer uses this?
                              - To write your spec I'd like to understand better how this product works, can you draw it on the board for me?
                              - If I understand you right you want <this> for the customer. Can you elaborate on <this>.
                              - Etc.

                              In other words, don't dismiss the request for a spec, you can work out later what that looks like. Draw him to the thinking process, to the discussion. Once you have an understanding of some features, propose to build a prototype or a model, or just do it. Show him (must be a man, women are much smarter :-) ) that it actually works to build working software in small increments. And don't try to win all battles at once, if you have to write a spec for the first release then so be it. Pick your battles carefully.

                              --Hubert

                              On 11/2/05, Sam Edwards <sedwards@...> wrote:

                              We currently have a project whose Product Owner is very technical.  He is requesting as features the following: an overall design of the product, and a functional specification.  He says once he gets these documents, he will let the team know his next set of features.  Is the customer always right in this case?

                               

                               



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



                              SPONSORED LINKS

                              Scrum

                               


                              YAHOO! GROUPS LINKS

                               

                               




                            • Sam Edwards
                              Thanks, Robin. I just order Cohn s book. I like your idea of getting the user involved in writing the stories - it s a nice way to break some habits and move
                              Message 14 of 15 , Nov 7, 2005
                              • 0 Attachment
                                Message

                                Thanks, Robin.  I just order Cohn’s book.  I like your idea of getting the user involved in writing the stories – it’s a nice way to break some habits and move into a new way of looking at things.

                                 

                                Sam

                                 


                                From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Dymond, Robin
                                Sent: Monday, November 07, 2005 1:03 PM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: RE: [scrumdevelopment] A question of what constitutes a valid "feature"

                                 

                                Sam,

                                 

                                You are experiencing a classic behavior. People "know" how to do things a certain way, asking them to change pushes them out of their comfort zone. The curious, feeling uncomfortable, will start to ask questions to learn their way back to familiarity. Others will react defensively and try to "get back" to what they know. Asking for a requirements document and design specification is exactly this defensive behavior.

                                 

                                I suggest you read Cohn's "user stories applied", (a fast read), and use your first iteration (iteration 0) to determine the business requirements in this format. This will give you a framework for defining the features in the product backlog. You can tell your customer that Agile requirements are user stories, show them some examples, and involve them in writing the stories.

                                 

                                Another question: Do you have the actual business customer, or a "proxy" customer? You need someone who understands the business needs first and foremost.

                                 

                                Hubert's suggestions are great. Use the mechanics of writing user stories to move your customer away from the waterfall method's intermediate work products and towards asking for tangible software features.

                                 

                                cheers,

                                Robin Dymond

                                Agile Coach

                                -----Original Message-----
                                From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Sam Edwards
                                Sent: Monday, November 07, 2005 2:17 PM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: RE: [scrumdevelopment] A question of what constitutes a valid "feature"

                                Excellent advice, Hubert.  Thanks for taking the time to respond to my concerns. 

                                 

                                Sam

                                 


                                From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Hubert Smits
                                Sent: Sunday, November 06, 2005 8:29 AM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: Re: [scrumdevelopment] A question of what constitutes a valid "feature"

                                 

                                Hi Sam,

                                I don't know your product owner, most are human though and may respond to requests like:

                                - Okay, I'll do your design, can you help me compose a list of features?
                                - Man! Big features you specify here, how do you envisage a customer uses this?
                                - To write your spec I'd like to understand better how this product works, can you draw it on the board for me?
                                - If I understand you right you want <this> for the customer. Can you elaborate on <this>.
                                - Etc.

                                In other words, don't dismiss the request for a spec, you can work out later what that looks like. Draw him to the thinking process, to the discussion. Once you have an understanding of some features, propose to build a prototype or a model, or just do it. Show him (must be a man, women are much smarter :-) ) that it actually works to build working software in small increments. And don't try to win all battles at once, if you have to write a spec for the first release then so be it. Pick your battles carefully.

                                --Hubert

                                On 11/2/05, Sam Edwards <sedwards@...> wrote:

                                We currently have a project whose Product Owner is very technical.  He is requesting as features the following: an overall design of the product, and a functional specification.  He says once he gets these documents, he will let the team know his next set of features.  Is the customer always right in this case?

                                 

                                 



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


                                SPONSORED LINKS

                                Scrum

                                 


                                YAHOO! GROUPS LINKS

                                 

                                 


                                 


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