Dan Rawsthorne | 1 Oct 01:17 2008

Re: Re: Agile Specification?

Actually, we (us use case guys, including Ivar) recommended against it.

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan <at> danube.com, 425-269-8628

woynam wrote:
>
>
> You're talking about how a use case is modeled within the UML
> meta-model, as a stereotype of a class.
>
> However, I don't recall him saying that one should map a use case to a
> single application class within your application design.
>
> If anyone actually did that, well then they got what they deserved. :-)
>
> Mark
>
> --- In scrumdevelopment <at> yahoogroups.com 
> <mailto:scrumdevelopment%40yahoogroups.com>, Dan Rawsthorne
> <dan.rawsthorne <at> ...> wrote:
> >
> > Actually, no. The Use Case was a Class, the Scenarios were the
> > instances. And, to be more specific, in the UML the Use Case was a
> > Classifier, which was an abstraction of Class. Then the implementation
> > of a scenario was described with these other classes, the boundary,
> > controller, entity, I think. It got a little carried away... but made
> > for some pretty diagrams
> >
(Continue reading)

Dan Rawsthorne | 1 Oct 01:18 2008

Re: Re: Outsource Scrum

So would I, Ron. The PO is the "single wringable neck" and leaving 
him/her out of anything is just bad behavior.

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan <at> danube.com, 425-269-8628

Ron Jeffries wrote:
>
> Hello, caike. On Tuesday, September 30, 2008, at 4:18:47 PM, you
> wrote:
>
> > I guess the only time the Scrum Master should act as a proxy PO
> > would be *during the sprint*, by not letting any external
> > influences interfere with the team.
>
> > I donĀ“t think inviting the PO for the Daily Scrums is also a good idea,
> > since he may be tempted to interfere.
>
> > Besides that, your participation as the PO on the other meetings is a
> > key-element to the success of Scrum.
>
> To me it seems ludicrous to exclude the PO at any time. They know
> things only they know; they hold the keys to the projects success;
> they are likely the single most powerful person on the project; they
> can probably get it cancelled if they want to.
>
> If I were the PO and I were excluded, I would terminate the project.
> I'm that kind of guy.
>
(Continue reading)

Mike Vizdos | 1 Oct 01:25 2008
Picon

Re: Outsource Scrum

Time for you to hop on a plane?

Thank you,

- Mike Vizdos
  Vizdos Enterprises, LLC
  
 Contact Information

          Web:      www.implementingscrum.com
                          www.michaelvizdos.com

  AOL IM:  MikeV Work
         &nbsp ;Twitter:   mvizdos
          Skype:    mvizdos
          Phone:   +1 619-709-1716
          Fax:         +1 425-675-7296

PS: Come to one of my workshops.  Visit michaelvizdos.com/enroll.

PPS: Visit implementingscrum.com/subscribe.  Receive 2 FREE videos.

On Sep 26, 2008, at 2:25 PM, wfc_85283 wrote:

I work for a small company. Prior to my arrival, the owner contracted
our development to a company in Mexico. I was hired to manage the
project. The outfit in Mexico informed me that they develop using the
Scrum framework. I am new to Scrum, I've spent the last 4 weeks
educating myself on Scrum.

I have the responsibility to ensure that the system meets requirements
and that the final product is a system that is maintainable and one
that can grow with the changing needs of the business.

I am the Product Owner. I have given the folks in Mexico a
Waterfall-ish requirements document and the Product Backlog containing
the user stories. 

I'm concerned because the outsourci ng firm has shown little interest
in getting to know our business model. I have received no questions
or feedback on the documents that I gave them. They have indicated
that although I am the Product Owner, I will not be involved in the
Sprint Planning meeting, the Sprint Review nor will I be invited to
the daily Scrums.

I thought Scrum called for more communication, not less. I thought
Scrum called for a Team that possessed a strong business knowledge.

Our firs t Sprint is scheduled to start on Monday. I'm really at a
loss as to how to continue. It seems obvious to me that they are
clueless but being new to Scrum I'm not so sure.

All comments are welcome. Thanks in advance for your input.

Bill


__._,_.___


Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Cory Foy | 1 Oct 04:22 2008

Re: Application Framework and database design

Hi Bill,

wfc_85283 wrote:
> I'm new to Scrum so please be patient.

We've all been there. Literally. Well, maybe not Ken, since he would 
have been an old hat as soon as he designed it. But, for sure, the rest 
of us.

