One possibility for a geographically
distributed daily scrum is to use the EPF newsgroup. The group leader can
create a post for the scrum for that day, and each person involved responds to
the post by answering the three questions. Others can respond to those posts by
offering advice, assistance, etc. Or, to keep it pure, responses could be via
email.
We probably wouldn’t need to do this
every day – maybe 2 or 3 times a week. And the post should go up by 9:00
AM local time for each participant.
It’s not the same as meeting
face-to-face, but it may be worth a try. And it has the advantage of being
public.
- Jim
____________________
Jim Ruehlin, IBM
Rational
RUP Content
Developer
Eclipse Process
Framework (EPF) Committer
email:
jruehlin@xxxxxxxxxx
phone:
760.505.3232
fax:
949.369.0720
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ana Valente Pereira
<apereira@xxxxxxxxxxx>
Sent: Monday, July 10, 2006 10:30
AM
To: Eclipse Process Framework
Project Developers List <epf-dev@xxxxxxxxxxx>
Subject: Re: [epf-dev] IMPORTANT:
Monday 8 AM PDT Meeting - OpenUP Refocus
Agile practices also promote daily team integration meetings, allowing
the team to coordinate their work , focus on the work to be done and
raising problems and issues ... as we are not in the same room (not even
on the same country) maybe we could send a 5 minute email every day to
each content owner addressing the 3 typical questions:
* what was done yesterday?
* what are we planning to do today?
* what impediments are in the way?
or is this too much work?
Ana
Per Kroll wrote:
>
> Hi,
>
> I like this, and this is consistent with some of the things I
> discussed with Brian last week. This would mean that we establish
> three iterations for the end game for the OpenUP component. My
> assumption is that the tool component, which I believe is on track,
> will continue as planned.
>
> Also, Chris has correctly pointed out that we should follow our own
> project mgmt process (duh), and we don't. So, I would like us to
> create an iteration plan where we are specific about what should be
> worked on, and how to measure success for each of the content area as
> well as OpenUP overall by the end of the iteration. Chris and I talked
> about spending time working on this next week.
>
> We should also start to prioritize work, as well as estimate size/effort.
>
> Cheers
>
> Per Kroll
> STSM, Manager Methods: RUP / RMC
> Project Lead: Eclipse Process Framework
> Rational Software, IBM Corp
> 408-342-3815
>
>
> *Ricardo Balduino/Cupertino/IBM@IBMUS*
> Sent by: epf-dev-bounces@xxxxxxxxxxx
>
> 07/07/2006 11:16 AM
> Please respond to
> Eclipse Process Framework Project Developers List <
epf-dev@xxxxxxxxxxx>
>
>
>
> To
> Eclipse Process Framework Project Developers List < epf-dev@xxxxxxxxxxx>
> cc
>
> Subject
> RE: [epf-dev] IMPORTANT: Monday 8 AM PDT Meeting - OpenUP Refocus
>
>
>
>
>
>
>
>
>
>
> The proposition below sounds adequate, but we need to keep in mind
> that for the iteration objectives to be accomplished (i.e., text in
> final form), we need to consider time for reviews in each iteration as
> well. As part of this, we could have everyone writing and reviewing
> each others text, or even some people only write text and some only
> review text.
>
> As long as we agree with the iterations objectives, Bugzilla could be
> revisited to reflect the plan.
>
> Ricardo Balduino
> Senior Software Engineer
>
> IBM - RUP Team | EPF Committer
> www.ibm.com/rational
> www.eclipse.org/epf
>
>
> *Jim Ruehlin/Irvine/IBM@IBMUS*
> Sent by: epf-dev-bounces@xxxxxxxxxxx
>
> 07/07/2006 09:05 AM
> Please respond to
> Eclipse Process Framework Project Developers List <
epf-dev@xxxxxxxxxxx>
>
>
> To
> Per Kroll/Cupertino/IBM@IBMUS, epf-dev@xxxxxxxxxxx
> cc
>
> Subject
> RE: [epf-dev] IMPORTANT: Monday 8 AM PDT Meeting - OpenUP Refocus
>
>
>
>
>
>
>
>
>
>
>
> Hello,
>
> One scenario we might consider is to create 3 shorter iterations to
> complete the project, for instance 4 weeks each for M5 & M6, and 2
> weeks for M7. Or possibly 4/3/3 weeks. Then we could focus on creating
> solid deliverable content for each iteration rather than trying to
> improve all content each iteration.
>
> For instance, M5 could focus on delivering, in final form, all tasks.
> M6 could focus on artifacts, CPs, and DPs. And M7 could focus on
> guidelines. This way we know we’ve accomplished an iteration when
all
> elements of a particular type have been written, reviewed, and
> accepted. And each iteration would result in solid, usable content. Of
> course, this is just one possible way the work could be sliced up.
>
> - Jim
>
> ____________________
> Jim Ruehlin, IBM Rational
> RUP Content Developer
> Eclipse Process Framework (EPF) Committer
> email: _jruehlin@xxxxxx.com_ < mailto:jruehlin@xxxxxxxxxx>
> phone: 760.505.3232
> fax: 949.369.0720
>
>
> ------------------------------------------------------------------------
>
> *
> From:* epf-dev-bounces@xxxxxxxxxxx
> [mailto:epf-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Per
> Kroll/Cupertino/IBM*
> Sent:* Thursday, July 06, 2006 10:10 PM*
> To:* epf-dev@xxxxxxxxxxx*
> Subject:* [epf-dev] IMPORTANT: Monday 8 AM PDT Meeting - OpenUP Refocus
>
>
> Hi,
>
> it is increasingly obvious that OpenUP is not tracking according to
> plan. Even worse, we do not have a meaningful way of assessing where
> we are at....
> We need to refocus our efforts, prioritize what needs to be done, ask
> everybody to step up, establish a credible plan, and track to that plan.
>
> Some example problems:
> - Our burndown spreadsheet is after 4 weeks still not showing enough
> uptodate data to be relevant.
> - Burndown chart has major flaws: If you do not update status for a
> week, your remaining work by default goes down to zero... Makes the
> data look nice, but it does not reflect reality....
> - Glidepath is not used correctly. The point was that each team lead
> should update the glidepath once, and then only update the glidepath
> at iteration ends. We still have the dummy data I put in.
> - It is hard to assess, but the remaining work seems to not go down
> very much... when you adjust for incomplete data, but it is hard to say
> - We have no prioritization of remaining work (at least not that is
> visible), which makes it hard to know whether we work on the most
> important issues
> - We will fail to reach our M4 milestone with content freeze
> - We have no assessment of how much work is associated with each task,
> so all tasks are given equal weight in the burndown
> - My gut feeling is that we are not prioritizing some critical and
> time-consuming tasks associated with ensuring a good initial user
> experience
>
>
> To discuss what to do, I would like to have a meeting on Monday 7/10,
> 8 AM PDT.
> I would like each content leader to come. Others are also welcome.
> Agenda:
> - An honest analysis of where we are at (team leads, please update the
> burndown spreadsheet)
> - Discuss a credible plan for the end game
> - Be crisp on what we need to do in the short term
> - Discuss how to best mobilize our team
>
>
> Toll-free dial-in: 1-877-421-0003
> Toll dial-in: 1-770-615-1374
> IBM Tie-line: 421-0003
> Participant passcode: 667201
>
>
> Thanks
>
> Per Kroll
> STSM, Manager Methods: RUP / RMC
> Project Lead: Eclipse Process Framework
> Rational Software, IBM Corp
> 408-342-3815
> _______________________________________________
> epf-dev mailing list
> epf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epf-dev
> _______________________________________________
> epf-dev mailing list
> epf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epf-dev
> _______________________________________________
> epf-dev mailing list
> epf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epf-dev
>
>------------------------------------------------------------------------
>
>_______________________________________________
>epf-dev mailing list
>epf-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/epf-dev
>
>
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
