• Each test should ideally be independent of each other and should run independent of each other
• Skip the tests you don't want to run
  
• Investigate mock objects and design patterns
• If you feel the need to test private objects, you are going wrong [I guess thats obvious]
• Use coding standards for your nUnit tests too :)
• If possible use code coverage tools too like http://www.ncover.com/
• And obviously - first write the test and then the code rather than vice-versa. You could try ping pong programming where one developer writes the test and the other writes the code to pass through it.
  

Hi,

I recently completed the SCM course with Pete. My organization is just getting ready to provide SCRUM orientation to people. I have following query in my mind,

Continuous integration and continuous testing during a sprint will require source code syndication and automation of testing. Considering Microsoft platform, I guess it will be VSTS and nUnit that one has to use to institutionalize test automation and code syndication.

Please share best practices, suggestions that I can adapt. Thanks.

With Best Regards,
Nitin Bal

______________________________________________________________________

good summary jaimon.  my only comments are (a) in my opinion, the scrum
of scrums participant could be the scrummaster -- it's really up to the
teams to decide who the right person is -- if it's not working out, then
they can try having someone else go.  also, I think it's a good idea to
make sure the scrum of scrums has someone senior in management (perhaps
even an exec) that they can quickly escalate issues to if required.
when there are multi-team blocks that get identified at the scrum of
scrums, they may be related to organization-wide issues that require
more senior-level assistance / support in resolving.  (just to be clear,
though, I am not suggesting that the scrum of scrums be a way for
executives to monitor the project -- rather, it should be easy for the
scrum of scrums participants to flag an issue that they want to escalate
quickly to an exec if / when needed.)