> Being an old waterfall guy, I'm accustomed to planning the application
> framework (common objects, inheritance structure, error processing,
> ect.) and designing the database up front.

One of the common misconceptions I see often is that a move from 
waterfallish practices to agilish practices also means going from Big 
Design Up Front (BDUF) to No Design Up Front (NDUF).

The good thing is that it isn't true. Design up-front is encouraged - 
you don't throw away your thinking cap. What you are encouraged to do is 
do just enough architecture work. The balance can be tough to achieve 
sometimes. The easiest way to think of it comes from the Toyota System.

Designing and cutting the dies that were used to make the cars was one 
of the most vital (and expensive) parts of the process. In the U.S., the 
manufacturers would freeze the design, and then send it to the die 
cutters. This meant that any changes after the fact would be quite 
expensive - possibly resulting in the die having to be recreated.

However, in Toyota, the designers worked closely with the die cutters, 
who had the expertise to know which parts of the die were likely to 
change. As such, they could work somewhat in parallel so that the final 
die was completed very rapidly after the final design.

In a similar way, you want to design the architecture so that it meets 
your needs, but stay agile enough to be able to have changes happen in 
both sides.

> To add to the complexity, we are outsourcing the development.  I am
> the Product Owner.  The Scrum Master and the Team are outsourced and
> do not have strong industry knowledge or a good understanding of our
> day to day operations.

This will be a large challenge for you. What this means is that the 
traditional communication fostered by an onsite team will be lost. There 
are a couple of things that I would highly recommend:

- Frequent calls. They should be able to reach you any time they are 
working if they have a question - and should be encouraged to contact you.

- Webcams - One of the best investments I've made with remote teams is 
each end having a webcam. They can call on the phone, and you all can 
stare at each other through it. It's amazing, and quite underrated, how 
much of an impact this can have

- Daily Stand-Ups - The trick here is making sure that the team you are 
working with is highly encouraged to report failures and successes. The 
number one issue I run into with outsourced teams is a fear of reporting 
bad news, or things that are blocking them. This may be because they 
want the contract, or may be an aspect of their culture. Become very 
aware when they always say every thing is rosy.

> Our application incorporates 24 functional areas.  It is my
> understanding that each Sprint within the Scrum addresses a functional
> area or a subset of the stories within a functional area.  

