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.

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?

--- 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 3 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 4 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?

>
>
> 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 5 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.

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/
> >
>

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 6 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

>
>
> 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 7 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.

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/> >>

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 8 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/>