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

Scrum Team and the Team

Expand Messages
  • john.zayd
    Team members are the engineers who are building the software, writing the code. What about QA? If the software is the team responsibility, then QA should be
    Message 1 of 27 , Nov 30, 2009
    • 0 Attachment
      Team members are the engineers who are building the software, writing the code. What about QA? If the software is the team responsibility, then QA should be on the product owner side! What if we are building an in-house product, that is the Product Owner have the responsibilities to provide GUI mockups, and also work on some features such as website, brochure etc: can these be an items in the backlog? If so, some of them, at least the GUI mockups will be mixed with other items/stories, in that case, well the product owner team share the team in estimating the backlog items (story points) for these items? Since it's part of what DONE means for this specific tasks / item. Product owner are pigs also, and can speak in the standup meeting right? Will they report their work progress answering the three questions? Will they pay the $1 if they are late?
    • Roy Morien
      WHat exactly are you calling QA? I don t really agree with your assertion that the Product Owner has responsibility to provide GUI mockups etc. What is late
      Message 2 of 27 , Nov 30, 2009
      • 0 Attachment
        WHat exactly are you calling QA?
         
        I don't really agree with your assertion that the Product Owner has responsibility to provide GUI mockups etc.
         
        What is 'late' in your discussion?
         
        This sounds very much like you are not seeing the basic concepts of collaboration, adaptation and openness. These all sound like questions about how to apply traditional concepts and practices to Scrum, not how to do it the Scrum way.
         
        Regards,
        Roy Morien
         

        To: scrumdevelopment@yahoogroups.com
        From: john.zayd@...
        Date: Mon, 30 Nov 2009 09:11:04 +0000
        Subject: [scrumdevelopment] Scrum Team and the Team

         
        Team members are the engineers who are building the software, writing the code. What about QA? If the software is the team responsibility, then QA should be on the product owner side! What if we are building an in-house product, that is the Product Owner have the responsibilities to provide GUI mockups, and also work on some features such as website, brochure etc: can these be an items in the backlog? If so, some of them, at least the GUI mockups will be mixed with other items/stories, in that case, well the product owner team share the team in estimating the backlog items (story points) for these items? Since it's part of what DONE means for this specific tasks / item. Product owner are pigs also, and can speak in the standup meeting right? Will they report their work progress answering the three questions? Will they pay the $1 if they are late?




        Brought to you exclusively by Windows Live Download new and classic emoticon packs at Emoticon World
      • john.zayd
        Quality Assurance engineers: test and validate each feature after being completed during the sprint. Product owner need to present the GUI mockups to an
        Message 3 of 27 , Nov 30, 2009
        • 0 Attachment
          Quality Assurance engineers: test and validate each feature after being completed during the sprint.
          Product owner need to present the GUI mockups to an internal user group for evaluation - they also sometimes work with external agencies for improving UX. This is done before filling the backlog items? Is that wrong? Why you disagree with this?
          Well I see the concept of collaboration, but scrum it self divided the roles between the three.

          --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:
          >
          >
          > WHat exactly are you calling QA?
          >
          >
          >
          > I don't really agree with your assertion that the Product Owner has responsibility to provide GUI mockups etc.
          >
          >
          >
          > What is 'late' in your discussion?
          >
          >
          >
          > This sounds very much like you are not seeing the basic concepts of collaboration, adaptation and openness. These all sound like questions about how to apply traditional concepts and practices to Scrum, not how to do it the Scrum way.
          >
          >
          >
          > Regards,
          >
          > Roy Morien
          >
          >
          >
          > To: scrumdevelopment@yahoogroups.com
          > From: john.zayd@...
          > Date: Mon, 30 Nov 2009 09:11:04 +0000
          > Subject: [scrumdevelopment] Scrum Team and the Team
          >
          >
          >
          >
          >
          > Team members are the engineers who are building the software, writing the code. What about QA? If the software is the team responsibility, then QA should be on the product owner side! What if we are building an in-house product, that is the Product Owner have the responsibilities to provide GUI mockups, and also work on some features such as website, brochure etc: can these be an items in the backlog? If so, some of them, at least the GUI mockups will be mixed with other items/stories, in that case, well the product owner team share the team in estimating the backlog items (story points) for these items? Since it's part of what DONE means for this specific tasks / item. Product owner are pigs also, and can speak in the standup meeting right? Will they report their work progress answering the three questions? Will they pay the $1 if they are late?
          >
          >
          >
          >
          >
          > _________________________________________________________________
          > Download new and classic emoticon packs at Emoticon World Brought to you exclusively by Windows Live
          > http://windowslive.ninemsn.com.au/emoticon.aspx?
          >
        • Roy Morien
          Yes, Scrum divides the roles of Product Owner and Scrum Master and The Team ... there is no QA role. QA is considered to be part of The Team s
          Message 4 of 27 , Nov 30, 2009
          • 0 Attachment
            Yes, Scrum divides the roles of Product Owner and Scrum Master and The Team ... there is no QA role. QA is considered to be part of The Team's responsibilities, to deliver code that is DONE, which includes QA. Your definition of Quality Assurance engineers; "test and validate each feature after being completed during a sprint" is a contradiction in Scrum. The 'test and validate' is an essential part of the sprint activity, and if it is not done during the sprint, then the feature cannot be said to be completed.
             
            Any role for QA engineers MAY be to audit and verify the system on behalf of users, but this should be done on features that the developers have already rigorously tested and "QA'd". This is an 'end-of-line' activity, which may well be totally unnecessary if the 'in-line' QA has been done properly.
             
            In brief, my point is that quality should be built-in as part of the development of the features, during the sprint. Therefore, perfectly, there is no role at all for QA engineers; that "test and validate each feature after being completed during the sprint" is entirely redundant.
             
            As for Product Owners presenting GUI mockups, well, I don't think that is their role at all. The PO is responsible for assisting in gathering User Stories and maintaining the Product Backlog. The PO is not responsible for design issues, such as what the GUI will look like. My immediate thought on reading your first email was "GUI mockups would be part of an up-front requirements and design specification" which is just not a part of the Scrum development thinking or practice, but which is very much traditional roject management thinking. When a User Story comes up for consideration to be included in a Sprint, then the dvelopers, in collaboration with appropriate users, would sit down to detail the GUI design (presumably in terms of pre-existing standards). This is the 'just-in-time' philosophy.
             
            As well, from my perspetive, having used development tools for 30 years, I would suggest that it is a waste of time to have 'GUI mockups'. Using appropriate UI design tools, the so-called mockup is probably, or can probably be, the production level design. What did you have in mind as being a mockup, that would not be done with one of the many 'drag-and-drop' WYSIWYG style screen design tools?
             
            Regards,
            Roy Morien 
             

            To: scrumdevelopment@yahoogroups.com
            From: john.zayd@...
            Date: Mon, 30 Nov 2009 10:27:04 +0000
            Subject: [scrumdevelopment] Re: Scrum Team and the Team

             
            Quality Assurance engineers: test and validate each feature after being completed during the sprint.
            Product owner need to present the GUI mockups to an internal user group for evaluation - they also sometimes work with external agencies for improving UX. This is done before filling the backlog items? Is that wrong? Why you disagree with this?
            Well I see the concept of collaboration, but scrum it self divided the roles between the three.

            --- In scrumdevelopment@ yahoogroups. com, Roy Morien <roymorien@. ..> wrote:
            >
            >
            > WHat exactly are you calling QA?
            >
            >
            >
            > I don't really agree with your assertion that the Product Owner has responsibility to provide GUI mockups etc.
            >
            >
            >
            > What is 'late' in your discussion?
            >
            >
            >
            > This sounds very much like you are not seeing the basic concepts of collaboration, adaptation and openness. These all sound like questions about how to apply traditional concepts and practices to Scrum, not how to do it the Scrum way.
            >
            >
            >
            > Regards,
            >
            > Roy Morien
            >
            >
            >
            > To: scrumdevelopment@ yahoogroups. com
            > From: john.zayd@.. .
            > Date: Mon, 30 Nov 2009 09:11:04 +0000
            > Subject: [scrumdevelopment] Scrum Team and the Team
            >
            >
            >
            >
            >
            > Team members are the engineers who are building the software, writing the code. What about QA? If the software is the team responsibility, then QA should be on the product owner side! What if we are building an in-house product, that is the Product Owner have the responsibilities to provide GUI mockups, and also work on some features such as website, brochure etc: can these be an items in the backlog? If so, some of them, at least the GUI mockups will be mixed with other items/stories, in that case, well the product owner team share the team in estimating the backlog items (story points) for these items? Since it's part of what DONE means for this specific tasks / item. Product owner are pigs also, and can speak in the standup meeting right? Will they report their work progress answering the three questions? Will they pay the $1 if they are late?
            >
            >
            >
            >
            >
            > ____________ _________ _________ _________ _________ _________ _
            > Download new and classic emoticon packs at Emoticon World Brought to you exclusively by Windows Live
            > http://windowslive. ninemsn.com. au/emoticon. aspx?
            >




            With all the lastest places, searching has never been easier. Look now! Looking to move this spring?
          • Maurice le Rutte
              Roy Morien schreef: In brief, my point is that quality should be built-in as part of the development of the features, during the sprint. Therefore,
            Message 5 of 27 , Nov 30, 2009
            • 0 Attachment
               Roy Morien schreef:

              In brief, my point is that quality should be built-in as part of the development of the features, during the sprint. Therefore, perfectly, there is no role at all for QA engineers; that "test and validate each feature after being completed during the sprint" is entirely redundant.
               
              As for Product Owners presenting GUI mockups, well, I don't think that is their role at all. The PO is responsible for assisting in gathering User Stories and maintaining the Product Backlog. The PO is not responsible for design issues, such as what the GUI will look like. My immediate thought on reading your first email was "GUI mockups would be part of an up-front requirements and design specification" which is just not a part of the Scrum development thinking or practice, but which is very much traditional roject management thinking. When a User Story comes up for consideration to be included in a Sprint, then the dvelopers, in collaboration with appropriate users, would sit down to detail the GUI design (presumably in terms of pre-existing standards). This is the 'just-in-time' philosophy.
               
              As well, from my perspetive, having used development tools for 30 years, I would suggest that it is a waste of time to have 'GUI mockups'. Using appropriate UI design tools, the so-called mockup is probably, or can probably be, the production level design. What did you have in mind as being a mockup, that would not be done with one of the many 'drag-and-drop' WYSIWYG style screen design tools?



              -- 
              http://twitter.com/scrumnl
            • Roy Morien
              I do appreciate short responses to my emails, but this is ... a little too short. To: scrumdevelopment@yahoogroups.com From: maurice.lerutte@scrummaster.nl
              Message 6 of 27 , Nov 30, 2009
              • 0 Attachment
                I do appreciate short responses to my emails, but this is ... a little too short.
                 

                To: scrumdevelopment@yahoogroups.com
                From: maurice.lerutte@...
                Date: Mon, 30 Nov 2009 12:02:27 +0100
                Subject: Re: [scrumdevelopment] Re: Scrum Team and the Team

                 
                 Roy Morien schreef:

                In brief, my point is that quality should be built-in as part of the development of the features, during the sprint. Therefore, perfectly, there is no role at all for QA engineers; that "test and validate each feature after being completed during the sprint" is entirely redundant.
                 
                As for Product Owners presenting GUI mockups, well, I don't think that is their role at all. The PO is responsible for assisting in gathering User Stories and maintaining the Product Backlog. The PO is not responsible for design issues, such as what the GUI will look like. My immediate thought on reading your first email was "GUI mockups would be part of an up-front requirement s and design specification" which is just not a part of the Scrum development thinking or practice, but which is very much traditional roject management thinking. When a User Story comes up for consideration to be included in a Sprint, then the dvelopers, in collaboration with appropriate users, would sit down to detail the GUI design (presumably in terms of pre-existing standards). This is the 'just-in-time' philosophy.
                 
                As well, from my perspetive, having used development tools for 30 years, I would suggest that it is a waste of time to have 'GUI mockups'. Using appropriate UI design tools, the so-called mockup is probably, or can probably be, the production level design. What did you have in mind as being a mockup, that would not be done with one of the many 'drag-and-drop' WYSIWYG style screen design tools?



                -- 
                http://twitter. com/scrumnl



                View photos of singles in your area! Looking for a date?
              • Maurice le Rutte
                Attempt 2 :-) I was wondering what would you advise in a situation where you have a company creating physical products where software is only a small part of.
                Message 7 of 27 , Nov 30, 2009
                • 0 Attachment
                  Attempt 2 :-)

                  I was wondering what would you advise in a situation where you have a company creating physical products where software is only a small part of. You need to have a consistant behaviour amongst several products and the user must like the way the product works - not limited to the software only and must find it aesthetically pleasing.

                  Those people who studied that area of industrial design need to make sure that across the entire company and projects the same decisions are made and they can't go around changing their mind everytime. Neither can they just come up with an idea the first day of a sprint, they have to be sure it fits in the entire product range.

                  You will quickly end up with pre-sprint requirements/mock-ups/... at least, I did.

                  Maurice.

                  Roy Morien schreef:
                   

                  I do appreciate short responses to my emails, but this is ... a little too short.
                   


                  To: scrumdevelopment@ yahoogroups. com
                  From: maurice.lerutte@ scrummaster. nl
                  Date: Mon, 30 Nov 2009 12:02:27 +0100
                  Subject: Re: [scrumdevelopment] Re: Scrum Team and the Team

                   
                   Roy Morien schreef:

                  In brief, my point is that quality should be built-in as part of the development of the features, during the sprint. Therefore, perfectly, there is no role at all for QA engineers; that "test and validate each feature after being completed during the sprint" is entirely redundant.
                   
                  As for Product Owners presenting GUI mockups, well, I don't think that is their role at all. The PO is responsible for assisting in gathering User Stories and maintaining the Product Backlog. The PO is not responsible for design issues, such as what the GUI will look like. My immediate thought on reading your first email was "GUI mockups would be part of an up-front requirement s and design specification" which is just not a part of the Scrum development thinking or practice, but which is very much traditional roject management thinking. When a User Story comes up for consideration to be included in a Sprint, then the dvelopers, in collaboration with appropriate users, would sit down to detail the GUI design (presumably in terms of pre-existing standards). This is the 'just-in-time' philosophy.
                   
                  As well, from my perspetive, having used development tools for 30 years, I would suggest that it is a waste of time to have 'GUI mockups'. Using appropriate UI design tools, the so-called mockup is probably, or can probably be, the production level design. What did you have in mind as being a mockup, that would not be done with one of the many 'drag-and-drop' WYSIWYG style screen design tools?



                  -- 
                  http://twitter. com/scrumnl



                  -- 
                  http://twitter.com/scrumnl
                • Sarath Kummamuru
                  Hi John, Please see my inputs inline. thanks. Sarath. ... assure to the PO that the product has quality and so i would see them as part of the team. While i do
                  Message 8 of 27 , Nov 30, 2009
                  • 0 Attachment
                    Hi John,
                        Please see my inputs inline.


                    thanks.
                    Sarath.

                    On Mon, Nov 30, 2009 at 2:41 PM, john.zayd <john.zayd@...> wrote:
                     

                    Team members are the engineers who are building the software, writing the code. What about QA?

                    >>>> When you mean QA what do you mean? It is the team's responsibility to assure to the PO that the product has quality and so i would see them as part of the team.
                              While i do not think we should have a UAT, some of my customers who use the services of our agile team, do have some team members who help the PO from a UAT perspective. But mostly they also work closely with our team members in defining Acceptance criteria, participating in testing of the builds during and at the end of the sprint.
                     

                    If the software is the team responsibility, then QA should be on the product owner side!

                    >>>> I some how seem to feel that you are referring to the UAT, but my answer is already above. 

                    What if we are building an in-house product, that is the Product Owner have the responsibilities to provide GUI mockups,

                    >>>> This is a very common situation with many organizations that I coach. But in my opinion the PO is not responsible for the GUI mockups. The PO should be able to articulate the requirements and the vision of the product and leave it to the team to build the UI. Many cases that I have seen the teams moving into agile typically donot have these skills and normally wait for the design team to complete the mockups before the feature is started.

                    This is not right and I have always said that the design teams should mentor the dev and test teams on the design patterns and standards used in the org and should hand hold them initially but enable the teams to do the mockups by themselves over a period of time without compromising design standards.

                    and also work on some features such as website, brochure etc: can these be an items in the backlog? If so, some of them, at least the GUI mockups will be mixed with other items/stories, in that case, well the product owner team share the team in estimating the backlog items (story points) for these items?

                    >>>>  The PO will not have any owner ship on estimating the back log items. 

                    Since it's part of what DONE means for this specific tasks / item. Product owner are pigs also, and can speak in the standup meeting right? Will they report their work progress answering the three questions? Will they pay the $1 if they are late? 




                    --
                    Thanks,
                    Sarath.

                    Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335 0221 | www.quadone.com
                  • Sarath Kummamuru
                    Hi Maurice, I do agree with your thought that there should be a consistent behavior and design pattern across several products or even different areas of the
                    Message 9 of 27 , Nov 30, 2009
                    • 0 Attachment
                      Hi Maurice,
                          I do agree with your thought that there should be a consistent behavior and design pattern across several products or even different areas of the same product.

                          This is not only true of industrial design but also of software. Obviously you would not like software with some patterns in one place and a different ui pattern some where else.

                          This is normally been the responsibility of the design teams and over time atleast these patterns have not been communicated well enough to enable the TEAM to actually work within these design patterns. This is the reason esp in software products we still see the heavy dependence on UI designers (who are very loaded) having to do all the UI mockups before the team can pick them up.

                          With teams that I coach I do emphasize that UI responsibility should be with the team an they are constrained to some extent with the org wide ui design patterns and the definition of done should include some reference to this if required.

                           My experience has been that teams get to learn pretty quickly when they have to and this has been one of my eureka moments with some teams where the teams took complete ownership on the UI and the design teams started looking at improving existing design patterns and experimenting with new stuff.

                      Thanks,
                      Sarath.

                      On Mon, Nov 30, 2009 at 4:44 PM, Maurice le Rutte <maurice.lerutte@...> wrote:
                       

                      Attempt 2 :-)

                      I was wondering what would you advise in a situation where you have a company creating physical products where software is only a small part of. You need to have a consistant behaviour amongst several products and the user must like the way the product works - not limited to the software only and must find it aesthetically pleasing.

                      Those people who studied that area of industrial design need to make sure that across the entire company and projects the same decisions are made and they can't go around changing their mind everytime. Neither can they just come up with an idea the first day of a sprint, they have to be sure it fits in the entire product range.

                      You will quickly end up with pre-sprint requirements/mock-ups/... at least, I did.

                      Maurice.

                      Roy Morien schreef:

                       

                      I do appreciate short responses to my emails, but this is ... a little too short.
                       


                      To: scrumdevelopment@yahoogroups.com
                      From: maurice.lerutte@...
                      Date: Mon, 30 Nov 2009 12:02:27 +0100
                      Subject: Re: [scrumdevelopment] Re: Scrum Team and the Team

                       
                       Roy Morien schreef:

                      In brief, my point is that quality should be built-in as part of the development of the features, during the sprint. Therefore, perfectly, there is no role at all for QA engineers; that "test and validate each feature after being completed during the sprint" is entirely redundant.
                       
                      As for Product Owners presenting GUI mockups, well, I don't think that is their role at all. The PO is responsible for assisting in gathering User Stories and maintaining the Product Backlog. The PO is not responsible for design issues, such as what the GUI will look like. My immediate thought on reading your first email was "GUI mockups would be part of an up-front requirements and design specification" which is just not a part of the Scrum development thinking or practice, but which is very much traditional roject management thinking. When a User Story comes up for consideration to be included in a Sprint, then the dvelopers, in collaboration with appropriate users, would sit down to detail the GUI design (presumably in terms of pre-existing standards). This is the 'just-in-time' philosophy.
                       
                      As well, from my perspetive, having used development tools for 30 years, I would suggest that it is a waste of time to have 'GUI mockups'. Using appropriate UI design tools, the so-called mockup is probably, or can probably be, the production level design. What did you have in mind as being a mockup, that would not be done with one of the many 'drag-and-drop' WYSIWYG style screen design tools?



                      -- 
                      http://twitter.com/scrumnl



                      -- 
                      http://twitter.com/scrumnl



                      --
                      Thanks,
                      Sarath.

                      Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335 0221 | www.quadone.com
                    • john.zayd
                      I agree that it s the responsibility of the team to provide a QA d features, however, as you mentioned also, who is going to verify that? And that sometimes
                      Message 10 of 27 , Nov 30, 2009
                      • 0 Attachment
                        I agree that it's the responsibility of the team to provide a QA'd features, however, as you mentioned also, who is going to verify that? And that sometimes include extreme cases, which dose not necessarily be obvious for the developer while implementing the feature. Add to that verifying features quality as you explained: audit, will not be part of the sprint effort, then delivering a DONE features will not be completed by the end of the sprint, unless we give the people who is going to audit what the developers did a couple of days to verify the features, which include also code freeze, and that is QA my friend!

                        My point is that you need a QA effort sometime, to do the whole testing all over again, to do the boring tasks sometimes, like testing a 2 years old screens, which we might think it's working, but somehow it dose not! Developers tend to forget that.

                        For my statement regarding the product owner in my first message, I'm against the big design up front, and against collecting requirements up front, however, it's nice to have a GUI mockups sometimes that help imagine the solution, and also evaluate it! But I agree that the team should work hand in hand with the customer in designing the front end.

                        Well, GUI mockups are mush easier to be done using PowerPoint presentation, showing at least a success scenario of doing the main goal in the sprint for example, the theme: this usually take up to 2 hours max, I don't mind wasting the 2 hours if it will bring value to the team.

                        Back to the QA - Really it's my challenge right now? How to ensure the product is in good shape without braking scrum philosophy?
                      • Sarath Kummamuru
                        Hi John, So lets do some questions? 1. Those who are going to verify what is being built, what do they do? 2. Can these Auditors define how they would verify
                        Message 11 of 27 , Nov 30, 2009
                        • 0 Attachment
                          Hi John,
                              So lets do some questions?

                          1. Those who are going to verify what is being built, what do they do?
                          2. Can these Auditors define how they would verify the system to the team even before they start development?
                            • For example say : To test this feature we need to make sure that .... are all working.
                            • To test this feature we need to make sure that .... are all failing.
                          3. Is there any way that with some kind of automation these steps of quality audit can be done within the sprint?!  

                               Also what does the team feel about taking the owner ship of the Quality of the product on them selves and learning how the verification happens.

                          thanks,
                          Sarath.

                          On Mon, Nov 30, 2009 at 4:59 PM, john.zayd <john.zayd@...> wrote:
                           

                          I agree that it's the responsibility of the team to provide a QA'd features, however, as you mentioned also, who is going to verify that? And that sometimes include extreme cases, which dose not necessarily be obvious for the developer while implementing the feature. Add to that verifying features quality as you explained: audit, will not be part of the sprint effort, then delivering a DONE features will not be completed by the end of the sprint, unless we give the people who is going to audit what the developers did a couple of days to verify the features, which include also code freeze, and that is QA my friend!

                          My point is that you need a QA effort sometime, to do the whole testing all over again, to do the boring tasks sometimes, like testing a 2 years old screens, which we might think it's working, but somehow it dose not! Developers tend to forget that.

                          For my statement regarding the product owner in my first message, I'm against the big design up front, and against collecting requirements up front, however, it's nice to have a GUI mockups sometimes that help imagine the solution, and also evaluate it! But I agree that the team should work hand in hand with the customer in designing the front end.

                          Well, GUI mockups are mush easier to be done using PowerPoint presentation, showing at least a success scenario of doing the main goal in the sprint for example, the theme: this usually take up to 2 hours max, I don't mind wasting the 2 hours if it will bring value to the team.

                          Back to the QA - Really it's my challenge right now? How to ensure the product is in good shape without braking scrum philosophy?




                          --
                          Thanks,
                          Sarath.

                          Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335 0221 | www.quadone.com
                        • Maurice le Rutte
                          John, - Who s going to verify that the verification has been done right? [ad infinitum] - If there are cases that are being identified by the QA people , but
                          Message 12 of 27 , Nov 30, 2009
                          • 0 Attachment
                            John,

                            - Who's going to verify that the verification has been done right? [ad infinitum]
                            - If there are cases that are being identified by 'the QA people', but not by 'the developers' shouldn't this then be identified *before* the stuff is being created instead of afterwards trying to find out ?
                            - If you are [legally] required to have an audit shouldn't your process be so that you know that you'll pass the audit?

                            john.zayd schreef:
                             

                            I agree that it's the responsibility of the team to provide a QA'd features, however, as you mentioned also, who is going to verify that? And that sometimes include extreme cases, which dose not necessarily be obvious for the developer while implementing the feature. Add to that verifying features quality as you explained: audit, will not be part of the sprint effort, then delivering a DONE features will not be completed by the end of the sprint, unless we give the people who is going to audit what the developers did a couple of days to verify the features, which include also code freeze, and that is QA my friend!

                            My point is that you need a QA effort sometime, to do the whole testing all over again, to do the boring tasks sometimes, like testing a 2 years old screens, which we might think it's working, but somehow it dose not! Developers tend to forget that.



                            -- 
                            http://twitter.com/scrumnl
                          • petriheiramo
                            Hi John, ... That is QA the waterfall way, my friend. You haven t yet crossed the biggest hurdle in Agility. Until you do, the good advice these people are
                            Message 13 of 27 , Nov 30, 2009
                            • 0 Attachment
                              Hi John,

                              > I agree that it's the responsibility of the team to provide
                              > a QA'd features, however, as you mentioned also, who is going
                              > to verify that? And that sometimes include extreme cases,
                              > which dose not necessarily be obvious for the developer
                              > while implementing the feature. Add to that verifying
                              > features quality as you explained: audit, will not be part
                              > of the sprint effort, then delivering a DONE features will
                              > not be completed by the end of the sprint, unless we give
                              > the people who is going to audit what the developers did a
                              > couple of days to verify the features, which include also
                              > code freeze, and that is QA my friend!

                              That is QA the waterfall way, my friend. You haven't yet crossed the biggest hurdle in Agility. Until you do, the good advice these people are giving you will not give you the answer you're looking for. So my biggest advice is to get proper coaching by a known expert to help you see what Agile and Scrum is really about, and then you will understand the problem and you can see the possible solutions yourself.

                              Your exasperation points out to the fact that Agile QA cannot be done the old way.

                              > My point is that you need a QA effort sometime, to do the
                              > whole testing all over again, to do the boring tasks
                              > sometimes, like testing a 2 years old screens, which we might
                              > think it's working, but somehow it dose not! Developers tend
                              > to forget that.

                              That's exactly why you should automate your acceptance testing so that people wouldn't have to remember and the "whole testing all over again" could be run, at no extra cost, every night or even more frequently.

                              > For my statement regarding the product owner in my first message,
                              > I'm against the big design up front, and against collecting
                              > requirements up front, however, it's nice to have a GUI mockups
                              > sometimes that help imagine the solution, and also evaluate it!
                              > But I agree that the team should work hand in hand with the
                              > customer in designing the front end.
                              >
                              > Well, GUI mockups are mush easier to be done using PowerPoint
                              > presentation, showing at least a success scenario of doing the
                              > main goal in the sprint for example, the theme: this usually
                              > take up to 2 hours max, I don't mind wasting the 2 hours if it
                              > will bring value to the team.

                              I'm sure the people will tell you that with a proper WYSIWYG UI editor, it will take less time than that (and most of it is discussion about what the UI should look like and how it should work). Or it could be done in 15 mins on a flipboard. Other than that, powerpoint is surely fine and should indeed be done (up to a point) before the iteration starts.

                              > I don't mind wasting the 2 hours if it will bring value to the team

                              Aside from the word "waste", I agree with this. Why is it waste, if it provides value to the team? If it _is_ waste, shouldn't you look for the least wasteful way of doing it, or do it in a way that isn't waste? :)

                              > Back to the QA - Really it's my challenge right now? How to
                              > ensure the product is in good shape without braking scrum
                              > philosophy?

                              By not breaking Scrum and Agile philosophy. That's what the others have been telling you. :)


                              Yours Sincerely,


                              Petri

                              ---
                              Petri Heiramo
                              Process Development Manager, Agile Coach (CST)
                              Digia Plc., Finland
                            • PeteCRuth@aol.com
                              On a philosphical (perhaps hair-splitting note) while the comment below is often true, it is not necessarily always true. Things that might have value from a
                              Message 14 of 27 , Nov 30, 2009
                              • 0 Attachment
                                On a philosphical (perhaps hair-splitting note) while the comment below is often true, it is not necessarily always true. Things that might have value from a designer and/or developer perspective, might not have the same value for certain classes of users. 
                                 
                                Like "conventional wisdom", best practices sometimes aren't, for a given situation.
                                 
                                Regards,
                                 
                                Pete 
                                 
                                In a message dated 11/30/2009 3:25:43 A.M. Pacific Standard Time, kcsarath@... writes:
                                I do agree with your thought that there should be a consistent behavior and design pattern across several products or even different areas of the same product.

                                    This is not only true of industrial design but also of software. Obviously you would not like software with some patterns in one place and a different ui pattern some where else.
                              • john.zayd
                                Hey Petri Some of you might talk a lot about the philosophy, but I don t know about the real work experience? Each project has it s own challenges and
                                Message 15 of 27 , Nov 30, 2009
                                • 0 Attachment
                                  Hey Petri

                                  Some of you might talk a lot about the philosophy, but I don't know about the real work experience? Each project has it's own challenges and problems! It's easy to say that the team is responsible to deliver a QA'd features. However, values might change that, and I guess Scrum is flexible enough to support that. For example, one of my projects was for a bank, and they simply don't want any bug in the software, especially in a module that have to do with calculations: well quality in this case was the value, and since the process is there to support achieving the goal, not the goal it self, we created a small process in the team to ensure that: we tested that module more than anything else.

                                  Best regards,
                                  John

                                  --- In scrumdevelopment@yahoogroups.com, "petriheiramo" <petri.heiramo@...> wrote:
                                  >
                                  > Hi John,
                                  >
                                  > > I agree that it's the responsibility of the team to provide
                                  > > a QA'd features, however, as you mentioned also, who is going
                                  > > to verify that? And that sometimes include extreme cases,
                                  > > which dose not necessarily be obvious for the developer
                                  > > while implementing the feature. Add to that verifying
                                  > > features quality as you explained: audit, will not be part
                                  > > of the sprint effort, then delivering a DONE features will
                                  > > not be completed by the end of the sprint, unless we give
                                  > > the people who is going to audit what the developers did a
                                  > > couple of days to verify the features, which include also
                                  > > code freeze, and that is QA my friend!
                                  >
                                  > That is QA the waterfall way, my friend. You haven't yet crossed the biggest hurdle in Agility. Until you do, the good advice these people are giving you will not give you the answer you're looking for. So my biggest advice is to get proper coaching by a known expert to help you see what Agile and Scrum is really about, and then you will understand the problem and you can see the possible solutions yourself.


                                  >
                                  > Your exasperation points out to the fact that Agile QA cannot be done the old way.
                                  >
                                  > > My point is that you need a QA effort sometime, to do the
                                  > > whole testing all over again, to do the boring tasks
                                  > > sometimes, like testing a 2 years old screens, which we might
                                  > > think it's working, but somehow it dose not! Developers tend
                                  > > to forget that.
                                  >
                                  > That's exactly why you should automate your acceptance testing so that people wouldn't have to remember and the "whole testing all over again" could be run, at no extra cost, every night or even more frequently.
                                  >
                                  > > For my statement regarding the product owner in my first message,
                                  > > I'm against the big design up front, and against collecting
                                  > > requirements up front, however, it's nice to have a GUI mockups
                                  > > sometimes that help imagine the solution, and also evaluate it!
                                  > > But I agree that the team should work hand in hand with the
                                  > > customer in designing the front end.
                                  > >
                                  > > Well, GUI mockups are mush easier to be done using PowerPoint
                                  > > presentation, showing at least a success scenario of doing the
                                  > > main goal in the sprint for example, the theme: this usually
                                  > > take up to 2 hours max, I don't mind wasting the 2 hours if it
                                  > > will bring value to the team.
                                  >
                                  > I'm sure the people will tell you that with a proper WYSIWYG UI editor, it will take less time than that (and most of it is discussion about what the UI should look like and how it should work). Or it could be done in 15 mins on a flipboard. Other than that, powerpoint is surely fine and should indeed be done (up to a point) before the iteration starts.
                                  >
                                  > > I don't mind wasting the 2 hours if it will bring value to the team
                                  >
                                  > Aside from the word "waste", I agree with this. Why is it waste, if it provides value to the team? If it _is_ waste, shouldn't you look for the least wasteful way of doing it, or do it in a way that isn't waste? :)
                                  >
                                  > > Back to the QA - Really it's my challenge right now? How to
                                  > > ensure the product is in good shape without braking scrum
                                  > > philosophy?
                                  >
                                  > By not breaking Scrum and Agile philosophy. That's what the others have been telling you. :)
                                  >
                                  >
                                  > Yours Sincerely,
                                  >
                                  >
                                  > Petri
                                  >
                                  > ---
                                  > Petri Heiramo
                                  > Process Development Manager, Agile Coach (CST)
                                  > Digia Plc., Finland
                                  >
                                • john.zayd
                                  That s exactly what i meant in my last post :-)
                                  Message 16 of 27 , Nov 30, 2009
                                  • 0 Attachment
                                    That's exactly what i meant in my last post :-)

                                    --- In scrumdevelopment@yahoogroups.com, PeteCRuth@... wrote:
                                    >
                                    > On a philosphical (perhaps hair-splitting note) while the comment below is
                                    > often true, it is not necessarily always true. Things that might have
                                    > value from a designer and/or developer perspective, might not have the same
                                    > value for certain classes of users.
                                    >
                                    > Like "conventional wisdom", best practices sometimes aren't, for a given
                                    > situation.
                                    >
                                    > Regards,
                                    >
                                    > Pete
                                    >
                                    >
                                    > In a message dated 11/30/2009 3:25:43 A.M. Pacific Standard Time,
                                    > kcsarath@... writes:
                                    >
                                    > I do agree with your thought that there should be a consistent behavior
                                    > and design pattern across several products or even different areas of the
                                    > same product.
                                    >
                                    > This is not only true of industrial design but also of software. Obviously
                                    > you would not like software with some patterns in one place and a
                                    > different ui pattern some where else.
                                    >
                                  • Roy Morien
                                    Well, my first response is: Why are the developers trusted so little that their work must be verified? AND the old question Who guards the guards? How many
                                    Message 17 of 27 , Nov 30, 2009
                                    • 0 Attachment
                                      Well, my first response is: Why are the developers trusted so little that their work must be verified? AND the old question Who guards the guards? How many iterations of verifying previous actions should there be?
                                       
                                      Why are 'extreme cases' not part of the normal testing and verification by the developers. In fact,  would have thought that extreme cases were the first things to be checked; they are the easiest because of their 'extreme' nature. AND why would they not be obvious to the developers?
                                       
                                      Second response is: If you still need to verify something 2 years after it has been implemented, and presumably has been in use for that 2 years, then there is something very odd about that. How can it happen that a defect surfaces after 2 years? In any case, after 2 years it has certainly ceased to be of the development and delivery of new features, so is well outside our ballpark under discussion. ALSO, I think the users of that 2 year old screen would probably be the best QA engineers you could have. They use it, they know what the problem is. I always feel that users are a much neglected source of QA.
                                       
                                      Why on Earth would you do a GUI mockup using Powerpoint when you have perfectly good GUI form designers such as Dreamweaver, or the visual design tools in Delphi Studio or Visual Studio? Just like why would you do a report layour on paper when you can 'paint' the report in a WYSIWYG style on the screenusing something like Crystal Reports?
                                       
                                      So to answer your question: How to ensure the product is in good shape without braking scrum philosophy? You build QA and testing into the sprint development activity. You do Test Driven Development. You train the developers in testing techniques and you use testing software such as ANT, and you do continuous integration. AND you demonstrate to the client at then end of each sprint. If there are any 'defects', especially in the GUI then you can fix them almost on the spot. The worst case scenario is that the entire sprints work is thrown away, so you have lost 2 weeks effort. But then you better do some soul searching as to why that happened. THIS is the QA that you need; how to do it better, and how to learn from your mistakes in your development process. THIS is QA to me ... my friend!
                                       
                                      Regards,
                                      Roy Morien

                                       

                                      To: scrumdevelopment@yahoogroups.com
                                      From: john.zayd@...
                                      Date: Mon, 30 Nov 2009 11:29:11 +0000
                                      Subject: [scrumdevelopment] Re: Scrum Team and the Team

                                       
                                      I agree that it's the responsibility of the team to provide a QA'd features, however, as you mentioned also, who is going to verify that? And that sometimes include extreme cases, which dose not necessarily be obvious for the developer while implementing the feature. Add to that verifying features quality as you explained: audit, will not be part of the sprint effort, then delivering a DONE features will not be completed by the end of the sprint, unless we give the people who is going to audit what the developers did a couple of days to verify the features, which include also code freeze, and that is QA my friend!

                                      My point is that you need a QA effort sometime, to do the whole testing all over again, to do the boring tasks sometimes, like testing a 2 years old screens, which we might think it's working, but somehow it dose not! Developers tend to forget that.

                                      For my statement regarding the product owner in my first message, I'm against the big design up front, and against collecting requirements up front, however, it's nice to have a GUI mockups sometimes that help imagine the solution, and also evaluate it! But I agree that the team should work hand in hand with the customer in designing the front end.

                                      Well, GUI mockups are mush easier to be done using PowerPoint presentation, showing at least a success scenario of doing the main goal in the sprint for example, the theme: this usually take up to 2 hours max, I don't mind wasting the 2 hours if it will bring value to the team.

                                      Back to the QA - Really it's my challenge right now? How to ensure the product is in good shape without braking scrum philosophy?




                                      View photos of singles in your area! Looking for a date?
                                    • Roy Morien
                                      I have always said that the design teams should mentor the dev and test teams . What design teams ? What dev teams ? WHat test teams ? Whatever happened
                                      Message 18 of 27 , Nov 30, 2009
                                      • 0 Attachment
                                        " I have always said that the design teams should mentor the dev and test teams ".
                                         
                                        What "design teams"? What "dev teams"? WHat "test teams"? Whatever happened to "multi-skilled teams"?
                                         
                                        As far as I know, no agile method subscribes to the idea of having three separate teams for design, development and testing. Far from it!
                                         
                                        Regards,
                                        Roy Morien
                                         

                                        To: scrumdevelopment@yahoogroups.com
                                        From: kcsarath@...
                                        Date: Mon, 30 Nov 2009 16:47:44 +0530
                                        Subject: Re: [scrumdevelopment] Scrum Team and the Team

                                         
                                        Hi John,
                                            Please see my inputs inline.


                                        thanks.
                                        Sarath.

                                        On Mon, Nov 30, 2009 at 2:41 PM, john.zayd <john.zayd@yahoo. com> wrote:
                                         

                                        Team members are the engineers who are building the software, writing the code. What about QA?

                                        >>>> When you mean QA what do you mean? It is the team's responsibility to assure to the PO that the product has quality and so i would see them as part of the team.
                                                  While i do not think we should have a UAT, some of my customers who use the services of our agile team, do have some team members who help the PO from a UAT perspective. But mostly they also work closely with our team members in defining Acceptance criteria, participating in testing of the builds during and at the end of the sprint.
                                         
                                        If the software is the team responsibility, then QA should be on the product owner side!
                                        >>>> I some how seem to feel that you are referring to the UAT, but my answer is already above. 
                                        What if we are building an in-house product, that is the Product Owner have the responsibilities to provide GUI mockups,
                                        >>>> This is a very common situation with many organizations that I coach. But in my opinion the PO is not responsible for the GUI mockups. The PO should be able to articulate the requirements and the vision of the product and leave it to the team to build the UI. Many cases that I have seen the teams moving into agile typically donot have these skills and normally wait for the design team to complete the mockups before the feature is started.

                                        This is not right and I have always said that the design teams should mentor the dev and test teams on the design patterns and standards used in the org and should hand hold them initially but enable the teams to do the mockups by themselves over a period of time without compromising design standards.
                                        and also work on some features such as website, brochure etc: can these be an items in the backlog? If so, some of them, at least the GUI mockups will be mixed with other items/stories, in that case, well the product owner team share the team in estimating the backlog items (story points) for these items?
                                        >>>>  The PO will not have any owner ship on estimating the back log items. 
                                        Since it's part of what DONE means for this specific tasks / item. Product owner are pigs also, and can speak in the standup meeting right? Will they report their work progress answering the three questions? Will they pay the $1 if they are late? 




                                        --
                                        Thanks,
                                        Sarath.

                                        Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335 0221 | www.quadone. com



                                        Brought to you exclusively by Windows Live Download new and classic emoticon packs at Emoticon World
                                      • Sarath Kummamuru
                                        Hi Roy, My statement was in the context of teams transitioning to agile where the org previously had UI design teams who used to hand out mockups to the teams.
                                        Message 19 of 27 , Nov 30, 2009
                                        • 0 Attachment
                                          Hi Roy,
                                              My statement was in the context of teams transitioning to agile where the org previously had UI design teams who used to hand out mockups to the teams. Now with agile, one of the big challenges that I found with teams is that the teams still expect the mockups and ui to be done by some one else. This is surely against the cross functional team goal.

                                               So my statement was that what were design teams who previously had the expertise of doing these mock ups and understand the org wide design standards should mentor the teams to understand these standards and enable the teams to take the ui design decisions by themselves without having to wait for UI mockups from some one else.

                                               Again sorry for the confusion of naming the teams because I was referring to teams in the typical waterfall env moving to agile. I do subscribe to the fact that cross functional teams are the best and should be the way to go.
                                            
                                             
                                          thanks,
                                          Sarath.

                                          On Tue, Dec 1, 2009 at 7:52 AM, Roy Morien <roymorien@...> wrote:
                                           

                                          " I have always said that the design teams should mentor the dev and test teams ".
                                           
                                          What "design teams"? What "dev teams"? WHat "test teams"? Whatever happened to "multi-skilled teams"?
                                           
                                          As far as I know, no agile method subscribes to the idea of having three separate teams for design, development and testing. Far from it!


                                           
                                          Regards,
                                          Roy Morien
                                           

                                          To: scrumdevelopment@yahoogroups.com
                                          From: kcsarath@...
                                          Date: Mon, 30 Nov 2009 16:47:44 +0530
                                          Subject: Re: [scrumdevelopment] Scrum Team and the Team

                                           
                                          Hi John,
                                              Please see my inputs inline.


                                          thanks.
                                          Sarath.

                                          On Mon, Nov 30, 2009 at 2:41 PM, john.zayd <john.zayd@...> wrote:
                                           

                                          Team members are the engineers who are building the software, writing the code. What about QA?

                                          >>>> When you mean QA what do you mean? It is the team's responsibility to assure to the PO that the product has quality and so i would see them as part of the team.
                                                    While i do not think we should have a UAT, some of my customers who use the services of our agile team, do have some team members who help the PO from a UAT perspective. But mostly they also work closely with our team members in defining Acceptance criteria, participating in testing of the builds during and at the end of the sprint.
                                           
                                          If the software is the team responsibility, then QA should be on the product owner side!
                                          >>>> I some how seem to feel that you are referring to the UAT, but my answer is already above. 
                                          What if we are building an in-house product, that is the Product Owner have the responsibilities to provide GUI mockups,
                                          >>>> This is a very common situation with many organizations that I coach. But in my opinion the PO is not responsible for the GUI mockups. The PO should be able to articulate the requirements and the vision of the product and leave it to the team to build the UI. Many cases that I have seen the teams moving into agile typically donot have these skills and normally wait for the design team to complete the mockups before the feature is started.

                                          This is not right and I have always said that the design teams should mentor the dev and test teams on the design patterns and standards used in the org and should hand hold them initially but enable the teams to do the mockups by themselves over a period of time without compromising design standards.
                                          and also work on some features such as website, brochure etc: can these be an items in the backlog? If so, some of them, at least the GUI mockups will be mixed with other items/stories, in that case, well the product owner team share the team in estimating the backlog items (story points) for these items?
                                          >>>>  The PO will not have any owner ship on estimating the back log items. 
                                          Since it's part of what DONE means for this specific tasks / item. Product owner are pigs also, and can speak in the standup meeting right? Will they report their work progress answering the three questions? Will they pay the $1 if they are late? 




                                          --
                                          Thanks,
                                          Sarath.

                                          Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335 0221 | www.quadone.com



                                          Brought to you exclusively by Windows Live Download new and classic emoticon packs at Emoticon World



                                          --
                                          Thanks,
                                          Sarath.

                                          Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335 0221 | www.quadone.com
                                        • Roy Morien
                                          Fair enough :) To: scrumdevelopment@yahoogroups.com From: kcsarath@gmail.com Date: Tue, 1 Dec 2009 09:27:28 +0530 Subject: Re: [scrumdevelopment] Scrum Team
                                          Message 20 of 27 , Nov 30, 2009
                                          • 0 Attachment
                                            Fair enough :)
                                             

                                            To: scrumdevelopment@yahoogroups.com
                                            From: kcsarath@...
                                            Date: Tue, 1 Dec 2009 09:27:28 +0530
                                            Subject: Re: [scrumdevelopment] Scrum Team and the Team

                                             
                                            Hi Roy,
                                                My statement was in the context of teams transitioning to agile where the org previously had UI design teams who used to hand out mockups to the teams. Now with agile, one of the big challenges that I found with teams is that the teams still expect the mockups and ui to be done by some one else. This is surely against the cross functional team goal.

                                                 So my statement was that what were design teams who previously had the expertise of doing these mock ups and understand the org wide design standards should mentor the teams to understand these standards and enable the teams to take the ui design decisions by themselves without having to wait for UI mockups from some one else.

                                                 Again sorry for the confusion of naming the teams because I was referring to teams in the typical waterfall env moving to agile. I do subscribe to the fact that cross functional teams are the best and should be the way to go.
                                              
                                               
                                            thanks,
                                            Sarath.

                                            On Tue, Dec 1, 2009 at 7:52 AM, Roy Morien <roymorien@hotmail. com> wrote:
                                             

                                            " I have always said that the design teams should mentor the dev and test teams ".
                                             
                                            What "design teams"? What "dev teams"? WHat "test teams"? Whatever happened to "multi-skilled teams"?
                                             
                                            As far as I know, no agile method subscribes to the idea of having three separate teams for design, development and testing. Far from it!


                                             
                                            Regards,
                                            Roy Morien
                                             

                                            To: scrumdevelopment@ yahoogroups. com
                                            From: kcsarath@gmail. com
                                            Date: Mon, 30 Nov 2009 16:47:44 +0530
                                            Subject: Re: [scrumdevelopment] Scrum Team and the Team

                                             
                                            Hi John,
                                                Please see my inputs inline.


                                            thanks.
                                            Sarath.

                                            On Mon, Nov 30, 2009 at 2:41 PM, john.zayd <john.zayd@yahoo. com> wrote:
                                             
                                            Team members are the engineers who are building the software, writing the code. What about QA?

                                            >>>> When you mean QA what do you mean? It is the team's responsibility to assure to the PO that the product has quality and so i would see them as part of the team.
                                                      While i do not think we should have a UAT, some of my customers who use the services of our agile team, do have some team members who help the PO from a UAT perspective. But mostly they also work closely with our team members in defining Acceptance criteria, participating in testing of the builds during and at the end of the sprint.
                                             
                                            If the software is the team responsibility, then QA should be on the product owner side!
                                            >>>> I some how seem to feel that you are referring to the UAT, but my answer is already above. 
                                            What if we are building an in-house product, that is the Product Owner have the responsibilities to provide GUI mockups,
                                            >>>> This is a very common situation with many organizations that I coach. But in my opinion the PO is not responsible for the GUI mockups. The PO should be able to articulate the requirements and the vision of the product and leave it to the team to build the UI. Many cases that I have seen the teams moving into agile typically donot have these skills and normally wait for the design team to complete the mockups before the feature is started.

                                            This is not right and I have always said that the design teams should mentor the dev and test teams on the design patterns and standards used in the org and should hand hold them initially but enable the teams to do the mockups by themselves over a period of time without compromising design standards.
                                            and also work on some features such as website, brochure etc: can these be an items in the backlog? If so, some of them, at least the GUI mockups will be mixed with other items/stories, in that case, well the product owner team share the team in estimating the backlog items (story points) for these items?
                                            >>>>  The PO will not have any owner ship on estimating the back log items. 
                                            Since it's part of what DONE means for this specific tasks / item. Product owner are pigs also, and can speak in the standup meeting right? Will they report their work progress answering the three questions? Will they pay the $1 if they are late? 




                                            --
                                            Thanks,
                                            Sarath.

                                            Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335 0221 | www.quadone. com



                                            Brought to you exclusively by Windows Live Download new and classic emoticon packs at Emoticon World



                                            --
                                            Thanks,
                                            Sarath.

                                            Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335 0221 | www.quadone. com



                                            Australia's #1 job site If It Exists, You'll Find it on SEEK
                                          • john.zayd
                                            Thanks Roy. QA d features are the responsibility of the team. thanks
                                            Message 21 of 27 , Dec 1, 2009
                                            • 0 Attachment
                                              Thanks Roy.
                                              QA'd features are the responsibility of the team.

                                              thanks

                                              --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:
                                              >
                                              >
                                              > Well, my first response is: Why are the developers trusted so little that their work must be verified? AND the old question Who guards the guards? How many iterations of verifying previous actions should there be?
                                              >
                                              >
                                              >
                                              > Why are 'extreme cases' not part of the normal testing and verification by the developers. In fact, would have thought that extreme cases were the first things to be checked; they are the easiest because of their 'extreme' nature. AND why would they not be obvious to the developers?
                                              >
                                              >
                                              >
                                              > Second response is: If you still need to verify something 2 years after it has been implemented, and presumably has been in use for that 2 years, then there is something very odd about that. How can it happen that a defect surfaces after 2 years? In any case, after 2 years it has certainly ceased to be of the development and delivery of new features, so is well outside our ballpark under discussion. ALSO, I think the users of that 2 year old screen would probably be the best QA engineers you could have. They use it, they know what the problem is. I always feel that users are a much neglected source of QA.
                                              >
                                              >
                                              >
                                              > Why on Earth would you do a GUI mockup using Powerpoint when you have perfectly good GUI form designers such as Dreamweaver, or the visual design tools in Delphi Studio or Visual Studio? Just like why would you do a report layour on paper when you can 'paint' the report in a WYSIWYG style on the screenusing something like Crystal Reports?
                                              >
                                              >
                                              >
                                              > So to answer your question: How to ensure the product is in good shape without braking scrum philosophy? You build QA and testing into the sprint development activity. You do Test Driven Development. You train the developers in testing techniques and you use testing software such as ANT, and you do continuous integration. AND you demonstrate to the client at then end of each sprint. If there are any 'defects', especially in the GUI then you can fix them almost on the spot. The worst case scenario is that the entire sprints work is thrown away, so you have lost 2 weeks effort. But then you better do some soul searching as to why that happened. THIS is the QA that you need; how to do it better, and how to learn from your mistakes in your development process. THIS is QA to me ... my friend!
                                              >
                                              >
                                              >
                                              > Regards,
                                              >
                                              > Roy Morien
                                              >
                                              >
                                              >
                                              >
                                              > To: scrumdevelopment@yahoogroups.com
                                              > From: john.zayd@...
                                              > Date: Mon, 30 Nov 2009 11:29:11 +0000
                                              > Subject: [scrumdevelopment] Re: Scrum Team and the Team
                                              >
                                              >
                                              >
                                              >
                                              >
                                              > I agree that it's the responsibility of the team to provide a QA'd features, however, as you mentioned also, who is going to verify that? And that sometimes include extreme cases, which dose not necessarily be obvious for the developer while implementing the feature. Add to that verifying features quality as you explained: audit, will not be part of the sprint effort, then delivering a DONE features will not be completed by the end of the sprint, unless we give the people who is going to audit what the developers did a couple of days to verify the features, which include also code freeze, and that is QA my friend!
                                              >
                                              > My point is that you need a QA effort sometime, to do the whole testing all over again, to do the boring tasks sometimes, like testing a 2 years old screens, which we might think it's working, but somehow it dose not! Developers tend to forget that.
                                              >
                                              > For my statement regarding the product owner in my first message, I'm against the big design up front, and against collecting requirements up front, however, it's nice to have a GUI mockups sometimes that help imagine the solution, and also evaluate it! But I agree that the team should work hand in hand with the customer in designing the front end.
                                              >
                                              > Well, GUI mockups are mush easier to be done using PowerPoint presentation, showing at least a success scenario of doing the main goal in the sprint for example, the theme: this usually take up to 2 hours max, I don't mind wasting the 2 hours if it will bring value to the team.
                                              >
                                              > Back to the QA - Really it's my challenge right now? How to ensure the product is in good shape without braking scrum philosophy?
                                              >
                                              >
                                              >
                                              >
                                              >
                                              > _________________________________________________________________
                                              > Looking for a date? View photos of singles in your area!
                                              > http://clk.atdmt.com/NMN/go/150855801/direct/01/
                                              >
                                            • john.zayd
                                              One last thing, PO are different than the PM? What about the customers? PO will not represent the customer? PO can attend the daily standup, but can t speak?
                                              Message 22 of 27 , Dec 1, 2009
                                              • 0 Attachment
                                                One last thing, PO are different than the PM? What about the customers? PO will not represent the customer? PO can attend the daily standup, but can't speak?



                                                --- In scrumdevelopment@yahoogroups.com, "john.zayd" <john.zayd@...> wrote:
                                                >
                                                >
                                                > Thanks Roy.
                                                > QA'd features are the responsibility of the team.
                                                >
                                                > thanks
                                                >
                                                > --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@> wrote:
                                                > >
                                                > >
                                                > > Well, my first response is: Why are the developers trusted so little that their work must be verified? AND the old question Who guards the guards? How many iterations of verifying previous actions should there be?
                                                > >
                                                > >
                                                > >
                                                > > Why are 'extreme cases' not part of the normal testing and verification by the developers. In fact, would have thought that extreme cases were the first things to be checked; they are the easiest because of their 'extreme' nature. AND why would they not be obvious to the developers?
                                                > >
                                                > >
                                                > >
                                                > > Second response is: If you still need to verify something 2 years after it has been implemented, and presumably has been in use for that 2 years, then there is something very odd about that. How can it happen that a defect surfaces after 2 years? In any case, after 2 years it has certainly ceased to be of the development and delivery of new features, so is well outside our ballpark under discussion. ALSO, I think the users of that 2 year old screen would probably be the best QA engineers you could have. They use it, they know what the problem is. I always feel that users are a much neglected source of QA.
                                                > >
                                                > >
                                                > >
                                                > > Why on Earth would you do a GUI mockup using Powerpoint when you have perfectly good GUI form designers such as Dreamweaver, or the visual design tools in Delphi Studio or Visual Studio? Just like why would you do a report layour on paper when you can 'paint' the report in a WYSIWYG style on the screenusing something like Crystal Reports?
                                                > >
                                                > >
                                                > >
                                                > > So to answer your question: How to ensure the product is in good shape without braking scrum philosophy? You build QA and testing into the sprint development activity. You do Test Driven Development. You train the developers in testing techniques and you use testing software such as ANT, and you do continuous integration. AND you demonstrate to the client at then end of each sprint. If there are any 'defects', especially in the GUI then you can fix them almost on the spot. The worst case scenario is that the entire sprints work is thrown away, so you have lost 2 weeks effort. But then you better do some soul searching as to why that happened. THIS is the QA that you need; how to do it better, and how to learn from your mistakes in your development process. THIS is QA to me ... my friend!
                                                > >
                                                > >
                                                > >
                                                > > Regards,
                                                > >
                                                > > Roy Morien
                                                > >
                                                > >
                                                > >
                                                > >
                                                > > To: scrumdevelopment@yahoogroups.com
                                                > > From: john.zayd@
                                                > > Date: Mon, 30 Nov 2009 11:29:11 +0000
                                                > > Subject: [scrumdevelopment] Re: Scrum Team and the Team
                                                > >
                                                > >
                                                > >
                                                > >
                                                > >
                                                > > I agree that it's the responsibility of the team to provide a QA'd features, however, as you mentioned also, who is going to verify that? And that sometimes include extreme cases, which dose not necessarily be obvious for the developer while implementing the feature. Add to that verifying features quality as you explained: audit, will not be part of the sprint effort, then delivering a DONE features will not be completed by the end of the sprint, unless we give the people who is going to audit what the developers did a couple of days to verify the features, which include also code freeze, and that is QA my friend!
                                                > >
                                                > > My point is that you need a QA effort sometime, to do the whole testing all over again, to do the boring tasks sometimes, like testing a 2 years old screens, which we might think it's working, but somehow it dose not! Developers tend to forget that.
                                                > >
                                                > > For my statement regarding the product owner in my first message, I'm against the big design up front, and against collecting requirements up front, however, it's nice to have a GUI mockups sometimes that help imagine the solution, and also evaluate it! But I agree that the team should work hand in hand with the customer in designing the front end.
                                                > >
                                                > > Well, GUI mockups are mush easier to be done using PowerPoint presentation, showing at least a success scenario of doing the main goal in the sprint for example, the theme: this usually take up to 2 hours max, I don't mind wasting the 2 hours if it will bring value to the team.
                                                > >
                                                > > Back to the QA - Really it's my challenge right now? How to ensure the product is in good shape without braking scrum philosophy?
                                                > >
                                                > >
                                                > >
                                                > >
                                                > >
                                                > > _________________________________________________________________
                                                > > Looking for a date? View photos of singles in your area!
                                                > > http://clk.atdmt.com/NMN/go/150855801/direct/01/
                                                > >
                                                >
                                              • Dan Rawsthorne
                                                cross functional teams are the best and should be the way to go It s not that simple. Look at what Jeff Sutherland says about Patient Keeper. As I understand
                                                Message 23 of 27 , Dec 1, 2009
                                                • 0 Attachment
                                                  "cross functional teams are the best and should be the way to go" It's
                                                  not that simple. Look at what Jeff Sutherland says about Patient Keeper.
                                                  As I understand it, his POs (doctors) deliver quite detailed
                                                  specifications to the developers. It looks to me like he has two teams
                                                  going on, a PO team developing mockups, prototypes, and specs, and a
                                                  development team turning them into code. Maybe we could consider each of
                                                  these teams cross-functional, I'm not sure. Maybe it's one big team with
                                                  two pieces. They certainly provide different kinds of artifacts in a
                                                  waterfall(ish) setup. Maybe this isn't scrum... maybe it is... does it
                                                  matter? Is this a bad thing? a good thing? or just a successful thing?

                                                  Dan Rawsthorne, PhD, CST
                                                  Senior Coach, Danube Technologies
                                                  dan@..., 425-269-8628



                                                  Roy Morien wrote:
                                                  >
                                                  >
                                                  > Fair enough :)
                                                  >
                                                  >
                                                  > ------------------------------------------------------------------------
                                                  > To: scrumdevelopment@yahoogroups.com
                                                  > From: kcsarath@...
                                                  > Date: Tue, 1 Dec 2009 09:27:28 +0530
                                                  > Subject: Re: [scrumdevelopment] Scrum Team and the Team
                                                  >
                                                  >
                                                  > Hi Roy,
                                                  > My statement was in the context of teams transitioning to agile
                                                  > where the org previously had UI design teams who used to hand out
                                                  > mockups to the teams. Now with agile, one of the big challenges that I
                                                  > found with teams is that the teams still expect the mockups and ui to
                                                  > be done by some one else. This is surely against the cross functional
                                                  > team goal.
                                                  >
                                                  > So my statement was that what were design teams who previously
                                                  > had the expertise of doing these mock ups and understand the org wide
                                                  > design standards should mentor the teams to understand these standards
                                                  > and enable the teams to take the ui design decisions by themselves
                                                  > without having to wait for UI mockups from some one else.
                                                  >
                                                  > Again sorry for the confusion of naming the teams because I was
                                                  > referring to teams in the typical waterfall env moving to agile. I do
                                                  > subscribe to the fact that cross functional teams are the best and
                                                  > should be the way to go.
                                                  >
                                                  >
                                                  > thanks,
                                                  > Sarath.
                                                  >
                                                  > On Tue, Dec 1, 2009 at 7:52 AM, Roy Morien <roymorien@...
                                                  > <mailto:roymorien@...>> wrote:
                                                  >
                                                  >
                                                  >
                                                  > " I have always said that the design teams should mentor the dev
                                                  > and test teams ".
                                                  >
                                                  > What "design teams"? What "dev teams"? WHat "test teams"? Whatever
                                                  > happened to "multi-skilled teams"?
                                                  >
                                                  > As far as I know, no agile method subscribes to the idea of having
                                                  > three separate teams for design, development and testing. Far from it!
                                                  >
                                                  >
                                                  >
                                                  > Regards,
                                                  > Roy Morien
                                                  >
                                                  > ------------------------------------------------------------------------
                                                  > To: scrumdevelopment@yahoogroups.com
                                                  > <mailto:scrumdevelopment@yahoogroups.com>
                                                  > From: kcsarath@... <mailto:kcsarath@...>
                                                  > Date: Mon, 30 Nov 2009 16:47:44 +0530
                                                  > Subject: Re: [scrumdevelopment] Scrum Team and the Team
                                                  >
                                                  >
                                                  > Hi John,
                                                  > Please see my inputs inline.
                                                  >
                                                  >
                                                  > thanks.
                                                  > Sarath.
                                                  >
                                                  > On Mon, Nov 30, 2009 at 2:41 PM, john.zayd <john.zayd@...
                                                  > <mailto:john.zayd@...>> wrote:
                                                  >
                                                  >
                                                  > *Team members are the engineers who are building the software,
                                                  > writing the code. What about QA?*
                                                  >
                                                  > >>>> When you mean QA what do you mean? It is the team's
                                                  > responsibility to assure to the PO that the product has quality
                                                  > and so i would see them as part of the team.
                                                  > While i do not think we should have a UAT, some of my
                                                  > customers who use the services of our agile team, do have some
                                                  > team members who help the PO from a UAT perspective. But mostly
                                                  > they also work closely with our team members in defining
                                                  > Acceptance criteria, participating in testing of the builds during
                                                  > and at the end of the sprint.
                                                  >
                                                  >
                                                  > *If the software is the team responsibility, then QA should be
                                                  > on the product owner side! *
                                                  >
                                                  > >>>> I some how seem to feel that you are referring to the UAT,
                                                  > but my answer is already above.
                                                  >
                                                  > *What if we are building an in-house product, that is the
                                                  > Product Owner have the responsibilities to provide GUI mockups, *
                                                  >
                                                  > >>>> This is a very common situation with many organizations that
                                                  > I coach. But in my opinion the PO is not responsible for the GUI
                                                  > mockups. The PO should be able to articulate the requirements and
                                                  > the vision of the product and leave it to the team to build the
                                                  > UI. Many cases that I have seen the teams moving into agile
                                                  > typically donot have these skills and normally wait for the design
                                                  > team to complete the mockups before the feature is started.
                                                  >
                                                  > This is not right and I have always said that the design teams
                                                  > should mentor the dev and test teams on the design patterns and
                                                  > standards used in the org and should hand hold them initially but
                                                  > enable the teams to do the mockups by themselves over a period of
                                                  > time without compromising design standards.
                                                  >
                                                  > *and also work on some features such as website, brochure etc:
                                                  > can these be an items in the backlog? If so, some of them, at
                                                  > least the GUI mockups will be mixed with other items/stories,
                                                  > in that case, well the product owner team share the team in
                                                  > estimating the backlog items (story points) for these items?*
                                                  >
                                                  > *>>*>> The PO will not have any owner ship on estimating the back
                                                  > log items.
                                                  >
                                                  > Since it's part of what DONE means for this specific tasks /
                                                  > item. Product owner are pigs also, and can speak in the
                                                  > standup meeting right? Will they report their work progress
                                                  > answering the three questions? Will they pay the $1 if they
                                                  > are late?
                                                  >
                                                  >
                                                  >
                                                  >
                                                  > --
                                                  > Thanks,
                                                  > Sarath.
                                                  >
                                                  > Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335
                                                  > 0221 | www.quadone.com <http://www.quadone.com/>
                                                  >
                                                  >
                                                  > ------------------------------------------------------------------------
                                                  > Brought to you exclusively by Windows Live Download new and
                                                  > classic emoticon packs at Emoticon World
                                                  > <http://windowslive.ninemsn.com.au/emoticon.aspx?>
                                                  >
                                                  >
                                                  >
                                                  >
                                                  > --
                                                  > Thanks,
                                                  > Sarath.
                                                  >
                                                  > Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335
                                                  > 0221 | www.quadone.com <http://www.quadone.com/>
                                                  >
                                                  >
                                                  > ------------------------------------------------------------------------
                                                  > Australia's #1 job site If It Exists, You'll Find it on SEEK
                                                  > <http://clk.atdmt.com/NMN/go/157639755/direct/01/>
                                                  >
                                                • Sarath Kummamuru
                                                  PO is NOT the PM. Do you need a PM!? other than the Scrum Master? PO should represent the customer and should be part of the customer team or some one who can
                                                  Message 24 of 27 , Dec 1, 2009
                                                  • 0 Attachment
                                                    PO is NOT the PM. Do you need a PM!? other than the Scrum Master?


                                                    PO should represent the customer and should be part of the customer team or some one who can own decisions of the customer.

                                                    PO can attend the daily standup but normally it is restricted to the team members to speak. If there is a quick update i donot see why they cannot speak but surely not at the expense of the team communication.

                                                    Thanks,
                                                    Sarath.


                                                    On Tue, Dec 1, 2009 at 2:08 PM, john.zayd <john.zayd@...> wrote:
                                                     

                                                    One last thing, PO are different than the PM? What about the customers? PO will not represent the customer? PO can attend the daily standup, but can't speak?



                                                    --- In scrumdevelopment@yahoogroups.com, "john.zayd" <john.zayd@...> wrote:
                                                    >
                                                    >
                                                    > Thanks Roy.
                                                    > QA'd features are the responsibility of the team.
                                                    >
                                                    > thanks
                                                    >
                                                    > --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@> wrote:
                                                    > >
                                                    > >
                                                    > > Well, my first response is: Why are the developers trusted so little that their work must be verified? AND the old question Who guards the guards? How many iterations of verifying previous actions should there be?
                                                    > >
                                                    > >
                                                    > >
                                                    > > Why are 'extreme cases' not part of the normal testing and verification by the developers. In fact, would have thought that extreme cases were the first things to be checked; they are the easiest because of their 'extreme' nature. AND why would they not be obvious to the developers?
                                                    > >
                                                    > >
                                                    > >
                                                    > > Second response is: If you still need to verify something 2 years after it has been implemented, and presumably has been in use for that 2 years, then there is something very odd about that. How can it happen that a defect surfaces after 2 years? In any case, after 2 years it has certainly ceased to be of the development and delivery of new features, so is well outside our ballpark under discussion. ALSO, I think the users of that 2 year old screen would probably be the best QA engineers you could have. They use it, they know what the problem is. I always feel that users are a much neglected source of QA.
                                                    > >
                                                    > >
                                                    > >
                                                    > > Why on Earth would you do a GUI mockup using Powerpoint when you have perfectly good GUI form designers such as Dreamweaver, or the visual design tools in Delphi Studio or Visual Studio? Just like why would you do a report layour on paper when you can 'paint' the report in a WYSIWYG style on the screenusing something like Crystal Reports?
                                                    > >
                                                    > >
                                                    > >
                                                    > > So to answer your question: How to ensure the product is in good shape without braking scrum philosophy? You build QA and testing into the sprint development activity. You do Test Driven Development. You train the developers in testing techniques and you use testing software such as ANT, and you do continuous integration. AND you demonstrate to the client at then end of each sprint. If there are any 'defects', especially in the GUI then you can fix them almost on the spot. The worst case scenario is that the entire sprints work is thrown away, so you have lost 2 weeks effort. But then you better do some soul searching as to why that happened. THIS is the QA that you need; how to do it better, and how to learn from your mistakes in your development process. THIS is QA to me ... my friend!
                                                    > >
                                                    > >
                                                    > >
                                                    > > Regards,
                                                    > >
                                                    > > Roy Morien
                                                    > >
                                                    > >
                                                    > >
                                                    > >
                                                    > > To: scrumdevelopment@yahoogroups.com
                                                    > > From: john.zayd@
                                                    > > Date: Mon, 30 Nov 2009 11:29:11 +0000
                                                    > > Subject: [scrumdevelopment] Re: Scrum Team and the Team
                                                    > >
                                                    > >
                                                    > >
                                                    > >
                                                    > >
                                                    > > I agree that it's the responsibility of the team to provide a QA'd features, however, as you mentioned also, who is going to verify that? And that sometimes include extreme cases, which dose not necessarily be obvious for the developer while implementing the feature. Add to that verifying features quality as you explained: audit, will not be part of the sprint effort, then delivering a DONE features will not be completed by the end of the sprint, unless we give the people who is going to audit what the developers did a couple of days to verify the features, which include also code freeze, and that is QA my friend!
                                                    > >
                                                    > > My point is that you need a QA effort sometime, to do the whole testing all over again, to do the boring tasks sometimes, like testing a 2 years old screens, which we might think it's working, but somehow it dose not! Developers tend to forget that.
                                                    > >
                                                    > > For my statement regarding the product owner in my first message, I'm against the big design up front, and against collecting requirements up front, however, it's nice to have a GUI mockups sometimes that help imagine the solution, and also evaluate it! But I agree that the team should work hand in hand with the customer in designing the front end.
                                                    > >
                                                    > > Well, GUI mockups are mush easier to be done using PowerPoint presentation, showing at least a success scenario of doing the main goal in the sprint for example, the theme: this usually take up to 2 hours max, I don't mind wasting the 2 hours if it will bring value to the team.
                                                    > >
                                                    > > Back to the QA - Really it's my challenge right now? How to ensure the product is in good shape without braking scrum philosophy?
                                                    > >
                                                    > >
                                                    > >
                                                    > >
                                                    > >
                                                    > > __________________________________________________________
                                                    > > Looking for a date? View photos of singles in your area!
                                                    > > http://clk.atdmt.com/NMN/go/150855801/direct/01/
                                                    > >
                                                    >




                                                    --
                                                    Thanks,
                                                    Sarath.

                                                    Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335 0221 | www.quadone.com
                                                  • Dan Rawsthorne
                                                    Whoever the accountable person is on the team is the PO. This person may also have other organizational roles, like Program Manager or Project Manager. But
                                                    Message 25 of 27 , Dec 1, 2009
                                                    • 0 Attachment
                                                      Whoever the accountable person is on the team is the PO. This person may
                                                      also have other organizational roles, like Program Manager or Project
                                                      Manager. But must be ON THE TEAM to be the PO. Accountability is the key
                                                      ingredient... though it would be nice if the PO was also a SME on the
                                                      business, the product, etc

                                                      Dan Rawsthorne, PhD, CST
                                                      Senior Coach, Danube Technologies
                                                      dan@..., 425-269-8628



                                                      Sarath Kummamuru wrote:
                                                      >
                                                      >
                                                      > PO is NOT the PM. Do you need a PM!? other than the Scrum Master?
                                                      >
                                                      >
                                                      > PO should represent the customer and should be part of the customer
                                                      > team or some one who can own decisions of the customer.
                                                      >
                                                      > PO can attend the daily standup but normally it is restricted to the
                                                      > team members to speak. If there is a quick update i donot see why they
                                                      > cannot speak but surely not at the expense of the team communication.
                                                      >
                                                      > Thanks,
                                                      > Sarath.
                                                      >
                                                      >
                                                      > On Tue, Dec 1, 2009 at 2:08 PM, john.zayd <john.zayd@...
                                                      > <mailto:john.zayd@...>> wrote:
                                                      >
                                                      >
                                                      >
                                                      > One last thing, PO are different than the PM? What about the
                                                      > customers? PO will not represent the customer? PO can attend the
                                                      > daily standup, but can't speak?
                                                      >
                                                      >
                                                      >
                                                      > --- In scrumdevelopment@yahoogroups.com
                                                      > <mailto:scrumdevelopment%40yahoogroups.com>, "john.zayd"
                                                      > <john.zayd@...> wrote:
                                                      > >
                                                      > >
                                                      > > Thanks Roy.
                                                      > > QA'd features are the responsibility of the team.
                                                      > >
                                                      > > thanks
                                                      > >
                                                      > > --- In scrumdevelopment@yahoogroups.com
                                                      > <mailto:scrumdevelopment%40yahoogroups.com>, Roy Morien
                                                      > <roymorien@> wrote:
                                                      > > >
                                                      > > >
                                                      > > > Well, my first response is: Why are the developers trusted so
                                                      > little that their work must be verified? AND the old question Who
                                                      > guards the guards? How many iterations of verifying previous
                                                      > actions should there be?
                                                      > > >
                                                      > > >
                                                      > > >
                                                      > > > Why are 'extreme cases' not part of the normal testing and
                                                      > verification by the developers. In fact, would have thought that
                                                      > extreme cases were the first things to be checked; they are the
                                                      > easiest because of their 'extreme' nature. AND why would they not
                                                      > be obvious to the developers?
                                                      > > >
                                                      > > >
                                                      > > >
                                                      > > > Second response is: If you still need to verify something 2
                                                      > years after it has been implemented, and presumably has been in
                                                      > use for that 2 years, then there is something very odd about that.
                                                      > How can it happen that a defect surfaces after 2 years? In any
                                                      > case, after 2 years it has certainly ceased to be of the
                                                      > development and delivery of new features, so is well outside our
                                                      > ballpark under discussion. ALSO, I think the users of that 2 year
                                                      > old screen would probably be the best QA engineers you could have.
                                                      > They use it, they know what the problem is. I always feel that
                                                      > users are a much neglected source of QA.
                                                      > > >
                                                      > > >
                                                      > > >
                                                      > > > Why on Earth would you do a GUI mockup using Powerpoint when
                                                      > you have perfectly good GUI form designers such as Dreamweaver, or
                                                      > the visual design tools in Delphi Studio or Visual Studio? Just
                                                      > like why would you do a report layour on paper when you can
                                                      > 'paint' the report in a WYSIWYG style on the screenusing something
                                                      > like Crystal Reports?
                                                      > > >
                                                      > > >
                                                      > > >
                                                      > > > So to answer your question: How to ensure the product is in
                                                      > good shape without braking scrum philosophy? You build QA and
                                                      > testing into the sprint development activity. You do Test Driven
                                                      > Development. You train the developers in testing techniques and
                                                      > you use testing software such as ANT, and you do continuous
                                                      > integration. AND you demonstrate to the client at then end of each
                                                      > sprint. If there are any 'defects', especially in the GUI then you
                                                      > can fix them almost on the spot. The worst case scenario is that
                                                      > the entire sprints work is thrown away, so you have lost 2 weeks
                                                      > effort. But then you better do some soul searching as to why that
                                                      > happened. THIS is the QA that you need; how to do it better, and
                                                      > how to learn from your mistakes in your development process. THIS
                                                      > is QA to me ... my friend!
                                                      > > >
                                                      > > >
                                                      > > >
                                                      > > > Regards,
                                                      > > >
                                                      > > > Roy Morien
                                                      > > >
                                                      > > >
                                                      > > >
                                                      > > >
                                                      > > > To: scrumdevelopment@yahoogroups.com
                                                      > <mailto:scrumdevelopment%40yahoogroups.com>
                                                      > > > From: john.zayd@
                                                      > > > Date: Mon, 30 Nov 2009 11:29:11 +0000
                                                      > > > Subject: [scrumdevelopment] Re: Scrum Team and the Team
                                                      > > >
                                                      > > >
                                                      > > >
                                                      > > >
                                                      > > >
                                                      > > > I agree that it's the responsibility of the team to provide a
                                                      > QA'd features, however, as you mentioned also, who is going to
                                                      > verify that? And that sometimes include extreme cases, which dose
                                                      > not necessarily be obvious for the developer while implementing
                                                      > the feature. Add to that verifying features quality as you
                                                      > explained: audit, will not be part of the sprint effort, then
                                                      > delivering a DONE features will not be completed by the end of the
                                                      > sprint, unless we give the people who is going to audit what the
                                                      > developers did a couple of days to verify the features, which
                                                      > include also code freeze, and that is QA my friend!
                                                      > > >
                                                      > > > My point is that you need a QA effort sometime, to do the
                                                      > whole testing all over again, to do the boring tasks sometimes,
                                                      > like testing a 2 years old screens, which we might think it's
                                                      > working, but somehow it dose not! Developers tend to forget that.
                                                      > > >
                                                      > > > For my statement regarding the product owner in my first
                                                      > message, I'm against the big design up front, and against
                                                      > collecting requirements up front, however, it's nice to have a GUI
                                                      > mockups sometimes that help imagine the solution, and also
                                                      > evaluate it! But I agree that the team should work hand in hand
                                                      > with the customer in designing the front end.
                                                      > > >
                                                      > > > Well, GUI mockups are mush easier to be done using PowerPoint
                                                      > presentation, showing at least a success scenario of doing the
                                                      > main goal in the sprint for example, the theme: this usually take
                                                      > up to 2 hours max, I don't mind wasting the 2 hours if it will
                                                      > bring value to the team.
                                                      > > >
                                                      > > > Back to the QA - Really it's my challenge right now? How to
                                                      > ensure the product is in good shape without braking scrum philosophy?
                                                      > > >
                                                      > > >
                                                      > > >
                                                      > > >
                                                      > > >
                                                      > > > __________________________________________________________
                                                      > > > Looking for a date? View photos of singles in your area!
                                                      > > > http://clk.atdmt.com/NMN/go/150855801/direct/01/
                                                      > <http://clk.atdmt.com/NMN/go/150855801/direct/01/>
                                                      > > >
                                                      > >
                                                      >
                                                      >
                                                      >
                                                      >
                                                      > --
                                                      > Thanks,
                                                      > Sarath.
                                                      >
                                                      > Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335
                                                      > 0221 | www.quadone.com <http://www.quadone.com>
                                                      >
                                                    • Roy Morien
                                                      Well, as said elswhere, the PM role is redundant. Between the PO, the SM and The Team the project ets managed by consensus, by collaboration, by group decision
                                                      Message 26 of 27 , Dec 1, 2009
                                                      • 0 Attachment
                                                        Well, as said elswhere, the PM role is redundant. Between the PO, the SM and The Team the project ets managed by consensus, by collaboration, by group decision making. No PM telling folks what to do!
                                                         
                                                        What about the customers? Well, they have a champion in the PO, but also The Team collaborates with them as a normal part of the development activity. The PO gathers User Stories from the customers, the developers elaborate those User Stories with the customers. I also see no particular reason why The Team can't identify User Stories from the customers. Part of the job of the SM is to stop customers and the PO from interfering in the activities of The Team during a sprint. The Daily Scrum is a meeting of The Team to quickly inform The Team as a whole of success, failure, achievement, problems encountered during the day's development activities. This is not a planning meeting. It is not a demonstration to the client. It is all about the day's DEVELOPMENT activities. Therefore I see no reason why the PO should be there in attendance. Any questions arising from the Daily Scrum (which is only 15-20 minutes, remember) that need to be raised wih the PO can be done at another time, notduring the Daily Scrum.
                                                         
                                                        So the customers are well represented by the PO, and are included in the collaborative behaviour of The Team, so their needs are well looked after.
                                                         
                                                        Regards,
                                                        Roy Morien
                                                         

                                                        To: scrumdevelopment@yahoogroups.com
                                                        From: john.zayd@...
                                                        Date: Tue, 1 Dec 2009 08:38:09 +0000
                                                        Subject: [scrumdevelopment] Re: Scrum Team and the Team

                                                         
                                                        One last thing, PO are different than the PM? What about the customers? PO will not represent the customer? PO can attend the daily standup, but can't speak?

                                                        --- In scrumdevelopment@ yahoogroups. com, "john.zayd" <john.zayd@. ..> wrote:
                                                        >
                                                        >
                                                        > Thanks Roy.
                                                        > QA'd features are the responsibility of the team.
                                                        >
                                                        > thanks
                                                        >
                                                        > --- In scrumdevelopment@ yahoogroups. com, Roy Morien <roymorien@> wrote:
                                                        > >
                                                        > >
                                                        > > Well, my first response is: Why are the developers trusted so little that their work must be verified? AND the old question Who guards the guards? How many iterations of verifying previous actions should there be?
                                                        > >
                                                        > >
                                                        > >
                                                        > > Why are 'extreme cases' not part of the normal testing and verification by the developers. In fact, would have thought that extreme cases were the first things to be checked; they are the easiest because of their 'extreme' nature. AND why would they not be obvious to the developers?
                                                        > >
                                                        > >
                                                        > >
                                                        > > Second response is: If you still need to verify something 2 years after it has been implemented, and presumably has been in use for that 2 years, then there is something very odd about that. How can it happen that a defect surfaces after 2 years? In any case, after 2 years it has certainly ceased to be of the development and delivery of new features, so is well outside our ballpark under discussion. ALSO, I think the users of that 2 year old screen would probably be the best QA engineers you could have. They use it, they know what the problem is. I always feel that users are a much neglected source of QA.
                                                        > >
                                                        > >
                                                        > >
                                                        > > Why on Earth would you do a GUI mockup using Powerpoint when you have perfectly good GUI form designers such as Dreamweaver, or the visual design tools in Delphi Studio or Visual Studio? Just like why would you do a report layour on paper when you can 'paint' the report in a WYSIWYG style on the screenusing something like Crystal Reports?
                                                        > >
                                                        > >
                                                        > >
                                                        > > So to answer your question: How to ensure the product is in good shape without braking scrum philosophy? You build QA and testing into the sprint development activity. You do Test Driven Development. You train the developers in testing techniques and you use testing software such as ANT, and you do continuous integration. AND you demonstrate to the client at then end of each sprint. If there are any 'defects', especially in the GUI then you can fix them almost on the spot. The worst case scenario is that the entire sprints work is thrown away, so you have lost 2 weeks effort. But then you better do some soul searching as to why that happened. THIS is the QA that you need; how to do it better, and how to learn from your mistakes in your development process. THIS is QA to me ... my friend!
                                                        > >
                                                        > >
                                                        > >
                                                        > > Regards,
                                                        > >
                                                        > > Roy Morien
                                                        > >
                                                        > >
                                                        > >
                                                        > >
                                                        > > To: scrumdevelopment@ yahoogroups. com
                                                        > > From: john.zayd@
                                                        > > Date: Mon, 30 Nov 2009 11:29:11 +0000
                                                        > > Subject: [scrumdevelopment] Re: Scrum Team and the Team
                                                        > >
                                                        > >
                                                        > >
                                                        > >
                                                        > >
                                                        > > I agree that it's the responsibility of the team to provide a QA'd features, however, as you mentioned also, who is going to verify that? And that sometimes include extreme cases, which dose not necessarily be obvious for the developer while implementing the feature. Add to that verifying features quality as you explained: audit, will not be part of the sprint effort, then delivering a DONE features will not be completed by the end of the sprint, unless we give the people who is going to audit what the developers did a couple of days to verify the features, which include also code freeze, and that is QA my friend!
                                                        > >
                                                        > > My point is that you need a QA effort sometime, to do the whole testing all over again, to do the boring tasks sometimes, like testing a 2 years old screens, which we might think it's working, but somehow it dose not! Developers tend to forget that.
                                                        > >
                                                        > > For my statement regarding the product owner in my first message, I'm against the big design up front, and against collecting requirements up front, however, it's nice to have a GUI mockups sometimes that help imagine the solution, and also evaluate it! But I agree that the team should work hand in hand with the customer in designing the front end.
                                                        > >
                                                        > > Well, GUI mockups are mush easier to be done using PowerPoint presentation, showing at least a success scenario of doing the main goal in the sprint for example, the theme: this usually take up to 2 hours max, I don't mind wasting the 2 hours if it will bring value to the team.
                                                        > >
                                                        > > Back to the QA - Really it's my challenge right now? How to ensure the product is in good shape without braking scrum philosophy?
                                                        > >
                                                        > >
                                                        > >
                                                        > >
                                                        > >
                                                        > > ____________ _________ _________ _________ _________ _________ _
                                                        > > Looking for a date? View photos of singles in your area!
                                                        > > http://clk.atdmt. com/NMN/go/ 150855801/ direct/01/
                                                        > >
                                                        >




                                                        Find out how Use Messenger in your Hotmail inbox
                                                      • Roy Morien
                                                        If it is successful, then go for it! But don t think that it is a practice necessarilly applicable universally. In all things, there are horses for courses
                                                        Message 27 of 27 , Dec 1, 2009
                                                        • 0 Attachment
                                                          If it is successful, then go for it! But don't think that it is a practice necessarilly applicable universally.
                                                           
                                                          In all things, there are 'horses for courses' as the saying goes. 
                                                           
                                                          Again, Scrum is not a process strait-jacket that rigidly bounds our development behaviour.
                                                           
                                                          So, you're quite right ... is it Scrum? Doesn't look exactly like Scrum. Is it a bad (good) thing? Well, does it work for you? Does it matter if it is Scrum exactly or not? Nope!
                                                           
                                                          As always, the euphemistic 'you'. No specific 'you' is implied.
                                                           
                                                          Regards,
                                                          Roy Morien
                                                           
                                                          > To: scrumdevelopment@yahoogroups.com
                                                          > From: dan.rawsthorne@...
                                                          > Date: Tue, 1 Dec 2009 01:20:34 -0800
                                                          > Subject: Re: [!! SPAM] RE: [scrumdevelopment] Scrum Team and the Team
                                                          >
                                                          > "cross functional teams are the best and should be the way to go" It's
                                                          > not that simple. Look at what Jeff Sutherland says about Patient Keeper.
                                                          > As I understand it, his POs (doctors) deliver quite detailed
                                                          > specifications to the developers. It looks to me like he has two teams
                                                          > going on, a PO team developing mockups, prototypes, and specs, and a
                                                          > development team turning them into code. Maybe we could consider each of
                                                          > these teams cross-functional, I'm not sure. Maybe it's one big team with
                                                          > two pieces. They certainly provide different kinds of artifacts in a
                                                          > waterfall(ish) setup. Maybe this isn't scrum... maybe it is... does it
                                                          > matter? Is this a bad thing? a good thing? or just a successful thing?
                                                          >
                                                          > Dan Rawsthorne, PhD, CST
                                                          > Senior Coach, Danube Technologies
                                                          > dan@..., 425-269-8628
                                                          >
                                                          >
                                                          >
                                                          > Roy Morien wrote:
                                                          > >
                                                          > >
                                                          > > Fair enough :)
                                                          > >
                                                          > >
                                                          > > ------------------------------------------------------------------------
                                                          > > To: scrumdevelopment@yahoogroups.com
                                                          > > From: kcsarath@...
                                                          > > Date: Tue, 1 Dec 2009 09:27:28 +0530
                                                          > > Subject: Re: [scrumdevelopment] Scrum Team and the Team
                                                          > >
                                                          > >
                                                          > > Hi Roy,
                                                          > > My statement was in the context of teams transitioning to agile
                                                          > > where the org previously had UI design teams who used to hand out
                                                          > > mockups to the teams. Now with agile, one of the big challenges that I
                                                          > > found with teams is that the teams still expect the mockups and ui to
                                                          > > be done by some one else. This is surely against the cross functional
                                                          > > team goal.
                                                          > >
                                                          > > So my statement was that what were design teams who previously
                                                          > > had the expertise of doing these mock ups and understand the org wide
                                                          > > design standards should mentor the teams to understand these standards
                                                          > > and enable the teams to take the ui design decisions by themselves
                                                          > > without having to wait for UI mockups from some one else.
                                                          > >
                                                          > > Again sorry for the confusion of naming the teams because I was
                                                          > > referring to teams in the typical waterfall env moving to agile. I do
                                                          > > subscribe to the fact that cross functional teams are the best and
                                                          > > should be the way to go.
                                                          > >
                                                          > >
                                                          > > thanks,
                                                          > > Sarath.
                                                          > >
                                                          > > On Tue, Dec 1, 2009 at 7:52 AM, Roy Morien <roymorien@...
                                                          > > <mailto:roymorien@...>> wrote:
                                                          > >
                                                          > >
                                                          > >
                                                          > > " I have always said that the design teams should mentor the dev
                                                          > > and test teams ".
                                                          > >
                                                          > > What "design teams"? What "dev teams"? WHat "test teams"? Whatever
                                                          > > happened to "multi-skilled teams"?
                                                          > >
                                                          > > As far as I know, no agile method subscribes to the idea of having
                                                          > > three separate teams for design, development and testing. Far from it!
                                                          > >
                                                          > >
                                                          > >
                                                          > > Regards,
                                                          > > Roy Morien
                                                          > >
                                                          > > ------------------------------------------------------------------------
                                                          > > To: scrumdevelopment@yahoogroups.com
                                                          > > <mailto:scrumdevelopment@yahoogroups.com>
                                                          > > From: kcsarath@... <mailto:kcsarath@...>
                                                          > > Date: Mon, 30 Nov 2009 16:47:44 +0530
                                                          > > Subject: Re: [scrumdevelopment] Scrum Team and the Team
                                                          > >
                                                          > >
                                                          > > Hi John,
                                                          > > Please see my inputs inline.
                                                          > >
                                                          > >
                                                          > > thanks.
                                                          > > Sarath.
                                                          > >
                                                          > > On Mon, Nov 30, 2009 at 2:41 PM, john.zayd <john.zayd@...
                                                          > > <mailto:john.zayd@...>> wrote:
                                                          > >
                                                          > >
                                                          > > *Team members are the engineers who are building the software,
                                                          > > writing the code. What about QA?*
                                                          > >
                                                          > > >>>> When you mean QA what do you mean? It is the team's
                                                          > > responsibility to assure to the PO that the product has quality
                                                          > > and so i would see them as part of the team.
                                                          > > While i do not think we should have a UAT, some of my
                                                          > > customers who use the services of our agile team, do have some
                                                          > > team members who help the PO from a UAT perspective. But mostly
                                                          > > they also work closely with our team members in defining
                                                          > > Acceptance criteria, participating in testing of the builds during
                                                          > > and at the end of the sprint.
                                                          > >
                                                          > >
                                                          > > *If the software is the team responsibility, then QA should be
                                                          > > on the product owner side! *
                                                          > >
                                                          > > >>>> I some how seem to feel that you are referring to the UAT,
                                                          > > but my answer is already above.
                                                          > >
                                                          > > *What if we are building an in-house product, that is the
                                                          > > Product Owner have the responsibilities to provide GUI mockups, *
                                                          > >
                                                          > > >>>> This is a very common situation with many organizations that
                                                          > > I coach. But in my opinion the PO is not responsible for the GUI
                                                          > > mockups. The PO should be able to articulate the requirements and
                                                          > > the vision of the product and leave it to the team to build the
                                                          > > UI. Many cases that I have seen the teams moving into agile
                                                          > > typically donot have these skills and normally wait for the design
                                                          > > team to complete the mockups before the feature is started.
                                                          > >
                                                          > > This is not right and I have always said that the design teams
                                                          > > should mentor the dev and test teams on the design patterns and
                                                          > > standards used in the org and should hand hold them initially but
                                                          > > enable the teams to do the mockups by themselves over a period of
                                                          > > time without compromising design standards.
                                                          > >
                                                          > > *and also work on some features such as website, brochure etc:
                                                          > > can these be an items in the backlog? If so, some of them, at
                                                          > > least the GUI mockups will be mixed with other items/stories,
                                                          > > in that case, well the product owner team share the team in
                                                          > > estimating the backlog items (story points) for these items?*
                                                          > >
                                                          > > *>>*>> The PO will not have any owner ship on estimating the back
                                                          > > log items.
                                                          > >
                                                          > > Since it's part of what DONE means for this specific tasks /
                                                          > > item. Product owner are pigs also, and can speak in the
                                                          > > standup meeting right? Will they report their work progress
                                                          > > answering the three questions? Will they pay the $1 if they
                                                          > > are late?
                                                          > >
                                                          > >
                                                          > >
                                                          > >
                                                          > > --
                                                          > > Thanks,
                                                          > > Sarath.
                                                          > >
                                                          > > Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335
                                                          > > 0221 | www.quadone.com <http://www.quadone.com/>
                                                          > >
                                                          > >
                                                          > > ------------------------------------------------------------------------
                                                          > > Brought to you exclusively by Windows Live Download new and
                                                          > > classic emoticon packs at Emoticon World
                                                          > > <http://windowslive.ninemsn.com.au/emoticon.aspx?>
                                                          > >
                                                          > >
                                                          > >
                                                          > >
                                                          > > --
                                                          > > Thanks,
                                                          > > Sarath.
                                                          > >
                                                          > > Quad One Technologies | Mobile: +91 98490 05620 | Off: +91 40 2335
                                                          > > 0221 | www.quadone.com <http://www.quadone.com/>
                                                          > >
                                                          > >
                                                          > > ------------------------------------------------------------------------
                                                          > > Australia's #1 job site If It Exists, You'll Find it on SEEK
                                                          > > <http://clk.atdmt.com/NMN/go/157639755/direct/01/>
                                                          > >
                                                          >
                                                          >
                                                          > ------------------------------------
                                                          >
                                                          > 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/
                                                          >


                                                          Check out Domain Radar NOW! A world FIRST in property search has arrived!
                                                        Your message has been successfully submitted and would be delivered to recipients shortly.