The goal of each Sprint is for the team to deliver Running, Tested 
Features (http://www.xprogramming.com/xpmag/jatRtsMetric.htm). The work 
they do is dictated by your prioritization based on the business value - 
the highest business value items should come first.

> It sounds to me like we are going to end up with a bunch of objects
> pieced together and a database that is not all that relational.  Or as
> each new Sprint is implemented, we will need to rework other functions
> and redesign the database.

It is possible that an aspect of a story in a Sprint will cause a change 
to an earlier completed feature. However, unless you were one of the 
rare success stories I've heard of with Waterfall, it's likely that you 
all still had rework that happened there.

As far as the design and architecture - it's the responsibility of you 
and the team not to work in a silo, but be cognizant of the details of 
other stories around you. While stories should avoid being dependent on 
each other, you all should stay aware of stories that are related and 
should be completed together.

I'd also recommend looking at the User Stories Applied book by Mike Cohn 
(http://www.mountaingoatsoftware.com/books), and the Agile Databases 
book by Scott Ambler 
(http://www.ambysoft.com/books/agileDatabaseTechniques.html)

> I've got the User Stories for the first Sprint complete and the Team
> wants to get started.  Are we missing a step?  

Yes. Get started. ;) You can always adjust as you go, and you can always 
ask us here for help, or advice.

-- 
Cory Foy
http://www.cornetdesign.com
http://www.agileflorida.com

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! 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:
    mailto:scrumdevelopment-digest <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Roy Morien | 1 Oct 06:10 2008
Picon

RE: Application Framework and database design

Well, my view is that, if you have some User Stories already, you can immediately get going on development (including stipulating appropriate 'relational' structures), and at the same time you can start planning future iterations and releases.
 
I am always interested especially in why people felt (and still find) it necessary and desirable to develop the database schema fully up-front. I woild also be interested in knowing why you have changed your position on this. As long ago as 1992 I published  
an approach that I called Focal Entity Prototyping. Focal as in focusing on one entity (or relationship) and moving that through a development cycle of Entity Definition -> Table Definition -> Table Construction -> Data Form Construction (& reports and queries) and deliver that system component immediately. I have found this approach simple, effective and fast (and apparently rather puzzling to many practitioners and students alike).
 
It is interesting, from my experience in teaching at university level, that students are always so keen to rush ahead with defining the database schema on paper, and usually without the benefit of an entity modelling activity first. They seem so loath to do this vertical slicing and actually develop some working software. I find students to be great 'lab rats' who seem to find any and every way to defy good practice ... a bit like a slightly extreme example of development in industry :)
 
So ... grasp the nettle, as they say, and start delivering ... or insist on the outsourced developers to start delivering NOW!!
 
Regards,
Roy Morien




To: scrumdevelopment <at> yahoogroups.com
From: garvinpromo <at> gmail.com
Date: Tue, 30 Sep 2008 17:30:02 +0000
Subject: [scrumdevelopment] Application Framework and database design


I'm new to Scrum so please be patient.

Being an old waterfall guy, I'm accustomed to planning the application
framework (common objects, inheritance structure, error processing,
ect.) and designing the database up front.

To add to the complexity, we are outsourcing the development. I am
the Product Owner. The Scrum Master and the Team are outsourced and
do not have strong industry knowledge or a good understanding of our
day to day operations.

Our application incorporates 24 functional areas. It is my
understanding that each Sprint within the Scrum addresses a functional
area or a subset of the stories within a functional area.

It sounds to me like we are going to end up with a bunch of objects
pieced together and a database that is not all that relational. Or as
each new Sprint is implemented, we will need to rework other functions
and redesign the database.

I've got the User Stories for the first Sprint complete and the Team
wants to get started. Are we missing a step?

Thanks in advance for your help.

Bill


.ExternalClass #EC_ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;padding:0px 14px;} .ExternalClass #EC_ygrp-mkp hr {border:1px solid #d8d8d8;} .ExternalClass #EC_ygrp-mkp #EC_hd {color:#628c2a;font-size:85%;font-weight:bold;line-height:122%;} .ExternalClass #EC_ygrp-mkp #EC_ads {margin-bottom:10px;} .ExternalClass #EC_ygrp-mkp .EC_ad {padding:0 0;} .ExternalClass #EC_ygrp-mkp .EC_ad a {color:#0000ff;text-decoration:none;} .ExternalClass #EC_ygrp-sponsor #EC_ygrp-lc {font-family:Arial;} .ExternalClass #EC_ygrp-sponsor #EC_ygrp-lc #EC_hd {font-weight:bold;font-size:78%;line-height:122%;} .ExternalClass #EC_ygrp-sponsor #EC_ygrp-lc .EC_ad {margin-bottom:10px;padding:0 0;} .ExternalClass #EC_ygrp-mlmsg {font-size:13px;font-family:arial,helvetica,clean,sans-serif;} .ExternalClass #EC_ygrp-mlmsg table {font-size:inherit;font:100%;} .ExternalClass #EC_ygrp-mlmsg select, .ExternalClass input, .ExternalClass textarea {font:99% arial,helvetica,clean,sans-serif;} .ExternalClass #EC_ygrp-mlmsg pre, .ExternalClass code {font:115% monospace;} .ExternalClass #EC_ygrp-mlmsg EC_* {line-height:1.22em;} .ExternalClass #EC_ygrp-text {font-family:Georgia;} .ExternalClass #EC_ygrp-text p {;} .ExternalClass #EC_ygrp-tpmsgs {font-family:Arial;clear:both;} .ExternalClass #EC_ygrp-vitnav {padding-top:10px;font-family:Verdana;font-size:77%;} .ExternalClass #EC_ygrp-vitnav a {padding:0 1px;} .ExternalClass #EC_ygrp-actbar {clear:both;white-space:nowrap;color:#666;text-align:right;} .ExternalClass #EC_ygrp-actbar .EC_left {float:left;white-space:nowrap;} .ExternalClass .EC_bld {font-weight:bold;} .ExternalClass #EC_ygrp-grft {font-family:Verdana;font-size:77%;padding:15px 0;} .ExternalClass #EC_ygrp-ft {font-family:verdana;font-size:77%;border-top:1px solid #666;padding:5px 0;} .ExternalClass #EC_ygrp-mlmsg #EC_logo {padding-bottom:10px;} .ExternalClass #EC_ygrp-reco {margin-bottom:20px;padding:0px;} .ExternalClass #EC_ygrp-reco #EC_reco-head {font-weight:bold;color:#ff7900;} .ExternalClass #EC_reco-grpname {font-weight:bold;} .ExternalClass #EC_reco-category {font-size:77%;} .ExternalClass #EC_reco-desc {font-size:77%;} .ExternalClass #EC_ygrp-vital {background-color:#e0ecee;margin-bottom:20px;padding:2px 0 8px 8px;} .ExternalClass #EC_ygrp-vital #EC_vithd {font-size:77%;font-family:Verdana;font-weight:bold;color:#333;text-transform:uppercase;} .ExternalClass #EC_ygrp-vital ul {padding:0;} .ExternalClass #EC_ygrp-vital ul li {list-style-type:none;clear:both;border:1px solid #e0ecee;} .ExternalClass #EC_ygrp-vital ul li .EC_ct {font-weight:bold;color:#ff7900;float:right;width:2em;text-align:right;padding-right:.5em;} .ExternalClass #EC_ygrp-vital ul li .EC_cat {font-weight:bold;} .ExternalClass #EC_ygrp-vital a {text-decoration:none;} .ExternalClass #EC_ygrp-vital a:hover {text-decoration:underline;} .ExternalClass #EC_ygrp-sponsor #EC_hd {color:#999;font-size:77%;} .ExternalClass #EC_ygrp-sponsor #EC_ov {padding:6px 13px;background-color:#e0ecee;margin-bottom:20px;} .ExternalClass #EC_ygrp-sponsor #EC_ov ul {padding:0 0 0 8px;} .ExternalClass #EC_ygrp-sponsor #EC_ov li {list-style-type:square;padding:6px 0;font-size:77%;} .ExternalClass #EC_ygrp-sponsor #EC_ov li a {text-decoration:none;font-size:130%;} .ExternalClass #EC_ygrp-sponsor #EC_nc {background-color:#eee;margin-bottom:20px;padding:0 8px;} .ExternalClass #EC_ygrp-sponsor .EC_ad {padding:8px 0;} .ExternalClass #EC_ygrp-sponsor .EC_ad #EC_hd1 {font-family:Arial;font-weight:bold;color:#628c2a;font-size:100%;line-height:122%;} .ExternalClass #EC_ygrp-sponsor .EC_ad a {text-decoration:none;} .ExternalClass #EC_ygrp-sponsor .EC_ad a:hover {text-decoration:underline;} .ExternalClass #EC_ygrp-sponsor .EC_ad p {;} .ExternalClass EC_o {font-size:0;} .ExternalClass .EC_MsoNormal {;} .ExternalClass #EC_ygrp-text tt {font-size:120%;} .ExternalClass blockquote {;} .ExternalClass .EC_replbq {;}
__._,_.___

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
George Dinwiddie | 1 Oct 13:29 2008

Re: Application Framework and database design

Bill, you've already gotten some good advice, so I'll just concentrate 
on this item:

wfc_85283 wrote:
> Our application incorporates 24 functional areas.  It is my
> understanding that each Sprint within the Scrum addresses a functional
> area or a subset of the stories within a functional area.

I'm not completely sure I understand your meaning, but this sounds 
suspiciously like a phased waterfall approach, to me.  It sounds as if 
you're thinking of working module by module, working to finish each 
before proceeding to the next.

I would suggest that you take a more holistic view, generating an entire 
application, even though it initially does little more than show that 
it's there.  Having all the functional areas represented in the 
fledgling app will help the developers drive a reasonable first approach 
to the schema and architecture.

Then start to flesh out the functions, in business priority order, 
switching between functional areas as appropriate.  These will add 
elaborations to the schema and architecture, but the need to "rip out 
and redesign" should be gone.

There's an art to seeing how your application can grow in this way. 
It's a very different point of view than envisioning building it, 
starting at one end and proceeding to the other.  But working in this 
way provides a lot of benefits.  One of the important ones is that you, 
the Product Owner, can see at the end of first iteration whether it 
appears that the "walking skeleton" of the application is likely to have 
the right shape to carry the full weight by the end.

  good luck,
    George

-- 
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! 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:
    mailto:scrumdevelopment-digest <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Joseph Little | 1 Oct 14:38 2008
Picon

Re: Outsource Scrum

Hi,

As others are telling you, the outsource firm has misunderstood Scrum.
 This is common (all the reasons why would take too long to tell).

Assume positive intent on their part.  And tell 'em all those folks on
ScrumDev said the way to play is that the PO plays with the Team. 
Show 'em the book, etc.

Action items: 
1. Talk to your CEO. Get him/her prepared that if they don't change
their minds, this is too stupid a situation.
2. Get on a plane and visit them (see Mike Vizdos' suggestion
earlier).  Talk face to face.

Then inspect and adapt.

It is likely you will be forced to make a tough decision: do I stay
(in this broken relationship) or do I go?  It will improve
somewhat...but how much?? Enough??  Fast enough??

Talk to them about why they DON'T want you around. Talk to them about
why you WANT to be around. Show some consideration for their views,
but, if you have the time to play (and meet other criteria of a PO)
than you basically are right.

On their side, one underlying reason (typically) is they don't want to
show you their imperfections. (And maybe you don't want to show
yours?!?!)  Anyway, it's a normal human feeling; give 'em a way to
adjust into that.

Note: Listen for the meaning beneath their words.  

On their side, it is also pretty likely that someone, somewhere in the
past, had a relationship with a client where their "approach" seemed
the best solution. Just because it's dumb does not mean it wasn't "the
best of all possible worlds" at that time.  Maybe 3 years ago with a
different client...who knows.

PO: an easy job, right?  (By which I partly mean that it is
extraordinarily normal for the Team not to know how to play with the
PO at first, and vice versa.)

Best regards, Joe

--- In scrumdevelopment <at> yahoogroups.com, "wfc_85283" <garvinpromo <at> ...>
wrote:
>
> I work for a small company.  Prior to my arrival, the owner contracted
> our development to a company in Mexico. I was hired to manage the
> project.  The outfit in Mexico informed me that they develop using the
> Scrum framework.  I am new to Scrum, I've spent the last 4 weeks
> educating myself on Scrum.
> 
> I have the responsibility to ensure that the system meets requirements
> and that the final product is a system that is maintainable and one
> that can grow with the changing needs of the business.
> 
> I am the Product Owner.  I have given the folks in Mexico a
> Waterfall-ish requirements document and the Product Backlog containing
> the user stories.  
> 
> I'm concerned because the outsourcing firm has shown little interest
> in getting to know our business model.  I have received no questions
> or feedback on the documents that I gave them.  They have indicated
> that although I am the Product Owner, I will not be involved in the
> Sprint Planning meeting, the Sprint Review nor will I be invited to
> the daily Scrums.
> 
> I thought Scrum called for more communication, not less.  I thought
> Scrum called for a Team that possessed a strong business knowledge.
> 
> Our first Sprint is scheduled to start on Monday.  I'm really at a
> loss as to how to continue.  It seems obvious to me that they are
> clueless but being new to Scrum I'm not so sure.
> 
> All comments are welcome.  Thanks in advance for your input.
> 
> Bill
>

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! 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:
    mailto:scrumdevelopment-digest <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

woynam | 1 Oct 16:24 2008

Re: Application Framework and database design


Yes, I understand. :-)

