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

43266RE: [scrumdevelopment] Re: Scrum Team and the Team

Expand Messages
  • Roy Morien
    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
    • Show all 27 messages in this topic