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

43255Re: [!! SPAM] Re: [scrumdevelopment] Re: Scrum Team and the Team

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