The 2 key aspects of agility are 1) prioritize features based on
business value, and 2) inspect and adapt.

As Product Owner, you get to choose the priority of the features. When
we consider business value, we typically assume functional
requirements. However, in many cases there may be non-functional
requirements, e.g. maintainability, that have the highest business
value. You certainly don't want to build a system that can't be
maintained. It might give you some immediate value, but it will cost
you long term.

Thus, you should select a small set of features that really stress the
architecture of the system. In RUP, one builds an architectural
prototype to prove that the selected architecture will work. With
Scrum, we don't typically build throw-away prototypes, but we can
certainly build a small part of the actual system that highlights the
architecture.

By focusing on this initially, you'll get to see a portion of the
relational schema early, and determine if it suits your long-term
needs. If not, you can adjust, or can the project and start over.

Of course, building only a part of the system may require that you
leave out important business functionality initially. While one should
always strive to build deploy-able software, it may take a few Sprints
to build enough functionality to be useful, i.e. a release.

Mark

--- In scrumdevelopment <at> yahoogroups.com, "wfc_85283" <garvinpromo <at> ...>
wrote:
>
> > >
> >
> Thanks Mark.  I definitely know that there are issues with the
> outsourcing firm. It's a situation that I inherited.
> 
> I'm just trying to refine my understanding of Scrum.
>

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! 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:
    mailto:scrumdevelopment-digest <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

