Jeff | 1 Mar 02:24 2006
Picon
Picon

Sprint retrospective meeting question...


I have a question about the SECOND part of the sprint retrospective meeting.

I see that most training allows only "pigs" to attend the retrospective
meeting; 
i.e. the Product Owner is NOT allowed to attend.
(I view this is a good thing.)

Why is it not acceptable for the Product Owner to attend?   

What about other non-team members attending?    E.g. management?

(I'm expecting there can be psychological issues if 
management or other members of the company attend.  E.g. the 
Team does not get the opportunity to have an open meeting to 
discuss any issue.  I fear such a meeting will not be 
viewed as something "for the Team's benefit".)

Thanks for any input.

Jeff

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
(Continue reading)

mpkirby | 1 Mar 03:04 2006
Picon

Re: Sprint Review vs Serial Report


On 28 Feb 2006 at 16:33, Thierry Thelliez wrote:

> 
> I am looking for ideas to improve our Sprint reviews. The main issue I
> see is that not all the team members are engaged in the review. The
> Sprint Review ends up being like a `Serial ReportĀ“ meeting where
> some individuals seem to be loosing their time. 

Our review format is pretty straight forward.

Agenda:

10 minutes -- Review improvements made since the last retrospective.  This is the "We 
listened" part of the meeting.  If there isn't at least one thing there, then what was the point of 
the last retrospective (or you are executing perfectly -- This hasn't happened yet).

30 minutes -- I go around the room asking each person for a constructive observation about 
the previous iteration.  It's key to get everyone to provide input.  If they can't think of 
something constructive to say, then say something positive (something that went well, that 
you'd like to see us continue doing).  During this period, I allow some discussion.  It's not a 
traditional brainstorming format.

15 minutes - I go through the list of items, and I ask folks to silently "vote" for those things 
that they feel "impacted" them the most.  I put in place the "silent" rule because I found a few 
louder individuals were "talking up" points in prior retrospectives.

I make a quick "High / Medium / Low / none" estimation based on the number of hands.  I 
circle the Highs, and we talk a bit about what we might do in the upcoming iteration to 
alleviate some of the concerns.
(Continue reading)

Ron Jeffries | 1 Mar 03:31 2006

Re: User Stories

On Tuesday, February 28, 2006, at 10:44:46 AM, p.eckert wrote:

> I have a qustion about user stories (or features, or whatever people
> wish to call them).

> Online there is a bunch of information on what makes a 'good' stoy or
> a 'bad' story, but the examples do not seem to help me much.  I do not
> have a context to put them in.

> Would any of you be willing to share with me some of your 'good'
> stories, just so I can visualize how they should look?  I would like
> to see how real stories look vs the ones I see in books and online.

There's a wide range of "good". See my remarks on Card,
Conversation, Confirmation for reasons why I find the following
stories just fine.
http://www.xprogramming.com/xpmag/EXPCardConversationConfirmation.htm

  When ATM is out of cash, display an error message until customer
  hits Enter key or for 15 seconds. Then return customer's card.

  Overtime work accrues hours at 1.5 times hours worked on any day
  except Sunday. On Sunday, hours accrue at 2 times hours worked.

  After ten days, remove a new book from the "Just Came In" display
  page on the Library Web Site.

  Customer can order paint color and interior color according to
  this table:
    PAINT   INTERIOR
(Continue reading)

Jeff | 1 Mar 04:07 2006
Picon
Picon

Scrum and XP...


Another scrum question...

The more I "do scrum" the more I suspect XP is more appropriate for applying
scrum-like methodology to developing software.

After all, scrum (afaict) embodies a lot of XP's "project methodology"
aspects, though scrum does not address any coding/programming aspects.

I'm starting to find that effective scrum requires programming models such
as TDD.  XP already has this all sorted out.

Do scrum teams end up migrating to XP?

Jeff

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

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

(Continue reading)

Ron Jeffries | 1 Mar 04:18 2006

Re: Scrum and XP...

On Tuesday, February 28, 2006, at 7:07:31 PM, Jeff wrote:

> Do scrum teams end up migrating to XP?

Many do. Much of what I've been doing lately is introducing XP
practices to Scrum teams.

The thing is that for Scrum to work, the team has to come up somehow
with technical practices that let them produce software that is
known to work by the end of each Sprint. XP offers core practices
that are a good start at doing this.

Some time ago, if I'm not mistaken, Mike Beedle talked about a blend
of XP and Scrum that he called XP <at> Scrum. More recently he has taken
the position that practices much like the XP practices have always
been a part of Scrum. That may be the case, though they aren't
mentioned in the Scrum books, as far as I know.

But primacy of invention or whose name is on the book isn't what's
important. What's important is that a Scrum team needs to come up
with some coherent and effective set of technical practices, in
order to do their jobs effectively. The XP literature offers one
convenient package of practices that are a good start.

Regards,

Ron Jeffries
www.XProgramming.com
One test is worth a thousand expert opinions.
  -- Bill Nye (The Science Guy)
(Continue reading)

Steven Gordon | 1 Mar 05:03 2006
Picon

Re: Sprint Review vs Serial Report

One way to get the shyer people more involved is to rotate the few people who will present the team's work each sprint.
 
Steven Gordon

 
On 2/28/06, Thierry Thelliez <thierry <at> acm.org> wrote:

I am looking for ideas to improve our Sprint reviews. The main issue I see is that not all the team members are engaged in the review. The Sprint Review ends up being like a 'Serial Report' meeting where some individuals seem to be loosing their time.

 

We have many tasks and many different skill sets. It seems that some team members are so much focused into their own tasks that they pay little attention to the other tasks. There is also a (perceived) technical gap that seems to create boundaries. For example a backend developer does not seem to pay much attention to the UI work.

 

It does not seem to be so much an issue during the daily meetings since the meetings are short, although I see some of this attitude.

 

Should the team members be coached in listening more to the others? Should the tasks be designed to push more for larger participation?

 

 

Thierry Thelliez

 
 

 

YAHOO! GROUPS LINKS


Alex Pukinskis | 1 Mar 05:37 2006

Re: Sprint Review vs Serial Report

Are you doing demos of working software in your Review?  Don’t UI and backend people have to come together to make these demos actually work?

I frequently see teams spending 30 minutes to 1 hour on Sprint demos, 5 to 20 minutes on Sprint Review (usually the ScrumMaster just listing stats – work done vs. committed, defects, test coverage, build success, etc) and 30 minutes to 4 hours on the retrospective.  Is your meeting wildly different than these ranges?  Which part of the meeting are you struggling with?

-Alex

On 02 28 2006 4:33 PM, "Thierry Thelliez" <thierry <at> acm.org> wrote:

I am looking for ideas to improve our Sprint reviews. The main issue I see is that not all the team members are engaged in the review. The Sprint Review ends up being like a ‘Serial Report’ meeting where some individuals seem to be loosing their time.
 
We have many tasks and many different skill sets. It seems that some team members are so much focused into their own tasks that they pay little attention to the other tasks. There is also a (perceived) technical gap that seems to create boundaries. For example a backend developer does not seem to pay much attention to the UI work.
 
It does not seem to be so much an issue during the daily meetings since the meetings are short, although I see some of this attitude.
 
Should the team members be coached in listening more to the others? Should the tasks be designed to push more for larger participation?
 
 
Thierry Thelliez
 
 


To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com


  

 
 
SPONSORED LINKS
          
  
Scrum <http://groups.yahoo.com/gads?t=ms&k=Scrum&w1=Scrum&c=1&s=11&.sig=KvDTKhw7ncC9XbB25jdApQ>         
 
 
YAHOO! GROUPS LINKS


 



--
Alex Pukinskis - Agile Coach
Rally Software Development
http://rallydev.com/
    


SPONSORED LINKS
Scrum

YAHOO! GROUPS LINKS


kittys shu | 1 Mar 07:50 2006
Picon

what benefits can sub tasking bring to developers?

My current research is to conduct an empirical study on the effect of Scrum.
 
After several months' effort, the PM I work with finally agreed to try scrum in his project.
 
Since everything just started, there are some questions and issues appearing.
 
One of his questions is why do we do sub tasking, why don't we just end with selecting user stories for current iteration? I gave him two points as the answer: 1. sub tasking and time estimation force developers to think thoroughly what they are going to do with the user stories. So, they may find out that some stories that are originally thought feasible become not feasible so that they cannot go into the current iteration. This is good for iteration planning and results.
 
2. when we move the tasks to the "completed" list, healthy peer pressure can be achieved.
 
However, he thought these two points are more likely for management purpose.
 
How can we persuade developers to do this? Or, in other words, what are the big and obvious benefits for them to show their private working steps?
 
 

Find your next car at Yahoo! Canada Autos
YAHOO! GROUPS LINKS


Ron Jeffries | 1 Mar 10:43 2006

Re: what benefits can sub tasking bring to developers?

On Tuesday, February 28, 2006, at 10:50:24 PM, kittys shu wrote:

>   How can we persuade developers to do this? Or, in other words, what are the big and obvious
> benefits for them to show their private working steps?

I like to see the team brainstorm the technical tasks that are to be
done, but to see user stories signed up for, not tasks. (By the way
"user story" is, as far as I know, an XP term, not a Scrum term.)

Brainstorming the technical tasks is an explicit albeit small design
step and therefore it benefits the team by keeping everyone aware of
the intended design of each story, and allowing everyone to
contribute.

Signing up for stories rather than tasks keeps the team focused on
story completion, not task completion. Thus, I prefer it.

Ron Jeffries
www.XProgramming.com
It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

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

Mishkin Berteig | 1 Mar 13:31 2006

Re: Scrum and XP...

I generally agree with what you say Ron, but many of the Scrum teams that I have coached do not have access to the incredible tools used for TDD, continuous integration, etc.  This is usually due to the technologies involved not being compatible, but sometimes can be related to corporate standards that dis-allow open-source software.  Even with these barriers, as a coach I try to find ways for the team to do these things.  Sometimes that means building our own testing harness from scratch, for example.
 
I came to Scrum via agile via XP.  I hold TDD, pair programming and other XP practices very dear to my heart.  For new software development, Scrum might be a good place to start, but XP is what makes things really hum.  When a team is doing things that aren't new software development, XP starts to make less and less sense.&n bsp; A recent database migration project I was coaching had no need for some of the engineering practices that XP sets up.  Likewise for a software system upgrade project.  Both of those were done essentially using Scrum with some minor modifications.  And unfortunately (for little me who likes XP) there was no reasonable way to introduce XP practices given the various constraints.
 
Mishkin Berteig


Ron Jeffries <ronjeffries <at> XProgramming.com> wrote:
On Tuesday, February 28, 2006, at 7:07:31 PM, Jeff wrote:

> Do scrum teams end up migrating to XP?

Many do. Much of what I've been doing lately is introducin g XP
practices to Scrum teams.

The thing is that for Scrum to work, the team has to come up somehow
with technical practices that let them produce software that is
known to work by the end of each Sprint. XP offers core practices
that are a good start at doing this.

Some time ago, if I'm not mistaken, Mike Beedle talked about a blend
of XP and Scrum that he called XP <at> Scrum. More recently he has taken
the position that practices much like the XP practices have always
been a part of Scrum. That may be the case, though they aren't
mentioned in the Scrum books, as far as I know.

But primacy of invention or whose name is on the book isn't what's
important. What's important is that a Scrum team needs to come up
with some coherent and effective set of technical practices, in
order to do their jobs effectively. The XP literature offers one
convenient package of practices that are a good start.

Regards,

Ron Jeffries
www .XProgramming.com
One test is worth a thousand expert opinions.
-- Bill Nye (The Science Guy)



To Post a message, send it to: scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

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




Yahoo! Mail
Bring photos to life! New PhotoMail makes sharing a breeze.
YAHOO! GROUPS LINKS



Gmane