Jaimon Jose wrote:
>
> I have a number of large projects where I need to have multiple scrum
> teams. We are in a planning phase right now to see how we can implement
> the scrum of scrums. I read a couple of articles from scrumalliance
> (http://www.scrumalliance.org/articles/46
> <http://www.scrumalliance.org/articles/46>). Here are my findings...
> - Smaller team size is always better (5-9)
> - A team member, preferably a technical team member should represent the
> team in the scrum of scrum meeting. It should not be PO or SM
> - Scrum of scrum meetings need not be held daily. However, it should be
> held daily for distributed teams.
> - One of the objectives of these meetings is problem solving. Schedule
> your scrum of scrums meeting for a longer duration and discuss the
> issues that teams have after updating your team's status.
> - Scrum of scrum teams are self organizing. There will not be any PO or
> SM for these teams.
>
> Comments?
> --jaimon
>
>

I have a number of large projects where I need to have multiple scrum
teams.  We are in a planning phase right now to see how we can implement
the scrum of scrums.  I read a couple of articles from scrumalliance
(http://www.scrumalliance.org/articles/46).  Here are my findings...
- Smaller team size is always better (5-9)
- A team member, preferably a technical team member should represent the
team in the scrum of scrum meeting.  It should not be PO or SM
- Scrum of scrum meetings need not be held daily.  However, it should be
held daily for distributed teams.
- One of the objectives of these meetings is problem solving. Schedule
your scrum of scrums meeting for a longer duration and discuss the
issues that teams have after updating your team's status.
- Scrum of scrum teams are self organizing.  There will not be any PO or
SM for these teams.

Comments?
--jaimon

Michael Feathers' book, "Working effectively with Legacy Code" may be
a great companion for using Henrik's techniques. Feathers describe
many techniques(patterns) for making legacy code testable. Indian
Edition of the book is available as well.

Jayadeep

--- In Scrum-India@yahoogroups.com, "Pete Deemer" <petedeemer@...> wrote:
>
>
> There's a great article by Henrik Kniberg on how to catch up on test
> automation when you have a lot on pre-existing code:
>
> http://blog.crisp.se/henrikkniberg/2008/01/03/1199386980000.html
>
> If anyone is in the midst of doing this (or about to start), please
> share your experiences with the group, I know this is something a lot
> of people are wrestling with / daunted by.  best, --Pete
>

scrum-india wiki... cool!

is there anyone in the group with a burning passion on the topic below,
who'd like to volunteer to set up the wiki and facilitate creating the
lists?  whoever volunteers first gets it...

Vikrama Dhiman wrote:
>
> >>What if we got together as a community, and wrote
> (using a wiki perhaps) a short article called "advice for clients about
> using Scrum / Do's and Don'ts", that says all the things we'd like to
> say to them but can't -- which we could then point clients about at the
> start of a scrum project?
>
> Fantastic Idea!
>
> We could have two Wikis actually, one for clients [what they wanted to
> tell the team from a Scrum Do's/ Dont's perspective] and one for the
> teams wanting to tell the clients. However, in true Scrum fashion - at
> present, lets focus on the latter one only at present. :)
>
> Who would be creating it? Maybe we could have a Scrum India Wiki.
>
> */Pete Deemer <petedeemer@...>/* wrote:
>
>     Yeah, I see this a lot as well. Client demands a change during the
>     Sprint, team is forced to say yes. This makes client think "I can
>     make
>     changes anytime", which makes them less disciplined about preparing
>     their Backlog for the Sprint Planning Meeting, which then causes MORE
>     change requests during the Sprint. Team never gets to 100% done by
>     the
>     end of a Sprint, they feel stressed out all the time, and their
>     software
>     is full of defects. Eventually, this may cause them to abandon Scrum.
>     The high degree of flexibility Scrum gives the Product Owner
>     (ability to
>     change the backlog at the start of every Sprint) comes at a cost: the
>     team has to be protected from change during the Sprint, if you
>     want them
>     to achieve anything.
>
>     One thing I strongly recommend is trying shorter Sprints. 30 days is
>     longer than most clients can wait to make new requests. But you
>     may be
>     able to convince them to wait 2 weeks, or if not then 1 week. You can
>     try it for a Sprint or two and see if it helps.
>
>     Here's an idea. What if we got together as a community, and wrote
>     (using a wiki perhaps) a short article called "advice for clients
>     about
>     using Scrum / Do's and Don'ts", that says all the things we'd like to
>     say to them but can't -- which we could then point clients about
>     at the
>     start of a scrum project?
>
>     --Pete
>
>     Jay Mehta wrote:
>     > Implementing No Change in SCRUM process. I gree with Vikram,
>     there no
>     > fullhearted effort in sprint planning which results lots of
>     chaos even
>     > in Sprint. I have seen in Indian scenario where Scrum Master,
>     Product
>     > Owner have even terminated STORY in Sprint and not the Sprint.
>     Most of
>     > the professional has either not understood the concept of SCRUM or
>     > they are taking advantage for the flexibility in the apporach or
>     > having double standards in the following the process.
>     >
>     >
>     >
>     > */Vikrama Dhiman <vickydhiman@...
>     <mailto:vickydhiman%40yahoo.com>>/* wrote:
>     >
>     > "Implementing No Change Rules - seems to be a major areas of
>     > concern. All the Scrum practitioners I talk to, always have a
>     > problem with this [or with customers not defining priorities or
>     > giving any feedback what so ever].
>     >
>     > One reason is [at least with us] that mostly the time and
>     > materials projects have transitioned to Agile, and time and
>     > materials have had a history of almost ad-hoc, no tracking
>     > management, at least with us. Bringing in the discipline that
>     > Scrum imposes is hard enough for the teams in this case and on top
>     > of it to get clients to get used to it requires some effort. I
>     > think clients are insisting on making changes through out the
>     > sprint only when:
>     >
>     > * They are not doing enough ground work for the sprint/ iteration
>     > * There is lack of product owner role
>     > * There are too many customer representatives - one managing
>     > previous release, one planning next release, one is customer
>     > liaison officer and blah blah
>     > * They don't realize the loss of business value of stability
>     > in a sprint
>     > * Sprints are too long
>     >
>     > We are still struggling in coming to terms with this. Hence, any
>     > ideas and thoughts would be really useful.
>     >
>     > */sharadbn2003 <sharadbn@...
>     <mailto:sharadbn%40gmail.com>>/* wrote:
>     >
>     > First of all, I dont think this is Scrum probel. Scrum in any
>     > case
>     > allows any one to plan sprint only after a thorugh analysis and
>     > estimates. No one is commiting anything more than they can
>     > deliver.
>     >
>     > Secondly, there is an estimation process which decided the
>     > quantum
>     > of delievarbles for a sprint.
>     >
>     > Thridly, there is always a provison to terminate the sprint if
>     > there
>     > is so much chaos.
>     >
>     > So, to sum up, it is against the Scrum philosophy to allow
>     > changes
>     > dueing the sprint.
>     >
>     > Regards
>     >
>     > Sharad B Nalawade
>     >
>     > --- In Scrum-India@yahoogroups.com
>     <mailto:Scrum-India%40yahoogroups.com>
>     > <mailto:Scrum-India%40yahoogroups.com>, "Prabhakar Karve"
>     > <prkarve@...>
>     > wrote:
>     > >
>     > > Another area of annoyance to the customers that we have come
>     > across
>     > > is the strict discipline of not accepting any changes once a
>     > sprint
>     > > starts. They are so used to the freedom and power of making
>     > changes
>     > > whenever they wish. Has anyone faced this problem? What is the
>     > best
>     > > way to deal with it other than insisting that Scrum requires it?
>     > >
>     > > --- In Scrum-India@yahoogroups.com
>     <mailto:Scrum-India%40yahoogroups.com>
>     > <mailto:Scrum-India%40yahoogroups.com>, "suresh adina"
>     > <asuresh18@>
>     > > wrote:
>     > > >
>     > > > What I have noticed that most customers are afraid
>     > of "terminology"
>     > > more
>     > > > than the process itself. So the moment you
>     > > say "ISO", "CMMI", "Agile" or
>     > > > "Scrum" to customers they tend to go into defensive mode. In
>     > some
>     > > way same
>     > > > is the case with team members when they are not clear on the
>     > impact.
>     > > >
>     > > > So instead of going into the semantics of what to call it,
>     > start
>     > by
>     > > > explaining the methodology to be applied and the
>     > activities that
>     > > will be
>     > > > done there of including their roles. Whether it is
>     > customer or
>     > team
>     > > members,
>     > > > they need to see an inherent benefit to themselves and not
>     > just
>     > to
>     > > the
>     > > > project, which is an " unseen" entity.
>     > > >
>     > > > Customer involvement in the project at all stages is
>     > beneficial
>     > all
>     > > around.
>     > > > This is specially so when the customer plays the role of
>     > reviewer
>     > > throughout
>     > > > since the final outcome impacts their business and any
>     > > modifications can be
>     > > > identified in early stages.
>     > > >
>     > > > However, it is important to remember one key aspect. We
>     > should
>     > be
>     > > careful to
>     > > > ensure that Customer does not become our QA or QC. It is more
>     > about
>     > > > acceptance as we progress with Sprints and direct visibility
>     > into
>     > > progress
>     > > > of the project. As long as we take these precautions, I do
>     > not
>     > see
>     > > how any
>     > > > customer would be "annoyed" about being involved.
>     > > >
>     > > > Look forward to more of these discussions tomorrow.
>     > > >
>     > > > Suresh A
>     > > >
>     > >
>     >
>     >
>     > ----------------------------------------------------------
>     > Be a better friend, newshound, and know-it-all with Yahoo! Mobile.
>     > Try it now.
>     >
>    
<http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtD\
ypao8Wcj9tAcJ
>    
<http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtD\
ypao8Wcj9tAcJ>>
>     >
>     >
>     >
>     > ----------------------------------------------------------
>     > Never miss a thing. Make Yahoo your homepage.
>     > <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs
>     <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs>>
>     >
>
>
> ------------------------------------------------------------------------
> Never miss a thing. Make Yahoo your homepage.
> <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs>
>

There's a great article by Henrik Kniberg on how to catch up on test
automation when you have a lot on pre-existing code:

http://blog.crisp.se/henrikkniberg/2008/01/03/1199386980000.html

If anyone is in the midst of doing this (or about to start), please
share your experiences with the group, I know this is something a lot
of people are wrestling with / daunted by.  best, --Pete

Yeah, I see this a lot as well. Client demands a change during the
Sprint, team is forced to say yes. This makes client think "I can make
changes anytime", which makes them less disciplined about preparing
their Backlog for the Sprint Planning Meeting, which then causes MORE
change requests during the Sprint. Team never gets to 100% done by the
end of a Sprint, they feel stressed out all the time, and their software
is full of defects. Eventually, this may cause them to abandon Scrum.
The high degree of flexibility Scrum gives the Product Owner (ability to
change the backlog at the start of every Sprint) comes at a cost: the
team has to be protected from change during the Sprint, if you want them
to achieve anything.

One thing I strongly recommend is trying shorter Sprints. 30 days is
longer than most clients can wait to make new requests. But you may be
able to convince them to wait 2 weeks, or if not then 1 week. You can
try it for a Sprint or two and see if it helps.

Here's an idea. What if we got together as a community, and wrote
(using a wiki perhaps) a short article called "advice for clients about
using Scrum / Do's and Don'ts", that says all the things we'd like to
say to them but can't -- which we could then point clients about at the
start of a scrum project?

--Pete

Jay Mehta wrote:
> Implementing No Change in SCRUM process. I gree with Vikram, there no
> fullhearted effort in sprint planning which results lots of chaos even
> in Sprint. I have seen in Indian scenario where Scrum Master, Product
> Owner have even terminated STORY in Sprint and not the Sprint. Most of
> the professional has either not understood the concept of SCRUM or
> they are taking advantage for the flexibility in the apporach or
> having double standards in the following the process.
>
>
>
> */Vikrama Dhiman <vickydhiman@yahoo.com>/* wrote:
>
> "Implementing No Change Rules - seems to be a major areas of
> concern. All the Scrum practitioners I talk to, always have a
> problem with this [or with customers not defining priorities or
> giving any feedback what so ever].
>
> One reason is [at least with us] that mostly the time and
> materials projects have transitioned to Agile, and time and
> materials have had a history of almost ad-hoc, no tracking
> management, at least with us. Bringing in the discipline that
> Scrum imposes is hard enough for the teams in this case and on top
> of it to get clients to get used to it requires some effort. I
> think clients are insisting on making changes through out the
> sprint only when:
>
> * They are not doing enough ground work for the sprint/ iteration
> * There is lack of product owner role
> * There are too many customer representatives - one managing
> previous release, one planning next release, one is customer
> liaison officer and blah blah
> * They don't realize the loss of business value of stability
> in a sprint
> * Sprints are too long
>
> We are still struggling in coming to terms with this. Hence, any
> ideas and thoughts would be really useful.
>
> */sharadbn2003 <sharadbn@gmail.com>/* wrote:
>
> First of all, I dont think this is Scrum probel. Scrum in any
> case
> allows any one to plan sprint only after a thorugh analysis and
> estimates. No one is commiting anything more than they can
> deliver.
>
> Secondly, there is an estimation process which decided the
> quantum
> of delievarbles for a sprint.
>
> Thridly, there is always a provison to terminate the sprint if
> there
> is so much chaos.
>
> So, to sum up, it is against the Scrum philosophy to allow
> changes
> dueing the sprint.
>
> Regards
>
> Sharad B Nalawade
>
> --- In Scrum-India@yahoogroups.com
> <mailto:Scrum-India%40yahoogroups.com>, "Prabhakar Karve"
> <prkarve@...>
> wrote:
> >
> > Another area of annoyance to the customers that we have come
> across
> > is the strict discipline of not accepting any changes once a
> sprint
> > starts. They are so used to the freedom and power of making
> changes
> > whenever they wish. Has anyone faced this problem? What is the
> best
> > way to deal with it other than insisting that Scrum requires it?
> >
> > --- In Scrum-India@yahoogroups.com
> <mailto:Scrum-India%40yahoogroups.com>, "suresh adina"
> <asuresh18@>
> > wrote:
> > >
> > > What I have noticed that most customers are afraid
> of "terminology"
> > more
> > > than the process itself. So the moment you
> > say "ISO", "CMMI", "Agile" or
> > > "Scrum" to customers they tend to go into defensive mode. In
> some
> > way same
> > > is the case with team members when they are not clear on the
> impact.
> > >
> > > So instead of going into the semantics of what to call it,
> start
> by
> > > explaining the methodology to be applied and the
> activities that
> > will be
> > > done there of including their roles. Whether it is
> customer or
> team
> > members,
> > > they need to see an inherent benefit to themselves and not
> just
> to
> > the
> > > project, which is an " unseen" entity.
> > >
> > > Customer involvement in the project at all stages is
> beneficial
> all
> > around.
> > > This is specially so when the customer plays the role of
> reviewer
> > throughout
> > > since the final outcome impacts their business and any
> > modifications can be
> > > identified in early stages.
> > >
> > > However, it is important to remember one key aspect. We
> should
> be
> > careful to
> > > ensure that Customer does not become our QA or QC. It is more
> about
> > > acceptance as we progress with Sprints and direct visibility
> into
> > progress
> > > of the project. As long as we take these precautions, I do
> not
> see
> > how any
> > > customer would be "annoyed" about being involved.
> > >
> > > Look forward to more of these discussions tomorrow.
> > >
> > > Suresh A
> > >
> >
>
>
> ----------------------------------------------------------
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile.
> Try it now.
> <http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ>
>
>
>
> ----------------------------------------------------------
> Never miss a thing. Make Yahoo your homepage.
> <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs>
>

Very insightful , entertaining and nice !

manu

--- In Scrum-India@yahoogroups.com, "Pete Deemer" <petedeemer@...> wrote:
>
> Neat little article on TDD, will take 5 mins to read and tells you a
lot.
>
> "6 Reasons to develop your tests first"
> http://www.lispcast.com/2008/01/6-reasons-to-develop-your-tests-first
>
> Could be useful for helping explain to management (who maybe stopped
> coding before TDD came along) why it would be worth learning to do this?
>
> --Pete
>

Neat little article on TDD, will take 5 mins to read and tells you a lot.

"6 Reasons to develop your tests first"
http://www.lispcast.com/2008/01/6-reasons-to-develop-your-tests-first

Could be useful for helping explain to management (who maybe stopped
coding before TDD came along) why it would be worth learning to do this?

--Pete

Yeah, I see this a lot as well.  Client demands a change during the
Sprint, team is forced to say yes.  This makes client think "I can make
changes anytime", which makes them less disciplined about preparing
their Backlog for the Sprint Planning Meeting, which then causes MORE
change requests during the Sprint.  Team never gets to 100% done by the
end of a Sprint, they feel stressed out all the time, and their software
is full of defects.  Eventually, this may cause them to abandon Scrum.
The high degree of flexibility Scrum gives the Product Owner (ability to
change the backlog at the start of every Sprint) comes at a cost: the
team has to be protected from change during the Sprint, if you want them
to achieve anything.

One thing I strongly recommend is trying shorter Sprints.  30 days is
longer than most clients can wait to make new requests.  But you may be
able to convince them to wait 2 weeks, or if not then 1 week.  You can
try it for a Sprint or two and see if it helps.

Here's an idea.  What if we got together as a community, and wrote
(using a wiki perhaps) a short article called "advice for clients about
using Scrum / Do's and Don'ts", that says all the things we'd like to
say to them but can't -- which we could then point clients about at the
start of a scrum project?

--Pete

Jay Mehta wrote:
> Implementing No Change in SCRUM process. I gree with Vikram, there no
> fullhearted effort in sprint planning which results lots of chaos even
> in Sprint. I have seen in Indian scenario where Scrum Master, Product
> Owner have even terminated STORY in Sprint and not the Sprint. Most of
> the professional has either not understood the concept of SCRUM or
> they are taking advantage for the flexibility in the apporach or
> having double standards in the following the process.
>
>
>
> */Vikrama Dhiman <vickydhiman@...>/* wrote:
>
>     "Implementing No Change Rules - seems to be a major areas of
>     concern. All the Scrum practitioners I talk to, always have a
>     problem with this [or with customers not defining priorities or
>     giving any feedback what so ever].
>
>     One reason is [at least with us] that mostly the time and
>     materials projects have transitioned to Agile, and time and
>     materials have had a history of almost ad-hoc, no tracking
>     management, at least with us. Bringing in the discipline that
>     Scrum imposes is hard enough for the teams in this case and on top
>     of it to get clients to get used to it requires some effort. I
>     think clients are insisting on making changes through out the
>     sprint only when:
>
>         * They are not doing enough ground work for the sprint/ iteration
>         * There is lack of product owner role
>         * There are too many customer representatives - one managing
>           previous release, one planning next release, one is customer
>           liaison officer and blah blah
>         * They don't realize the loss of business value of stability
>           in a sprint
>         * Sprints are too long
>
>     We are still struggling in coming to terms with this. Hence, any
>     ideas and thoughts would be really useful.
>
>     */sharadbn2003 <sharadbn@...>/* wrote:
>
>         First of all, I dont think this is Scrum probel. Scrum in any
>         case
>         allows any one to plan sprint only after a thorugh analysis and
>         estimates. No one is commiting anything more than they can
>         deliver.
>
>         Secondly, there is an estimation process which decided the
>         quantum
>         of delievarbles for a sprint.
>
>         Thridly, there is always a provison to terminate the sprint if
>         there
>         is so much chaos.
>
>         So, to sum up, it is against the Scrum philosophy to allow
>         changes
>         dueing the sprint.
>
>         Regards
>
>         Sharad B Nalawade
>
>         --- In Scrum-India@yahoogroups.com
>         <mailto:Scrum-India%40yahoogroups.com>, "Prabhakar Karve"
>         <prkarve@...>
>         wrote:
>         >
>         > Another area of annoyance to the customers that we have come
>         across
>         > is the strict discipline of not accepting any changes once a
>         sprint
>         > starts. They are so used to the freedom and power of making
>         changes
>         > whenever they wish. Has anyone faced this problem? What is the
>         best
>         > way to deal with it other than insisting that Scrum requires it?
>         >
>         > --- In Scrum-India@yahoogroups.com
>         <mailto:Scrum-India%40yahoogroups.com>, "suresh adina"
>         <asuresh18@>
>         > wrote:
>         > >
>         > > What I have noticed that most customers are afraid
>         of "terminology"
>         > more
>         > > than the process itself. So the moment you
>         > say "ISO", "CMMI", "Agile" or
>         > > "Scrum" to customers they tend to go into defensive mode. In
>         some
>         > way same
>         > > is the case with team members when they are not clear on the
>         impact.
>         > >
>         > > So instead of going into the semantics of what to call it,
>         start
>         by
>         > > explaining the methodology to be applied and the
>         activities that
>         > will be
>         > > done there of including their roles. Whether it is
>         customer or
>         team
>         > members,
>         > > they need to see an inherent benefit to themselves and not
>         just
>         to
>         > the
>         > > project, which is an " unseen" entity.
>         > >
>         > > Customer involvement in the project at all stages is
>         beneficial
>         all
>         > around.
>         > > This is specially so when the customer plays the role of
>         reviewer
>         > throughout
>         > > since the final outcome impacts their business and any
>         > modifications can be
>         > > identified in early stages.
>         > >
>         > > However, it is important to remember one key aspect. We
>         should
>         be
>         > careful to
>         > > ensure that Customer does not become our QA or QC. It is more
>         about
>         > > acceptance as we progress with Sprints and direct visibility
>         into
>         > progress
>         > > of the project. As long as we take these precautions, I do
>         not
>         see
>         > how any
>         > > customer would be "annoyed" about being involved.
>         > >
>         > > Look forward to more of these discussions tomorrow.
>         > >
>         > > Suresh A
>         > >
>         >
>
>
>     ------------------------------------------------------------------------
>     Be a better friend, newshound, and know-it-all with Yahoo! Mobile.
>     Try it now.
>    
<http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtD\
ypao8Wcj9tAcJ>
>
>
>
> ------------------------------------------------------------------------
> Never miss a thing. Make Yahoo your homepage.
> <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs>
>

"Implementing No Change Rules - seems to be a major areas of concern. All the Scrum practitioners I talk to, always have a problem with this [or with customers not defining priorities or giving any feedback what so ever].

One reason is [at least with us] that mostly the time and materials projects have transitioned to Agile, and time and materials have had a history of almost ad-hoc, no tracking management, at least with us. Bringing in the discipline that Scrum imposes is hard enough for the teams in this case and on top of it to get clients to get used to it requires some effort. I think clients are insisting on making changes through out the sprint only when:

• They are not doing enough ground work for the sprint/ iteration
• There is lack of product owner role
  
• There are too many customer representatives - one managing previous release, one planning next release, one is customer liaison officer and blah blah
  
• They don't realize the loss of business value of stability in a sprint
  
• Sprints are too long
  

We are still struggling in coming to terms with this. Hence, any ideas and thoughts would be really useful.

sharadbn2003 <sharadbn@gmail.com> wrote:

First of all, I dont think this is Scrum probel. Scrum in any case
allows any one to plan sprint only after a thorugh analysis and
estimates. No one is commiting anything more than they can deliver.

Secondly, there is an estimation process which decided the quantum
of delievarbles for a sprint.

Thridly, there is always a provison to terminate the sprint if there
is so much chaos.

So, to sum up, it is against the Scrum philosophy to allow changes
dueing the sprint.

Regards

Sharad B Nalawade

--- In Scrum-India@yahoogroups.com, "Prabhakar Karve" <prkarve@...>
wrote:
>
> Another area of annoyance to the customers that we have come
across
> is the strict discipline of not accepting any changes once a
sprint
> starts. They are so used to the freedom and power of making
changes
> whenever they wish. Has anyone faced this problem? What is the
best
> way to deal with it other than insisting that Scrum requires it?
>
> --- In Scrum-India@yahoogroups.com, "suresh adina" <asuresh18@>
> wrote:
> >
> > What I have noticed that most customers are afraid
of "terminology"
> more
> > than the process itself. So the moment you
> say "ISO", "CMMI", "Agile" or
> > "Scrum" to customers they tend to go into defensive mode. In
some
> way same
> > is the case with team members when they are not clear on the
impact.
> >
> > So instead of going into the semantics of what to call it, start
by
> > explaining the methodology to be applied and the activities that
> will be
> > done there of including their roles. Whether it is customer or
team
> members,
> > they need to see an inherent benefit to themselves and not just
to
> the
> > project, which is an " unseen" entity.
> >
> > Customer involvement in the project at all stages is beneficial
all
> around.
> > This is specially so when the customer plays the role of
reviewer
> throughout
> > since the final outcome impacts their business and any
> modifications can be
> > identified in early stages.
> >
> > However, it is important to remember one key aspect. We should
be
> careful to
> > ensure that Customer does not become our QA or QC. It is more
about
> > acceptance as we progress with Sprints and direct visibility
into
> progress
> > of the project. As long as we take these precautions, I do not
see
> how any
> > customer would be "annoyed" about being involved.
> >
> > Look forward to more of these discussions tomorrow.
> >
> > Suresh A
> >
>

---

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

• They are not doing enough ground work for the sprint/ iteration
• There is lack of product owner role
  
• There are too many customer representatives - one managing previous release, one planning next release, one is customer liaison officer and blah blah
  
• They don't realize the loss of business value of stability in a sprint
  
• Sprints are too long
  

First of all, I dont think this is Scrum probel. Scrum in any case
allows any one to plan sprint only after a thorugh analysis and
estimates. No one is commiting anything more than they can deliver.

Secondly, there is an estimation process which decided the quantum
of delievarbles for a sprint.

Thridly, there is always a provison to terminate the sprint if there
is so much chaos.

So, to sum up, it is against the Scrum philosophy to allow changes
dueing the sprint.

Regards

Sharad B Nalawade

--- In Scrum-India@yahoogroups.com, "Prabhakar Karve" <prkarve@...>
wrote:
>
> Another area of annoyance to the customers that we have come
across
> is the strict discipline of not accepting any changes once a
sprint
> starts. They are so used to the freedom and power of making
changes
> whenever they wish. Has anyone faced this problem? What is the
best
> way to deal with it other than insisting that Scrum requires it?
>
> --- In Scrum-India@yahoogroups.com, "suresh adina" <asuresh18@>
> wrote:
> >
> > What I have noticed that most customers are afraid
of "terminology"
> more
> > than the process itself. So the moment you
> say "ISO", "CMMI", "Agile" or
> > "Scrum" to customers they tend to go into defensive mode. In
some
> way same
> > is the case with team members when they are not clear on the
impact.
> >
> > So instead of going into the semantics of what to call it, start
by
> > explaining the methodology to be applied and the activities that
> will be
> > done there of including their roles. Whether it is customer or
team
> members,
> > they need to see an inherent benefit to themselves and not just
to
> the
> > project, which is an " unseen" entity.
> >
> > Customer involvement in the project at all stages is beneficial
all
> around.
> > This is specially so when the customer plays the role of
reviewer
> throughout
> > since the final outcome impacts their business and any
> modifications can be
> > identified in early stages.
> >
> > However, it is important to remember one key aspect. We should
be
> careful to
> > ensure that Customer does not become our QA or QC. It is more
about
> > acceptance as we progress with Sprints and direct visibility
into
> progress
> > of the project. As long as we take these precautions, I do not
see
> how any
> > customer would be "annoyed" about being involved.
> >
> > Look forward to more of these discussions tomorrow.
> >
> > Suresh A
> >
>

First of all, I dont think this is Scrum probel. Scrum in any case
allows any one to plan sprint only after a thorugh analysis and
estimates. No one is commiting anything more than they can deliver.

Secondly, there is an estimation process which decided the quantum
of delievarbles for a sprint.

Thridly, there is always a provison to terminate the sprint if there
is so much chaos.

So, to sum up, it is against the Scrum philosophy to allow changes
dueing the sprint.

Regards

Sharad B Nalawade



--- In Scrum-India@yahoogroups.com, "Prabhakar Karve" <prkarve@...>
wrote:
>
> Another area of annoyance to the customers that we have come
across
> is the strict discipline of not accepting any changes once a
sprint
> starts. They are so used to the freedom and power of making
changes
> whenever they wish. Has anyone faced this problem? What is the
best
> way to deal with it other than insisting that Scrum requires it?
>
> --- In Scrum-India@yahoogroups.com, "suresh adina" <asuresh18@>
> wrote:
> >
> > What I have noticed that most customers are afraid
of "terminology"
> more
> > than the process itself. So the moment you
> say "ISO", "CMMI", "Agile" or
> > "Scrum" to customers they tend to go into defensive mode. In
some
> way same
> > is the case with team members when they are not clear on the
impact.
> >
> > So instead of going into the semantics of what to call it, start
by
> > explaining the methodology to be applied and the activities that
> will be
> > done there of including their roles. Whether it is customer or
team
> members,
> > they need to see an inherent benefit to themselves and not just
to
> the
> > project, which is an " unseen" entity.
> >
> > Customer involvement in the project at all stages is beneficial
all
> around.
> > This is specially so when the customer plays the role of
reviewer
> throughout
> > since the final outcome impacts their business and any
> modifications can be
> > identified in early stages.
> >
> > However, it is important to remember one key aspect. We should
be
> careful to
> > ensure that Customer does not become our QA or QC. It is more
about
> > acceptance as we progress with Sprints and direct visibility
into
> progress
> > of the project. As long as we take these precautions, I do not
see
> how any
> > customer would be "annoyed" about being involved.
> >
> > Look forward to more of these discussions tomorrow.
> >
> > Suresh A
> >
>

Another area of annoyance to the customers that we have come across
is the strict discipline of not accepting any changes once a sprint
starts. They are so used to the freedom and power of making changes
whenever they wish. Has anyone faced this problem? What is the best
way to deal with it other than insisting that Scrum requires it?

--- In Scrum-India@yahoogroups.com, "suresh adina" <asuresh18@...>
wrote:
>
> What I have noticed that most customers are afraid of "terminology"
more
> than the process itself. So the moment you
say "ISO", "CMMI", "Agile" or
> "Scrum" to customers they tend to go into defensive mode. In some
way same
> is the case with team members when they are not clear on the impact.
>
> So instead of going into the semantics of what to call it, start by
> explaining the methodology to be applied and the activities that
will be
> done there of including their roles. Whether it is customer or team
members,
> they need to see an inherent benefit to themselves and not just to
the
> project, which is an " unseen" entity.
>
> Customer involvement in the project at all stages is beneficial all
around.
> This is specially so when the customer plays the role of reviewer
throughout
> since the final outcome impacts their business and any
modifications can be
> identified in early stages.
>
> However, it is important to remember one key aspect. We should be
careful to
> ensure that Customer does not become our QA or QC. It is more about
> acceptance as we progress with Sprints and direct visibility into
progress
> of the project. As long as we take these precautions, I do not see
how any
> customer would be "annoyed" about being involved.
>
> Look forward to more of these discussions tomorrow.
>
> Suresh A
>

Vikrama

thanks for your comments.

when we step into an organisation trying to sell agile based
development highlighiting all benefits looks good to everyone
including the client who listens to it. ofcourse it would doom to
fail when we expect the whole org to change the process in day one -
it happens like SOA movement within the org to reach business goals.

but are we doing this in every engagement? i bet not - atleast in
service segment where many of the client engagements are won what
unique things that we get on board to client like cost effecice
solutions through open source tools, ability to delivery what we
committed, better project visibility ( through agile)

but more often the change is at client org where client don't seem to
understnd agile way of doing things. from my exp, my client
complained to us their involvement is increasingly getting higher
every iteration due to the kind of feedback we get on deliverables.
they are just annoyed of thier involvement as they thought, it's
vendor resp to deliver - which is also true.

I agree that we should go one team at a time - but what if we don't
do the transition at root (customer approach towards agile and its
commitment) - that would eventually doom to fail subsequnt
opportunities. In a service industry where one should bring high
competitive offering is questioned seriously when you can't delvier
what you have committed.

I like the approach which Pete said that we need to have some kind of
mutual agreement or a contract put inplace upfront to have sort of
MSA - master agreement!

--- In Scrum-India@yahoogroups.com, Vikrama Dhiman <vickydhiman@...>
wrote:
>
> Hello Selvan:
>
> Transitioning to Agile is generally slow. Below assumes a "service
industry" scenario.
>
> One of the mistakes you could do is converting whole organization
at one go. What I'd recommend is going one team at a time [and let
one team *really* get it]. Its difficult selling this to a management
looking at quick fix solutions - but I think you'd get a better
success by implementing it team by team.
>
> Some of the things you will need to keep in mind [would help]:
>
> Try and do the first projects in Scrum using time and materials
basis and not fixed price [this is because welcoming change gets
interpreted without the discipline aspect really sinking in at both
the team and product owner end]
> Try and use some XP engineering practices by the book
> Do Scrum by the book
> Have an on-site Scrum coach/ consultant
> If you do want to do Scrum on a fixed price project, try and
quote only for one release at a time and keep one release small
enough to be able to estimate
> Do it on a domain you are most comfortable with
>
> Hope that helps!
>
> Thanks
>
> Pete Deemer <petedeemer@...> wrote:
Selvan, let's say another client came to you tomorrow, saying "we'd
> like to try scrum". based on your lessons learned below, what are
the
> 5 (or however many you like) things on your checklist, that you
would
> want to make sure you did, to set you and your client up for
success?
> What I have in mind are very practical steps you could take.
>
> for example, I've seen some teams actually come up with a scrum
> "contract" with the client. it's not really a contract, it's just
a
> piece of paper laying out the groundrules of how we're going to do
> scrum, but it's really helpful in surfacing areas where the client
> either "understand scrum differently" (the polite way to say it!)
or
> is unsure of whether they're going to be able to commit.
obviously,
> you have to be careful about this -- they're the client, after
all --
> so you want to make sure they understand you're doing this not to
be
> difficult or demanding, but because you want to see the project
succeed.
>
> I'd love to hear what other people would put on their checklist,
based
> on their experiences...
>
> --p
>
> --- In Scrum-India@yahoogroups.com, "Kalaiselvan" <selmaks@> wrote:
> >
> > All
> > I welcome all to this forum and I personaly thank Pete for his
> > initiative on this to bring all people together to discuss,
debate on
> > Agile dev.
> >
> > To share my experience, I've seen many people taling about Agile
> > thinking that it's another software dev process like 'waterfall'
and
> > take it light to acknowledge that it's good and we will
implement
> > successfully etc while selling solutions to customer ( it could
be
> > internal/external). That's a great misjudgement - or to be
honest the
> > person who claims so haven't understood the difficulty in making
> > agile development success.
> >
> > yes it is indeed another dev process - but more matured, mor
epainful
> > to implement and requires lot of decipline.
> >
> > I've a bitter experience where I had tough changing the mindset
of my
> > client to transition to Agile though they have been following
> > waterfall ( or some thier own way of doing things design-dev-
test
> > etc). In the end, we failed to show case the credibility of
agile
> > development ( it goes with many valid reasons but i think it's
out of
> > discussino here) and customer insisting going back to his dev
> > process.
> >
> > lessons learned was
> > 1. agile is not for every customer engagment / project
> > 2. approach customer transition more transparent and better
> > commitment and involvement from customer team (upper mgt from
> > customer)
> > 3. requires lot of decipline and no compramise on 'agile' way of
> > doing things
> > 4. need right people in the team who could understand and
appreciate
> > the value of doing in 'agile' way
> > 5. technology choice to hande many aspects of agile dev (
TDD,Pair
> > programming, incremental design and dev etc)
> > 6. proper role players upfront and commitment from project
> > stakeholders
> > 7. identify artifacts that are relevant upfront
> > 8. enrichment of agile way of doing things which gives
success.....
> >
> > Looking forward to others to share such experience here
> >
> > you are welcome ---- all the best!
> >
> > thanks
> > Selvan
> >
>
>
>
>
>
>
> ---------------------------------
> Never miss a thing. Make Yahoo your homepage.
>

Vikrama

thanks for your comments.

when we step into an organisation trying to sell agile based
development highlighiting all benefits looks good to everyone
including the client who listens to it. ofcourse it would doom to
fail when we expect the whole org to change the process in day one -
it happens like SOA movement within the org to reach business goals.

but are we doing this in every engagement? i bet not - atleast in
service segment where many of the client engagements are won what
unique things that we get on board to client like cost effecice
solutions through open source tools, ability to delivery what we
committed, better project visibility ( through agile)

but more often the change is at client org where client don't seem to
understnd agile way of doing things. from my exp, my client
complained to us their involvement is increasingly getting higher
every iteration due to the kind of feedback we get on deliverables.
they are just annoyed of thier involvement as they thought, it's
vendor resp to deliver - which is also true.

I agree that we should go one team at a time - but what if we don't
do the transition at root (customer approach towards agile and its
commitment) - that would eventually doom to fail subsequnt
opportunities. In a service industry where one should bring high
competitive offering is questioned serriously when you can't delvier
what you have committed.

I like the approach which Pete said that we need to have some kind of
mutual agreement or a contract put inplace upfront to have sort of
MSA - master agreement!

--- In Scrum-India@yahoogroups.com, Vikrama Dhiman <vickydhiman@...>
wrote:
>
> Hello Selvan:
>
> Transitioning to Agile is generally slow. Below assumes a "service
industry" scenario.
>
> One of the mistakes you could do is converting whole organization
at one go. What I'd recommend is going one team at a time [and let
one team *really* get it]. Its difficult selling this to a management
looking at quick fix solutions - but I think you'd get a better
success by implementing it team by team.
>
> Some of the things you will need to keep in mind [would help]:
>
>    Try and do the first projects in Scrum using time and materials
basis and not fixed price [this is because welcoming change gets
interpreted without the discipline aspect really sinking in at both
the team and product owner end]
>    Try and use some XP engineering practices by the book
>    Do Scrum by the book
>    Have an on-site Scrum coach/ consultant
>    If you do want to do Scrum on a fixed price project, try and
quote only for one release at a time and keep one release small
enough to be able to estimate
>    Do it on a domain you are most comfortable with
>
> Hope that helps!
>
> Thanks
>
> Pete Deemer <petedeemer@...> wrote:
Selvan, let's say another client came to you tomorrow, saying "we'd
>  like to try scrum".  based on your lessons learned below, what are
the
>  5 (or however many you like) things on your checklist, that you
would
>  want to make sure you did, to set you and your client up for
success?
>  What I have in mind are very practical steps you could take.
>
>  for example, I've seen some teams actually come up with a scrum
>  "contract" with the client.  it's not really a contract, it's just
a
>  piece of paper laying out the groundrules of how we're going to do
>  scrum, but it's really helpful in surfacing areas where the client
>  either "understand scrum differently" (the polite way to say it!)
or
>  is unsure of whether they're going to be able to commit.
obviously,
>  you have to be careful about this -- they're the client, after
all --
>  so you want to make sure they understand you're doing this not to
be
>  difficult or demanding, but because you want to see the project
succeed.
>
>  I'd love to hear what other people would put on their checklist,
based
>  on their experiences...
>
>  --p
>
>  --- In Scrum-India@yahoogroups.com, "Kalaiselvan" <selmaks@> wrote:
>  >
>  > All
>  > I welcome all to this forum and I personaly thank Pete for his
>  > initiative on this to bring all people together to discuss,
debate on
>  > Agile dev.
>  >
>  > To share my experience, I've seen many people taling about Agile
>  > thinking that it's another software dev process like 'waterfall'
and
>  > take it light to acknowledge that it's good and we will
implement
>  > successfully etc while selling solutions to customer ( it could
be
>  > internal/external). That's a great misjudgement - or to be
honest the
>  > person who claims so haven't understood the difficulty in making
>  > agile development success.
>  >
>  > yes it is indeed another dev process - but more matured, mor
epainful
>  > to implement and requires lot of decipline.
>  >
>  > I've a bitter experience where I had tough changing the mindset
of my
>  > client to transition to Agile though they have been following
>  > waterfall ( or some thier own way of doing things design-dev-
test
>  > etc). In the end, we failed to show case the credibility of
agile
>  > development ( it goes with many valid reasons but i think it's
out of
>  > discussino here) and customer insisting going back to his dev
>  > process.
>  >
>  > lessons learned was
>  > 1. agile is not for every customer engagment / project
>  > 2. approach customer transition more transparent and better
>  > commitment and involvement from customer team (upper mgt from
>  > customer)
>  > 3. requires lot of decipline and no compramise on 'agile' way of
>  > doing things
>  > 4. need right people in the team who could understand and
appreciate
>  > the value of doing in 'agile' way
>  > 5. technology choice to hande many aspects of agile dev (
TDD,Pair
>  > programming, incremental design and dev etc)
>  > 6. proper role players upfront and commitment from project
>  > stakeholders
>  > 7. identify artifacts that are relevant upfront
>  > 8. enrichment of agile way of doing things which gives
success.....
>  >
>  > Looking forward to others to share such experience here
>  >
>  > you are welcome ---- all the best!
>  >
>  > thanks
>  > Selvan
>  >
>
>
>
>
>
>
> ---------------------------------
> Never miss a thing.   Make Yahoo your homepage.
>

Hi,

  Where ever majority of team members are in same
  location, have a face-to-face Scrum and request other
members to participate through polycom and make sure
all the guys participate either directly or through
phone.

In either case , you might use collaboration tools
like wiki (I find Twiki very helpful)  to let everyone
answer the basic SCRUM questions , this very helpful
specially when team is new to SCRUM,  this helps team
members  articulate answers in clear and concise way
during face to face SCRUM meeting.

Regards
Sindhurakshit


--- Jayaprakash P <jayaprakash.puttaswamy@...>
wrote:

> Hi guys,
>
> You guys might already be aware of the issues
> concerned with DAILY
> SCRUM when your development teams are distributed in
> multiple Time
> zoned locations. Which do you think is the most
> effective way for
> DAILY SCRUMS?
>
> a) Where ever majority of team members are in same
> location, have a
> face-to-face Scrum and request other members to
> participate through
> e-scrum by answering the standard Scrum questions.
>
> b) Do an e-scrum for all the team members
>
> c) Use the polycom and make sure all the guys
> participate either
> directly or through phone instead of e-scrum.
>
> Regards,
> Jay
>
>



      
________________________________________________________________________________\
____
Never miss a thing.  Make Yahoo your home page.
http://www.yahoo.com/r/hs

Hi guys,

You guys might already be aware of the issues concerned with DAILY
SCRUM when your development teams are distributed in multiple Time
zoned locations. Which do you think is the most effective way for
DAILY SCRUMS?

a) Where ever majority of team members are in same location, have a
face-to-face Scrum and request other members to participate through
e-scrum by answering the standard Scrum questions.

b) Do an e-scrum for all the team members

c) Use the polycom and make sure all the guys participate either
directly or through phone instead of e-scrum.

Regards,
Jay

Hi everyone,

 

We recently did a successful scrum implementation for one of our projects and after a dozen sprints or so, deployed a major release.

 

The subsequent two sprints after the release were more "cooled down", with focus more on PBIs like performance tuning a particular part of the application, fixing bugs that were deferred before the release, doing R&D on a technology that could be possibly used in the next release, taking up the backlog of automated GUI tests and code review tasks (those that couldn't be finished before the release due to shortage of time)  ... in order words, with no visibile features coming out of the "shippable build" at the end of the sprint.

 

The reason this is happening is because the product owner hasn't yet decided on the new features/enhancements and the priorities. This is typical in this project owning to the nature of the application we are developing (a web based e-learning software).

 

Is it a good idea to stop scrum in this case and resume with a new sprint in a couple of weeks, once we get concrete PBIs again from the PO...or keep on rolling with sprints one after the other. Do we sprint infinitely as long as the project application is being evolved and maintained?

 

Did any one of you face a similar situation?

 

Clifford

 

---

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

I agree with Vikrama when he suggests creating a success story in one or
two projects before going across to the whole organization. It also
makes sense to do scrum by the book (at least initially). If you are
already doing iterative development, there are chances that some of the
concepts are currently being applied. But the real benefits come from
Scrum only when you follow all the aspects together, like insistance on
a single person managing the backlog, no change accepted once a sprint
starts, daily updation and visibility of progress etc.


--- In Scrum-India@yahoogroups.com, Vikrama Dhiman <vickydhiman@...>
wrote:
>
> Hello Selvan:
>
> Transitioning to Agile is generally slow. Below assumes a "service
industry" scenario.
>
> One of the mistakes you could do is converting whole organization at
one go. What I'd recommend is going one team at a time [and let one team
*really* get it]. Its difficult selling this to a management looking at
quick fix solutions - but I think you'd get a better success by
implementing it team by team.
>
> Some of the things you will need to keep in mind [would help]:
>
> Try and do the first projects in Scrum using time and materials basis
and not fixed price [this is because welcoming change gets interpreted
without the discipline aspect really sinking in at both the team and
product owner end]
> Try and use some XP engineering practices by the book
> Do Scrum by the book
> Have an on-site Scrum coach/ consultant
> If you do want to do Scrum on a fixed price project, try and quote
only for one release at a time and keep one release small enough to be
able to estimate
> Do it on a domain you are most comfortable with
>
> Hope that helps!
>
> Thanks
>
> Pete Deemer petedeemer@... wrote: Selvan, let's say another client
came to you tomorrow, saying "we'd
> like to try scrum". based on your lessons learned below, what are the
> 5 (or however many you like) things on your checklist, that you would
> want to make sure you did, to set you and your client up for success?
> What I have in mind are very practical steps you could take.
>
> for example, I've seen some teams actually come up with a scrum
> "contract" with the client. it's not really a contract, it's just a
> piece of paper laying out the groundrules of how we're going to do
> scrum, but it's really helpful in surfacing areas where the client
> either "understand scrum differently" (the polite way to say it!) or
> is unsure of whether they're going to be able to commit. obviously,
> you have to be careful about this -- they're the client, after all --
> so you want to make sure they understand you're doing this not to be
> difficult or demanding, but because you want to see the project
succeed.
>
> I'd love to hear what other people would put on their checklist, based
> on their experiences...
>
> --p
>
> --- In Scrum-India@yahoogroups.com, "Kalaiselvan" selmaks@ wrote:
> >
> > All
> > I welcome all to this forum and I personaly thank Pete for his
> > initiative on this to bring all people together to discuss, debate
on
> > Agile dev.
> >
> > To share my experience, I've seen many people taling about Agile
> > thinking that it's another software dev process like 'waterfall' and
> > take it light to acknowledge that it's good and we will implement
> > successfully etc while selling solutions to customer ( it could be
> > internal/external). That's a great misjudgement - or to be honest
the
> > person who claims so haven't understood the difficulty in making
> > agile development success.
> >
> > yes it is indeed another dev process - but more matured, mor
epainful
> > to implement and requires lot of decipline.
> >
> > I've a bitter experience where I had tough changing the mindset of
my
> > client to transition to Agile though they have been following
> > waterfall ( or some thier own way of doing things design-dev-test
> > etc). In the end, we failed to show case the credibility of agile
> > development ( it goes with many valid reasons but i think it's out
of
> > discussino here) and customer insisting going back to his dev
> > process.
> >
> > lessons learned was
> > 1. agile is not for every customer engagment / project
> > 2. approach customer transition more transparent and better
> > commitment and involvement from customer team (upper mgt from
> > customer)
> > 3. requires lot of decipline and no compramise on 'agile' way of
> > doing things
> > 4. need right people in the team who could understand and appreciate
> > the value of doing in 'agile' way
> > 5. technology choice to hande many aspects of agile dev ( TDD,Pair
> > programming, incremental design and dev etc)
> > 6. proper role players upfront and commitment from project
> > stakeholders
> > 7. identify artifacts that are relevant upfront
> > 8. enrichment of agile way of doing things which gives success.....
> >
> > Looking forward to others to share such experience here
> >
> > you are welcome ---- all the best!
> >
> > thanks
> > Selvan
> >
>
>
>
>
>
>
> ---------------------------------
> Never miss a thing. Make Yahoo your homepage.
>

• Try and do the first projects in Scrum using time and materials basis and not fixed price [this is because welcoming change gets interpreted without the discipline aspect really sinking in at both the team and product owner end]
• Try and use some XP engineering practices by the book
• Do Scrum by the book
• Have an on-site Scrum coach/ consultant
• If you do want to do Scrum on a fixed price project, try and quote only for one release at a time and keep one release small enough to be able to estimate
• Do it on a domain you are most comfortable with
  

Selvan, let's say another client came to you tomorrow, saying "we'd
like to try scrum". based on your lessons learned below, what are the
5 (or however many you like) things on your checklist, that you would
want to make sure you did, to set you and your client up for success?
What I have in mind are very practical steps you could take.

for example, I've seen some teams actually come up with a scrum
"contract" with the client. it's not really a contract, it's just a
piece of paper laying out the groundrules of how we're going to do
scrum, but it's really helpful in surfacing areas where the client
either "understand scrum differently" (the polite way to say it!) or
is unsure of whether they're going to be able to commit. obviously,
you have to be careful about this -- they're the client, after all --
so you want to make sure they understand you're doing this not to be
difficult or demanding, but because you want to see the project succeed.

I'd love to hear what other people would put on their checklist, based
on their experiences...

--p

--- In Scrum-India@yahoogroups.com, "Kalaiselvan" <selmaks@...> wrote:
>
> All
> I welcome all to this forum and I personaly thank Pete for his
> initiative on this to bring all people together to discuss, debate on
> Agile dev.
>
> To share my experience, I've seen many people taling about Agile
> thinking that it's another software dev process like 'waterfall' and
> take it light to acknowledge that it's good and we will implement
> successfully etc while selling solutions to customer ( it could be
> internal/external). That's a great misjudgement - or to be honest the
> person who claims so haven't understood the difficulty in making
> agile development success.
>
> yes it is indeed another dev process - but more matured, mor epainful
> to implement and requires lot of decipline.
>
> I've a bitter experience where I had tough changing the mindset of my
> client to transition to Agile though they have been following
> waterfall ( or some thier own way of doing things design-dev-test
> etc). In the end, we failed to show case the credibility of agile
> development ( it goes with many valid reasons but i think it's out of
> discussino here) and customer insisting going back to his dev
> process.
>
> lessons learned was
> 1. agile is not for every customer engagment / project
> 2. approach customer transition more transparent and better
> commitment and involvement from customer team (upper mgt from
> customer)
> 3. requires lot of decipline and no compramise on 'agile' way of
> doing things
> 4. need right people in the team who could understand and appreciate
> the value of doing in 'agile' way
> 5. technology choice to hande many aspects of agile dev ( TDD,Pair
> programming, incremental design and dev etc)
> 6. proper role players upfront and commitment from project
> stakeholders
> 7. identify artifacts that are relevant upfront
> 8. enrichment of agile way of doing things which gives success.....
>
> Looking forward to others to share such experience here
>
> you are welcome ---- all the best!
>
> thanks
> Selvan
>

Selvan, let's say another client came to you tomorrow, saying "we'd
like to try scrum".  based on your lessons learned below, what are the
5 (or however many you like) things on your checklist, that you would
want to make sure you did, to set you and your client up for success?
What I have in mind are very practical steps you could take.

for example, I've seen some teams actually come up with a scrum
"contract" with the client.  it's not really a contract, it's just a
piece of paper laying out the groundrules of how we're going to do
scrum, but it's really helpful in surfacing areas where the client
either "understand scrum differently" (the polite way to say it!) or
is unsure of whether they're going to be able to commit.  obviously,
you have to be careful about this -- they're the client, after all --
so you want to make sure they understand you're doing this not to be
difficult or demanding, but because you want to see the project succeed.

I'd love to hear what other people would put on their checklist, based
on their experiences...

--p


--- In Scrum-India@yahoogroups.com, "Kalaiselvan" <selmaks@...> wrote:
>
> All
> I welcome all to this forum and I personaly thank Pete for his
> initiative on this to bring all people together to discuss, debate on
> Agile dev.
>
> To share my experience, I've seen many people taling about Agile
> thinking that it's another software dev process like 'waterfall' and
> take it light to acknowledge that it's good and we will implement
> successfully etc while selling solutions to customer ( it could be
> internal/external). That's a great misjudgement - or to be honest the
> person who claims so haven't understood the difficulty in making
> agile development success.
>
> yes it is indeed another dev process - but more matured, mor epainful
> to implement and requires lot of decipline.
>
> I've a bitter experience where I had tough changing the mindset of my
> client to transition to Agile though they have been following
> waterfall ( or some thier own way of doing things design-dev-test
> etc). In the end, we failed to show case the credibility of agile
> development ( it goes with many valid reasons but i think it's out of
> discussino here) and customer insisting going back to his dev
> process.
>
> lessons learned was
> 1. agile is not for every customer engagment / project
> 2. approach customer transition more transparent and better
> commitment and involvement from customer team (upper mgt from
> customer)
> 3. requires lot of decipline and no compramise on 'agile' way of
> doing things
> 4. need right people in the team who could understand and appreciate
> the value of doing in 'agile' way
> 5. technology choice to hande many aspects of agile dev ( TDD,Pair
> programming, incremental design and dev etc)
> 6. proper role players upfront and commitment from project
> stakeholders
> 7. identify artifacts that are relevant upfront
> 8. enrichment of agile way of doing things which gives success.....
>
> Looking forward to others to share such experience here
>
> you are welcome ---- all the best!
>
> thanks
> Selvan
>

All
I welcome all to this forum and I personaly thank Pete for his
initiative on this to bring all people together to discuss, debate on
Agile dev.

To share my experience, I've seen many people taling about Agile
thinking that it's another software dev process like 'waterfall' and
take it light to acknowledge that it's good and we will implement
successfully etc while selling solutions to customer ( it could be
internal/external). That's a great misjudgement - or to be honest the
person who claims so haven't understood the difficulty in making
agile development success.

yes it is indeed another dev process - but more matured, mor epainful
to implement and requires lot of decipline.

I've a bitter experience where I had tough changing the mindset of my
client to transition to Agile though they have been following
waterfall ( or some thier own way of doing things design-dev-test
etc). In the end, we failed to show case the credibility of agile
development ( it goes with many valid reasons but i think it's out of
discussino here) and customer insisting going back to his dev
process.

lessons learned was
1. agile is not for every customer engagment / project
2. approach customer transition more transparent and better
commitment and involvement from customer team (upper mgt from
customer)
3. requires lot of decipline and no compramise on 'agile' way of
doing things
4. need right people in the team who could understand and appreciate
the value of doing in 'agile' way
5. technology choice to hande many aspects of agile dev ( TDD,Pair
programming, incremental design and dev etc)
6. proper role players upfront and commitment from project
stakeholders
7. identify artifacts that are relevant upfront
8. enrichment of agile way of doing things which gives success.....

Looking forward to others to share such experience here

you are welcome ---- all the best!

thanks
Selvan