woynam | 1 Oct 16:29 2008

Re: Outsource Scrum


Actually, it does sound like Scum(tm). :-) Scum(tm) should not be
confused with Scrum, however.

Scum(tm) was invented by 'ol PMBOK types to confuse people. You really
do need to see the contract to determine if it says the team would use
Scum(tm) or Scrum.

In Scum(tm), PO doesn't stand for Product Owner. It stands for P*ss Off.

Mark 

--- In scrumdevelopment <at> yahoogroups.com, "Bill Campbell"
<garvinpromo <at> ...> wrote:
>
> I agree, it doesn't sound like Scum to me either.  Being new to Scrum I
> thought maybe I was missing something,
> 
> Thanks.
> 
> On Sat, Sep 27, 2008 at 6:38 AM, Doug McQuilken <dougmcq000 <at> ...>wrote:
> 
> >   Hmmm............. if there is no transparency how would you know
whether
> > they utilized scrum methodology?
> >
> > Regards,
> > Doug
> >
> > --- On *Sat, 9/27/08, George Dinwiddie <lists <at> ...>* wrote:
> >
> > From: George Dinwiddie <lists <at> ...>
> > Subject: Re: [scrumdevelopment] Outsource Scrum
> > To: scrumdevelopment <at> yahoogroups.com
> > Date: Saturday, September 27, 2008, 12:06 AM
> >
> >  wfc_85283 wrote:
> > > I work for a small company. Prior to my arrival, the owner
contracted
> > > our development to a company in Mexico. I was hired to manage the
> > > project. The outfit in Mexico informed me that they develop
using the
> > > Scrum framework. I am new to Scrum, I've spent the last 4 weeks
> > > educating myself on Scrum.
> >
> > How often are they to deliver working code to you?
> >
> > Do you have access to the contract to see what they are obligated
to do?
> > It may well be that their mention of Scrum has nothing to do with
> > their relationship with their clients.
> >
> > - George
> >
> > --
> > ------------ --------- --------- --------- --------- --------- -
> > * George Dinwiddie * http://blog. gdinwiddie.
com<http://blog.gdinwiddie.com>
> > Software Development http://www.idiacomp
uting.com<http://www.idiacomputing.com>
> > Consultant and Coach http://www.agilemar
yland.org<http://www.agilemaryland.org>
> > ------------ --------- --------- --------- --------- --------- -
> >
> >   
> >
>

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! 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:
    mailto:scrumdevelopment-digest <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

kaverjody | 1 Oct 16:43 2008

change item description during sprint plus measure teams by velocity

I faced a situation that two behaviours as the title happened
together, I do not like that, it make things worse.

- First one is, the contents of items change during sprints sometimes.
The problem is, when we take the item, the target is a bit vague, e.g.
it says to implement certain functionality on one OS delivery
(embedded). But, the situation is there are several versions /
revisions of OS, in the beginning we were working on r1, and we would
be on r2 during sprint, and the project expected to have functionality
against r3 at the end. Then at the end, we realized that PO's
expectation is different from teams'.

- Second is, PO wants to promote good teams (we scrum masters want
also), so an evaluation form was developed to find the star team from
teams, one estimate is the velocity.

Theoretically, above two situations are fine, coz first one could due
to insufficient communication between PO and team, second one should
be able to work.

Whereas it leads to a wrong direction. There are some different
interpretations on related teams, consider the OS contains two
different parts, e.g. startup and some device drivers. The team who
relies on the startup part was considered DONE their work against the
unworking r3. Other teams are not, because their dependent driver part
was not ready, so they were not DONE against the target OS r3.

- My feeling is it's not fair. Teams working together to contribute to
business values, their productions together provides business values,
instead of single alone. An OS v3 with startup enabled but
misfunctionalities related to drivers is meaningless and useless to users.

The measurement on teams by comparing velocity make things worse. If
it's not fair to calculate their productivity, how can we compare
their velocity? Also I insist that we should compare the velocity
change of one team as a feedback for teams to be better, but comparing
velocity between teams are bad. Promoting star teams in such a
situation may not achieve the goal to value good teams, instead it may
to non-productive competition on fake velocity number.

I have some ideas, but I'd like to know yours too.

------------------------------------

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! 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:
    mailto:scrumdevelopment-digest <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/


Gmane