Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

scrumdevelopment · Scrum Users

The Yahoo! Groups Product Blog

Check it out!

Group Information

  • Members: 7478
  • Category: Development
  • Founded: Feb 1, 2000
  • Language: English
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Message search is now enhanced, find messages faster. Take it for a spin.

Messages

Advanced
Messages Help
Messages 5882 - 5913 of 56957   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#5882 From: todd <todd@...>
Date: Wed Jan 5, 2005 5:53 pm
Subject: Re: Re: design practices
toddhoff1
Send Email Send Email
 
Steven Gordon wrote:

> Emergent design has other benefits over up-front design besides being
> able to handle changing/uncertain/emergent requirements:
>
> 1. Emergent designs force the code to be easily changable, whereas
> top-down holistic design can easily create code that is monolithically
> dependent on the current design.  Even if requirements never changed,
> implementing the system a few requirements at a time results in a
> system that will be battle tested at being able to accommodate
> additional requirements after deployment.


This is a bit of FUD.  There's nothing in top down design that makes it
any more monolithic or dependent or less changeable than any other
design approach. If you know how to design your code to be testable and
changeable then it will be. And it can be far easier to add in new
requirements, depending on the nature of the new requirements. If people
add useless over complicated code that doesn't work then that's there
own issue, it's not required by any design methodology that i know of.
Nor will any design methodology prevent someone from doing stupid stuff.

#5883 From: "Clarke Ching" <lists@...>
Date: Wed Jan 5, 2005 7:03 pm
Subject: RE: Re: Multi-Project Development with Limited Resources
clarkeching
Send Email Send Email
 
Hi Jiri,
 
Thanks for your reply.
 
> a) Unfortunately for us our company, as many do, has won a
   bid for this project on a fixed price contract basis.
   So we get a big sum of money, divided in monthly payments
   over a period of two years, to finance the ongoing
   development effort. ... He has the right
   to not give us any further work in the future, if not
   satisfied.
 
That is kinda unfortunate!  So there is no immediate motivation for your company to deliver any earlier than promised.  In fact, by the sound of it, would you lose money if you did?
 
Clarke
 


From: Jiri Lundak [mailto:jiri.lundak@...]
Sent: 04 January 2005 00:31
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Re: Multi-Project Development with Limited Resources


Hi Clark,

a) Unfortunately for us our company, as many do, has won a
   bid for this project on a fixed price contract basis.
   So we get a big sum of money, divided in monthly payments
   over a period of two years, to finance the ongoing
   development effort. At the end of the project all code
   becomes the property of the customer. He has the right
   to not give us any further work in the future, if not
   satisfied.
   Unfortunately the customer has no idea how to continue to
   develop the system on his own or a third party, because
   very much know-how in the business domain is needed, that
   our partner, IBM, does not possess.
   So even in the case that the project should be terminated
   without being finished, there is the opinion in upper
   management, that the investment is so big, that the
   customer can not afford to invest once more the same sum
   to complete the project.

b) Although this this would be a remote possibility (because
   there are several other suppliers), this would not be
   an easy switch, because there would have to be rewritten
   many host programms that migrate data from the old host
   environment to the one (the host programms being written
   by our company's programmer over the period of the last
   20 years). A bit you can call that kind of a supplier
   lock in. Sure, with lots of money this could be possible.
   But as a govermental firm (operating on tax money) they
   try to save any single Swiss franc they can.

Hope this helps to give you a better picture.

Jiri


--- In scrumdevelopment@yahoogroups.com, "clarkeching" <lists@c...> wrote:
>
> Hi Jiri,
>
> I don't think we can properly help answer your question without
> knowing:
>
> a) How does your company *make money* from these
> projects/customers?  Are they paid on completion of the work, as
> part of a joint-venture, or is this done a work and materials basis?
>
> b) What's the competive environment like for your company?  For
> instance, can your customers easily move to another supplier?
>
> Since your employer is in business to make money your decision
> should be based on how you can help them to make the most money (now
> and in the future), not on minimising cost, technical
> considerations, efficiency, or on "fairly" balancing the needs of
> the many customers. 
>
> BTW: you might want to look at the animations in this powerpoint
> presentaion, under "Tool 2 - Eliminate multitasking"
> http://www.clarkeching.com/files/clarke_ching_goldratt_toc_xpday_2004
> .ppt
> Clarke





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




#5884 From: Steven Gordon <sagordon@...>
Date: Wed Jan 5, 2005 7:10 pm
Subject: RE: Re: design practices
sfman2k
Send Email Send Email
 
The argument that if you know what you are doing, you can create a perfectly
good software using any methodology (or even no methodology) defeats anything we
say here.  Given the current state of software today, this is not a very
realistic or productive argument.

It is common sense that a design that has had new requirements added to it
dozens of times in a principled way can be more trusted to be able to
accommodate new requirements of similar kinds than a design that has never had
any new requirements added to it.

-----Original Message-----
From: todd [mailto:todd@...]
Sent: Wed 1/5/2005 10:53 AM
To: scrumdevelopment@yahoogroups.com
Cc:
Subject: Re: [scrumdevelopment] Re: design practices




	 Steven Gordon wrote:

	 > Emergent design has other benefits over up-front design besides being
	 > able to handle changing/uncertain/emergent requirements:
	 >
	 > 1. Emergent designs force the code to be easily changable, whereas
	 > top-down holistic design can easily create code that is monolithically
	 > dependent on the current design.  Even if requirements never changed,
	 > implementing the system a few requirements at a time results in a
	 > system that will be battle tested at being able to accommodate
	 > additional requirements after deployment.


	 This is a bit of FUD.  There's nothing in top down design that makes it
	 any more monolithic or dependent or less changeable than any other
	 design approach. If you know how to design your code to be testable and
	 changeable then it will be. And it can be far easier to add in new
	 requirements, depending on the nature of the new requirements. If people
	 add useless over complicated code that doesn't work then that's there
	 own issue, it's not required by any design methodology that i know of.
	 Nor will any design methodology prevent someone from doing stupid stuff.

#5885 From: todd <todd@...>
Date: Wed Jan 5, 2005 7:24 pm
Subject: Re: Re: design practices
toddhoff1
Send Email Send Email
 
Steven Gordon wrote:

> The argument that if you know what you are doing, you can create a
> perfectly good software using any methodology (or even no methodology)
> defeats anything we say here.

It's productive and realistic because you can't overcome this lack by
adding a methodology. So dinging one methodology in favor another isn't
fair, imho.

>
> It is common sense that a design that has had new requirements added
> to it dozens of times in a principled way can be more trusted to be
> able to accommodate new requirements of similar kinds than a design
> that has never had any new requirements added to it.

The use of the word  "principled" defeats anything we say here. Given
the current state of software today, this is not a very realistic or
productive argument. :-)

#5886 From: Ron Jeffries <ronjeffries@...>
Date: Wed Jan 5, 2005 9:08 pm
Subject: Re: Re: Multi-Project Development with Limited Resources
RonaldEJeffries
Send Email Send Email
 
On Wednesday, January 5, 2005, at 2:03:04 PM, Clarke Ching wrote:

>> a) Unfortunately for us our company, as many do, has won a
>    bid for this project on a fixed price contract basis.
>    So we get a big sum of money, divided in monthly payments
>    over a period of two years, to finance the ongoing
>    development effort. ... He has the right
>    to not give us any further work in the future, if not
>    satisfied.

> That is kinda unfortunate!  So there is no immediate motivation for your
> company to deliver any earlier than promised.

Unless getting parts sooner than promised might make him more
satisfied ...

> In fact, by the sound of it,
> would you lose money if you did?

Unless it's really underbid, in which case you'd lose less by
getting done sooner, lose fewer people by working less overtime, or
get more money by making him happy ...

Ron Jeffries
www.XProgramming.com
I could be wrong, but I'm not.  --Eagles, Victim of Love

#5887 From: Hubert Smits <hubert.smits@...>
Date: Wed Jan 5, 2005 10:21 pm
Subject: Re: Concurrent work in product backlog
hubert_g_smits
Send Email Send Email
 
Hello Heidi,

Take into account the number of developers you can put on the job. In
theory 10 developers can do 100 days of development work in 10 days.
You will know from experience that this piece of mathematics isn't
true, 10 developers bring overhead, paerwork, holiday leave etc.
That's where your adjustment factor comes in. Hopefully you have some
experience to best guess this factor. If you haven't, then you may
think about the following number that I use for large projects with a
new team. A year has 52 weeks * 5 working days. Out of these 260 days
I take 70-80 for holidays, illness, training and what else: 185 days
are available for productive coding.

Hope this is a start for you.

--Hubert


On Wed, 05 Jan 2005 14:45:39 -0000, the_heidster <the_heidster@...> wrote:
>
>
> Folks - I am creating my first product backlog. I know that the
> estimate for each requirement/feature should be done in days.
> Questions, do I just add up the days to estimate the completion
> date? This would indicate that each day is consecutive. How does
> this take into account concurrent work (or does it?) Also, by what
> criteria should I decide the "adjustment factor"? How important is
> the adjustment factor?
>
> Thanks,
> Heidi
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com
> Yahoo! Groups Links
>
>
>
>
>

#5888 From: "David Laffineuse" <dlaffineuse@...>
Date: Wed Jan 5, 2005 11:10 pm
Subject: Scrum and CCPM
d_laffineuse
Send Email Send Email
 
Does anyone have experience using Scrum and Critical Chain Project Management in combination?
Much interested in your experiences if you have.
 
David Laffineuse
dlaffineuse@...


Find the music you love with MSN Music – tracks are just 99c!

#5889 From: "David Laffineuse" <dlaffineuse@...>
Date: Wed Jan 5, 2005 11:09 pm
Subject: RE: Concurrent work in product backlog
d_laffineuse
Send Email Send Email
 



>From: "the_heidster" <the_heidster@...>
>Reply-To: scrumdevelopment@yahoogroups.com
>To: scrumdevelopment@yahoogroups.com
>Subject: [scrumdevelopment] Concurrent work in product backlog
>Date: Wed, 05 Jan 2005 14:45:39 -0000
>MIME-Version: 1.0
>X-Originating-IP: 208.153.158.254
>X-Sender: the_heidster@...
>Received: from n13a.bulk.scd.yahoo.com ([66.94.237.24]) by mc8-f2.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Wed, 5 Jan 2005 06:46:11 -0800
>Received: from [66.218.69.4] by n13.bulk.scd.yahoo.com with NNFMP; 05 Jan 2005 14:45:58 -0000
>Received: from [66.218.67.196] by mailer4.bulk.scd.yahoo.com with NNFMP; 05 Jan 2005 14:45:58 -0000
>Received: (qmail 46241 invoked from network); 5 Jan 2005 14:45:56 -0000
>Received: from unknown (66.218.66.166)  by m3.grp.scd.yahoo.com with QMQP; 5 Jan 2005 14:45:56 -0000
>Received: from unknown (HELO n9a.bulk.scd.yahoo.com) (66.94.237.43)  by mta5.grp.scd.yahoo.com with SMTP; 5 Jan 2005 14:45:56 -0000
>Received: from [66.218.69.1] by n9.bulk.scd.yahoo.com with NNFMP; 05 Jan 2005 14:45:39 -0000
>Received: from [66.218.67.184] by mailer1.bulk.scd.yahoo.com with NNFMP; 05 Jan 2005 14:45:39 -0000
>X-Message-Info: JGTYoYF78jEleecK1ifoE9yk+87n8iJz
>X-Yahoo-Newman-Property: groups-email
>X-Apparently-To: scrumdevelopment@yahoogroups.com
>User-Agent: eGroups-EW/0.82
>X-Mailer: Yahoo Groups Message Poster
>X-eGroups-Remote-IP: 66.94.237.43
>X-Yahoo-Profile: the_heidster
>Mailing-List: list scrumdevelopment@yahoogroups.com; contact scrumdevelopment-owner@yahoogroups.com
>Delivered-To: mailing list scrumdevelopment@yahoogroups.com
>Precedence: bulk
>List-Unsubscribe: <mailto:scrumdevelopment-unsubscribe@yahoogroups.com>
>Return-Path: sentto-1569064-5852-1104936358-dlaffineuse=hotmail.com@...
>X-OriginalArrivalTime: 05 Jan 2005 14:46:11.0817 (UTC) FILETIME=[4CA8E590:01C4F335]
>
>
>Folks - I am creating my first product backlog. I know that the
>estimate for each requirement/feature should be done in days.
>Questions, do I just add up the days to estimate the completion
>date? This would indicate that each day is consecutive. How does
>this take into account concurrent work (or does it?) Also, by what
>criteria should I decide the "adjustment factor"? How important is
>the adjustment factor?
>
>Thanks,
>Heidi
>
>
>


MSN Premium helps protect against viruses, hackers, junk e-mail pop-ups.

#5890 From: "Mike Cohn" <mike@...>
Date: Thu Jan 6, 2005 4:10 am
Subject: RE: Concurrent work in product backlog
mikewcohn
Send Email Send Email
 
Heidi--
I hate to steer you toward a book again. But, hey, this one's free (for
now). See http://www.mountaingoatsoftware.com/agileplanning/ and look at
Chapter 10, "Simple Release Planning." It should address your questions but
you may want to read the earlier chapters (on estimating, especially in
Ideal Time, since it sounds like that's what you're doing).

--Mike Cohn
Author of User Stories Applied for Agile Software Development
www.mountaingoatsoftware.com
www.userstories.com

-----Original Message-----
From: the_heidster [mailto:the_heidster@...]
Sent: Wednesday, January 05, 2005 7:46 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Concurrent work in product backlog



Folks - I am creating my first product backlog. I know that the
estimate for each requirement/feature should be done in days.
Questions, do I just add up the days to estimate the completion
date? This would indicate that each day is consecutive. How does
this take into account concurrent work (or does it?) Also, by what
criteria should I decide the "adjustment factor"? How important is
the adjustment factor?

Thanks,
Heidi





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

#5891 From: "Mike Cohn" <mike@...>
Date: Thu Jan 6, 2005 4:10 am
Subject: RE: Scrum and CCPM
mikewcohn
Send Email Send Email
 

Hi David—

Critical Chain thinking has very much influenced how I plan Scrum projects. If you look at http://www.mountaingoatsoftware.com/agileplanning/ you’ll see my book in progress on “Agile Estimating and Planning.”  Chapter 13 (“Improving Accuracy with Buffers”) is explicitly about incorporating Critical Chain-style buffers into Scrum projects.

 

Also, see David Anderson’s book, “Agile Management for Software Engineering” for a great deal on TOC and agile in general.

 

--Mike Cohn

Author of User Stories Applied for Agile Software Development

www.mountaingoatsoftware.com

www.userstories.com


From: David Laffineuse [mailto:dlaffineuse@...]
Sent: Wednesday, January 05, 2005 4:10 PM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Scrum and CCPM

 

Does anyone have experience using Scrum and Critical Chain Project Management in combination?

Much interested in your experiences if you have.

 

David Laffineuse

dlaffineuse@...




#5892 From: Paul Hodgetts <phodgetts@...>
Date: Thu Jan 6, 2005 5:52 am
Subject: Re: Concurrent work in product backlog
agilelogic
Send Email Send Email
 
Heidi (the_heidster) wrote:

  > Folks - I am creating my first product backlog. I know that the
  > estimate for each requirement/feature should be done in days.

The important thing is that the relative sizes hold up.  We
need to make sure a 4 is really twice as big as a 2.  Most of
the teams I've worked with seem to have difficulties estimating
in nebulous units, just working with relative sizes.  So we
end up correlating the units to something we can have a better
feel for, which is typically ideal days (if I was doing nothing
else, had no interruptions, no unexpected issues, etc).

If we want a first-cut SWAG at the overall schedule, in
addition to size estimates, we also need to estimate velocity.
This seems easiest done correlated to days, and if we are also
estimating in ideal days we can correlate size to velocity.  We
can take the available working days in a sprint, add them up
and then take into consideration that just about every day is
not ideal by multiplying by anywhere from 40% to 80%.  Just
about every team I work with wants to use from 75% to 100%, and
it never plays out that way.

Once we get some feedback from a couple of sprints, however, it
doesn't matter if the estimating units correlate to time.  We
will learn that the team can average 38 estimated ideal days per
sprint.  Maybe that means an ideal day maps to 1.75 elapsed days,
but we don't really care.  We have 423 total estimated ideal
days left, so figure another 11 or 12 sprints.

  > Questions, do I just add up the days to estimate the completion
  > date? This would indicate that each day is consecutive. How does
  > this take into account concurrent work (or does it?)

As mentioned above, we use the total work size and the team's
estimated velocity per sprint to estimate a completion date.

There are two types of concurrent work.  The first is when the
team is working on several backlog items at the same time.  The
second is when we have a cross-functional team, where a backlog
item needs several skill sets to get it done (which is pretty
common -- it's especially typical that we have developers and
testers, and usually types of developers as well, DBAs, etc.),
and some of that work happens in parallel.

I use a concept I call a "work stream."  A work stream is the
collection of people we gather together to get a backlog item
done.  For example, we use a pair of developers, a DBA and a
tester.  It's not necessary that these people are dedicated to
one work stream -- a DBA may timeshare across them.  For
estimating at the backlog item level, we assume a minimal work
stream size.  When we actually task the backlog item out for a
sprint, we may put more than one work stream on it, reducing
the elapsed time but still taking up the same total ideal time.

So as an example, I have a backlog item for an e-commerce
application feature.  My minimal work stream is one interface
designer, a pair of developers and a tester.  I estimate how
long it takes this group to get the backlog item done.  The
interface designer needs a day before the developers can get
started, then everyone works in parallel for 3 days, and then
the tester and developers need a day for final test and fix.
The overall estimate for this backlog item would be 5 days.

This is not exact.  The interface designer could very well go
off and start working on another backlog item while the tester
and developers are in final test.  But it's close enough, and
the actual measured velocity will rise if the team learns how
to overlap backlog item work like this.  The alternative is to
map out a complex set of tasks and dependencies, in other words
something like a Gantt chart, and we know how well that works.

Some folks would say the work stream concept I mention above is
trying to be too exact.  An easier approach is to consider what
your critical path resource would be, typically the developers,
and then just estimate their time.  This wouldn't consider the
work that has to happen prior to or after the developers, and
thus the actual velocity would tend to fall if there is enough
of it happening.

In any case, we take the number of available work streams times
the number of work days and that gives us our ideal velocity for
a sprint.  Divide the total work size in ideal days by this
velocity and we get the number of sprints remaining, and hence
the estimated completion date.

  > Also, by what criteria should I decide the "adjustment factor"?
  > How important is the adjustment factor?

There are adjustments that can be applied to both size and
velocity estimates.  Earlier I mentioned adjusting the velocity
to accommodate less than ideal days.

Ken Schwaber has a set of velocity adjustment factors that he
teaches as part of the Certified ScrumMaster course.  I'm not
sure if he considers these proprietary to the course, so I won't
detail them here.  But some of the more important criteria I use
for adjusting velocity are if the team is distributed, if we
have multiple teams coordinating work, if it's a new team, if
they're new to Scrum, if they have some unpredictable legacy
support on their plate, etc.  These things may slow them down.

We can also apply adjustments to size estimates.  If we're using
new technology or building in some new domain, the amount of work
may be larger than we might estimate.  We may even adjust certain
types of backlog items, for example the web services features may
be proving troublesome so we want to adjust them a bit.

The adjustment factor is important if the team is not taking it
into consideration when estimating.  It seems to be the nature
of estimating software projects that we tend to be optimistic.
More experienced teams may have realized their tendencies and
apply their own adjustment factors.  Less experienced teams may
not consider them.  A ScrumMaster should watch the team and
suggest applying adjustments if they feel they're needed.  I
would not take the team's estimates and apply an adjustment
after the fact without their understanding and agreement.

But, after a few iterations, regardless of whether we adjust we
will learn our actual velocity and converge on more accurate
overall estimates.  Initially, however, in order to avoid
establishing overly optimistic expectations, we may want to
apply some adjustment factors.  Just be sure to establish the
understanding that we're SWAG'ing these things, and the only
realistic numbers are those that result from concrete feedback.

I hope all that helps a bit.  There is a Certified ScrumMaster
course that I'm helping Ken teach coming up in San Diego
February 7-8, where you can learn all about planning and the
rest of Scrum.

Regards,
Paul
-----
Paul Hodgetts -- CEO, Principal Consultant
Agile Logic  -- www.agilelogic.com
Consulting, Coaching, Training -- On-Site & Out-Sourced Development
Agile Processes/Scrum/Lean/XP -- Java/J2EE, C++, OOA/D, UI/IA, XML

Upcoming Events:

"Scrum"
XP San Diego User Group - Thursday, January 6, 2005
http://groups.yahoo.com/group/xpsandiego/

"Can RUP Be Agile? Can RUP Be Extreme?"
Orange County Rational Users Group - Thursday, January 20, 2005
http://www.rational-ug.org/groups.php?groupid=9

Certified ScrumMaster Training, San Diego, CA - February 7-8, 2005
http://www.controlchaos.com/certification/

#5893 From: Angelo Schneider <angelo.schneider@...>
Date: Thu Jan 6, 2005 11:40 am
Subject: Article Re: Multi-Project Development with Limited Resources
angelo_schne...
Send Email Send Email
 
Hi,

a bit late but better late than never :D

In the german magazine "OBJEKTspectrum" was an article about "product
family"  development with interlocked SCRUMs (product family backlog
interlocked with several product backlogs).

I don't remember the issue, but it was a 2004 issue. The web page is:
www.sigs.de

The article was quite good and as you are from switzerland I suggest to
get a copy.

Regards,
	 Angelo

--------------------------- www.oomentor.de --------------------------
Angelo Schneider         OOAD/UML         Angelo.Schneider@...
Putlitzstr. 24       Patterns/FrameWorks          Fon: +49 721 9812465
76137 Karlsruhe           C++/JAVA                Fax: +49 721 9812467

#5894 From: "Deb" <deborah@...>
Date: Thu Jan 6, 2005 1:31 pm
Subject: OT: Re: Concurrent work in product backlog
debhart9
Send Email Send Email
 
lol

I followed your link to see what your book is up to, Mike. I was
excited to see that your Appendix includes "Answers to All Question"
!!! How wonderful, I have lots of questions. For starters... a
Canadian conundrum: it's freezing rain outside - should I drive or
take the streetcar? :-)

But then I realised that there IS NO DOWNLOAD LINK for this chapter...
oh, how disappointing. Guess I'll just have to buy the book :-D

Happy new year, Mike, and thanks for all your help and input here.
Hope 2005 brings you lots of royalties.
deb

(Happy new year, all... may 2005 bring you wonderful surprises!)

--- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...> wrote:
> Heidi--
> I hate to steer you toward a book again. But, hey, this one's free (for
> now). See http://www.mountaingoatsoftware.com/agileplanning/ and look at
> Chapter 10, "Simple Release Planning." It should address your
questions but
> you may want to read the earlier chapters (on estimating, especially in
> Ideal Time, since it sounds like that's what you're doing).
>
> --Mike Cohn
> Author of User Stories Applied for Agile Software Development
> www.mountaingoatsoftware.com
> www.userstories.com
>
> -----Original Message-----
> From: the_heidster [mailto:the_heidster@y...]
> Sent: Wednesday, January 05, 2005 7:46 AM
> To: scrumdevelopment@yahoogroups.com
> Subject: [scrumdevelopment] Concurrent work in product backlog
>
>
>
> Folks - I am creating my first product backlog. I know that the
> estimate for each requirement/feature should be done in days.
> Questions, do I just add up the days to estimate the completion
> date? This would indicate that each day is consecutive. How does
> this take into account concurrent work (or does it?) Also, by what
> criteria should I decide the "adjustment factor"? How important is
> the adjustment factor?
>
> Thanks,
> Heidi
>
>
>
>
>
> To Post a message, send it to:   scrumdevelopment@e...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@e...
> Yahoo! Groups Links

#5895 From: Steven Gordon <sagordon@...>
Date: Thu Jan 6, 2005 1:56 pm
Subject: RE: Scrum and CCPM
sfman2k
Send Email Send Email
 
The problem with applying CCPM to software development scheduling
is that the business level dependencies between tasks/features/stories are
not software development dependencies when using modern OO design.

In terms of an example in chapter 13, in the physical world we have to find
the keys before we can drive the car, but in the software development world
we can implement finding the keys and implement driving the car (assuming
that we already have the keys) in parallel.

If we allow CCPM to remove this advantage in the software development
world, we will have developers waiting unnecessarily for functionally
dependent tasks to be completed before they start implementing their tasks.
In order to not be idle, these developers would then work on different tasks,
and we are likely to have more incompletely implemented features at the end
of each iteration.

Of course, this does not preclude using the schedule estimation buffering
technique described.  But, there is much more to CCPM than just schedule
buffering.

Steven Gordon
http://sf.asu.edu/


	 -----Original Message-----
	 From: Mike Cohn [mailto:mike@...]
	 Sent: Wed 1/5/2005 9:10 PM
	 To: scrumdevelopment@yahoogroups.com
	 Cc:
	 Subject: RE: [scrumdevelopment] Scrum and CCPM



	 Hi David—

	 Critical Chain thinking has very much influenced how I plan Scrum projects. If
you look at http://www.mountaingoatsoftware.com/agileplanning/ you’ll see my
book in progress on “Agile Estimating and Planning.† Chapter 13
(“Improving Accuracy with Buffersâ€) is explicitly about incorporating
Critical Chain-style buffers into Scrum projects.



	 Also, see David Anderson’s book, “Agile Management for Software
Engineering†for a great deal on TOC and agile in general.



	 --Mike Cohn

	 Author of User Stories Applied for Agile Software Development

	 www.mountaingoatsoftware.com

	 www.userstories.com


   _____


	 From: David Laffineuse [mailto:dlaffineuse@...]
	 Sent: Wednesday, January 05, 2005 4:10 PM
	 To: scrumdevelopment@yahoogroups.com
	 Subject: [scrumdevelopment] Scrum and CCPM



	 Does anyone have experience using Scrum and Critical Chain Project Management
in combination?

	 Much interested in your experiences if you have.



	 David Laffineuse

	 dlaffineuse@...

#5898 From: "Jim York" <jim.york@...>
Date: Thu Jan 6, 2005 2:51 pm
Subject: Seeking Lean Agile Coaches
jimyorkcsm
Send Email Send Email
 
On behalf of Cristina Cleary, I am posting the following message:

Seeking Lean-Agile Coaches: Your assistance would be appreciated!!!

Hello, my name is Cristina Cleary and I am a Sr. Technical Recruiter
at CC Pace in Fairfax, VA. CC Pace is a technology services consulting
firm that specializes in Agile and Lean methodologies. As a recruiter
for my company I have been tasked with filling two project positions
for Lean-Agile Coaches. These positions require an expert knowledge of
Scrum and knowledge of Lean Thinking. Any suggestions or referrals you
may have that could help me to find these resources would be greatly
appreciated. Feel free to review our corporate web site for more
information about CC Pace (www.ccpace.com).

Please feel free to contact me directly at (703) 251-6836 or simply
email me at ccleary@...

Please respond directly to Christina.
Thanks,
Jim

#5899 From: "Claude Montpetit" <claude@...>
Date: Thu Jan 6, 2005 8:51 pm
Subject: Scrum management job Offer in Granby, QC, Canada
claude_montp...
Send Email Send Email
 
Hi,

The company I work with is currently looking to fill a position of
Software Manager. The development approach here is "almost" scrum and
Scrum concepts have been accepted throughout the company.

The company wants to hire a full time manager, not a contractor. It is
located in cold-snowy-frozen-Canada, close to the ski hills of the
Eastern Townships (Estrie), 45 min. outside of Montreal.

The company's site is at http://www.nertec.com but the site is very
obsolete as the company has recently been restructured and changed
name. It is a small company of around 30 employees broken into
software, firmware, and hardware teams. The software team is around 10
people including some contractors.

Scrum was started last summer with good initial success but a manager
that has the discipline of promoting the need to have outsiders
defining priorities (client), daily scrums, and tight monthly cycle
closure will be an asset to the team.

Software developement is done mainly in server-side Java.

If you are interested or need more info, send me an email.

Claude

#5900 From: "ginitram" <ginitram@...>
Date: Thu Jan 6, 2005 9:39 pm
Subject: [Article] Adaptative Project Management Using Scrum by Craig Murphy
ginitram
Send Email Send Email
 
The Methods & Tools newsletter has just released in its html archive
section "Adaptative Project Management Using Scrum" by Craig Murphy

This article provides a basic overview of Scrum.

http://www.methodsandtools.com/archive/archive.php?id=18

#5901 From: "Mike Cohn" <mike@...>
Date: Thu Jan 6, 2005 11:18 pm
Subject: RE: OT: Re: Concurrent work in product backlog
mikewcohn
Send Email Send Email
 
Thanks, Deb.

You'll notice though that the chapter isn't called "CORRECT answers to all
questions"!

--Mike

-----Original Message-----
From: Deb [mailto:deborah@...]
Sent: Thursday, January 06, 2005 6:31 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] OT: Re: Concurrent work in product backlog



lol

I followed your link to see what your book is up to, Mike. I was
excited to see that your Appendix includes "Answers to All Question"
!!! How wonderful, I have lots of questions. For starters... a
Canadian conundrum: it's freezing rain outside - should I drive or
take the streetcar? :-)

But then I realised that there IS NO DOWNLOAD LINK for this chapter...
oh, how disappointing. Guess I'll just have to buy the book :-D

Happy new year, Mike, and thanks for all your help and input here.
Hope 2005 brings you lots of royalties.
deb

(Happy new year, all... may 2005 bring you wonderful surprises!)

--- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...> wrote:
> Heidi--
> I hate to steer you toward a book again. But, hey, this one's free (for
> now). See http://www.mountaingoatsoftware.com/agileplanning/ and look at
> Chapter 10, "Simple Release Planning." It should address your
questions but
> you may want to read the earlier chapters (on estimating, especially in
> Ideal Time, since it sounds like that's what you're doing).
>
> --Mike Cohn
> Author of User Stories Applied for Agile Software Development
> www.mountaingoatsoftware.com
> www.userstories.com
>
> -----Original Message-----
> From: the_heidster [mailto:the_heidster@y...]
> Sent: Wednesday, January 05, 2005 7:46 AM
> To: scrumdevelopment@yahoogroups.com
> Subject: [scrumdevelopment] Concurrent work in product backlog
>
>
>
> Folks - I am creating my first product backlog. I know that the
> estimate for each requirement/feature should be done in days.
> Questions, do I just add up the days to estimate the completion
> date? This would indicate that each day is consecutive. How does
> this take into account concurrent work (or does it?) Also, by what
> criteria should I decide the "adjustment factor"? How important is
> the adjustment factor?
>
> Thanks,
> Heidi
>
>
>
>
>
> To Post a message, send it to:   scrumdevelopment@e...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@e...
> Yahoo! Groups Links





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

#5902 From: "Mike Beedle" <beedlem@...>
Date: Thu Jan 6, 2005 11:45 pm
Subject: Re: Multi-Project Development with Limited Resources
beedlem
Send Email Send Email
 

 

(Jiri
"

Hi Mike,

 

Thanks for the pointer. Some questions that I have:

 

1. What do is the difference between a Shared Resources Scrum Master

   and a 'normal' (is there anyone normal among us ;-) ) Scrum Master?

 

"

      )

 

Jiri:

 

The "Shared Resources Scrum Master" is the Scrum Master for the

Shared Resources team, if there is one (either the team or the

ScrumMaster for it).  (Don't you love that answer?? :-)

 

Let me explain.  The "shared resources team members" have as a goal:

 

      * promote the conceptual integrity of the enterprise architecture

  and applications

      * promote and facilitate enterprise component reuse

      * provide coaching, training and mentoring for application development      

  team members (both process and technology)

 

The "Shared Resources" team codes stuff in cooperation with other teams.  

The "Shared Resources" team members are in many cases on loan to other teams.  

These members carry "central DNA", that reminds the application teams there are:

 

·        design and architectural standards 

 

This prevents application developers from re-architecting applications

that are not compatible with enterprise standards.

 

·        reusable business components (some under development)

 

      This prevents business developers from re-inventing the
      "business component wheel"

·        coding standards

 

      This helps and reminds the application developers that there are

enterprise coding standards  (The goal is that all code throughout

the enterprise in a particular architecture looks and feels the same.)

     

·        infrastructure components that need to be used

 

      This prevents teams from recreating things like "single sign on",

      "authorization services", workflow, document management, faxing,

printing, logging, etc., etc.

 

 

The "Shared Resources team members" live with the teams, but meet with the

"Shared Resources Scrum Master" at least once again in the same room, where

the 3 questions are asked.  (Yes, those 3 questions you already know from

basic Scrum.)

 

The goal of the Shared Resources team is to eventually have teams with no

"Shared Resource team members", and instead have a representative of

the application come to the "Shared Resources Meetings".

 

The "shared resources team" is sometimes called "Architecture team", but

I prefer "Shared resources" because the Architecture name has in some

places negative connotations, as in "high-level non-writing code experts

on top of white pedestals", etc.  Actually, I believe there is a

"good breed" of architects that resemble more "coaches", but then we

had to call the team the "Coaching Team", which is even harder to understand.

 

(Jiri

"2. What do you mean by 'Production Super Sprints'?"

      )

 

Many applications are developed concurrently, most of which use and

deploy reusable components.  Because of these dependencies, the

"reusable code base" needs to be tested and deployed all-at-once in a

"Production Super Sprint", which encompass one or more individual

application Sprints.

 

"Production Super Sprints" are self-similar at a higher level of scale

to Sprints.  (As "Scrum of Scrums" for multiple teams are self-similar

to "Scrums".)

 

In our case we do scaling at two levels: technical and management.

 

So our "Scrum of Scrums" apply to:

 

      * application team leaders (to decide Production Super Sprints and

  Enterprise Releases)

      * technical leaders (to decide Production Super Sprint contents)

      * Shared Resources team members (to evolve Enterprise Development and

        Architecture through application Sprints and Production Super Sprints)

      * Shared Resources sub-teams (to coordinate dependencies among shared

        Components within the Shared Resources team.)

 

Of course then you have regular Scrums:

 

      * Application Scrums

      * Shared Resources Scrums

 

(Jiri

"3. Would be intersting to hear, how you do this in the concrete

   -> Integration Testing across applications and reusable components?

"

      )

 

Throw all enterprise applications into a single integration server and

bang away (through both automated tests and manual tests).

 


(Jiri

      (Btw: What happend to XBreed?))

 

XBreed was renamed "Enterprise Agile Process" to avoid confusion -- a

much better name for its purpose:

 

      Concurrent Agile Application Development

 

(All references to XP engineering practices have been removed, since that

was most of the confusing element.  "Enterprise Agile Process" can

use *any* engineering practices.)

 

Using this system we developed 17 applications at a large PBM here in Chicago,

and since they have extended this number to something like 25 apps.

 

To my knowledge, this is the highest number of concurrent applications

being developed in an "agile way" using reusable components.  (Some of

the apps, at least 5, are very large 200+ screens.)

 

This method has been refined over the years.  Our first experience

with it was in 1996 at a large benefits management company, and then

used it again in Insurance, and Financials, with different levels of

success.

 

The challenge for Agility and Scrum in particular today is:

 

      Enterprise Agile Development

 

with multiple concurrent and dependent projects being developed all-at-once.

 

This is where Agility will make "most business sense" i.e. highest

ROI and risk mitigation.

 

At this level of scale Agile Software Development is almost synonymous with

Agile Business Development, and for the most part:

 

the enterprise software is the business

 

(Think Telecom, Financials, Insurance, etc.)

 

- Mike

 

Michael A. Beedle

CEO

New Governance Inc.

2275 Half Day Rd, Suite 350

Bannockburn, IL 60015

Email: mike.beedle@...

www: http://www.newgovernance.com

Office: 847-821-2631

Cell: 847-840-9890

 


#5903 From: "David Laffineuse" <dlaffineuse@...>
Date: Fri Jan 7, 2005 4:45 am
Subject: RE: Scrum and CCPM
d_laffineuse
Send Email Send Email
 

Mike,

Thank you for the reference, much appreciated.  Another question for you, is it possible to reconcile approaches such as Scrum with process requirements based on SW-CMM?

David.

>From: "Mike Cohn" <mike@...>
>Reply-To: scrumdevelopment@yahoogroups.com
>To: <scrumdevelopment@yahoogroups.com>
>Subject: RE: [scrumdevelopment] Scrum and CCPM
>Date: Wed, 5 Jan 2005 21:10:19 -0700
>MIME-Version: 1.0
>X-Sender: mike@...
>Received: from n21a.bulk.scd.yahoo.com ([66.94.237.50]) by mc9-f24.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Wed, 5 Jan 2005 20:10:43 -0800
>Received: from [66.218.69.4] by n21.bulk.scd.yahoo.com with NNFMP; 06 Jan 2005 04:10:40 -0000
>Received: from [66.218.67.192] by mailer4.bulk.scd.yahoo.com with NNFMP; 06 Jan 2005 04:10:40 -0000
>Received: (qmail 10803 invoked from network); 6 Jan 2005 04:10:39 -0000
>Received: from unknown (66.218.66.218)  by m10.grp.scd.yahoo.com with QMQP; 6 Jan 2005 04:10:39 -0000
>Received: from unknown (HELO pyramid-01.kattare.com) (69.59.195.20)  by mta3.grp.scd.yahoo.com with SMTP; 6 Jan 2005 04:10:38 -0000
>Received: from GROWL (uslec-66-255-155-18.cust.uslec.net [66.255.155.18])(authenticated bits=0)by pyramid-01.kattare.com (8.12.10/8.12.11) with ESMTP id j064ALJJ004623for <scrumdevelopment@yahoogroups.com>; Wed, 5 Jan 2005 20:10:34 -0800
>X-Message-Info: JGTYoYF78jFpVCvYfKMg5FF1QPEJ+pZh
>X-Yahoo-Newman-Property: groups-email
>X-Apparently-To: scrumdevelopment@yahoogroups.com
>X-Mailer: Microsoft Office Outlook, Build 11.0.6353
>Thread-Index: AcTzfIsx2KPpT2C3S2CN/O7hMuqxVgAJqMhQ
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
>X-eGroups-Remote-IP: 69.59.195.20
>X-Yahoo-Profile: mikewcohn
>Mailing-List: list scrumdevelopment@yahoogroups.com; contact scrumdevelopment-owner@yahoogroups.com
>Delivered-To: mailing list scrumdevelopment@yahoogroups.com
>Precedence: bulk
>List-Unsubscribe: <mailto:scrumdevelopment-unsubscribe@yahoogroups.com>
>Return-Path: sentto-1569064-5866-1104984640-dlaffineuse=hotmail.com@...
>X-OriginalArrivalTime: 06 Jan 2005 04:10:43.0406 (UTC) FILETIME=[B0C4D6E0:01C4F3A5]
>
>Hi David-
>
>Critical Chain thinking has very much influenced how I plan Scrum projects.
>If you look at http://www.mountaingoatsoftware.com/agileplanning/ you'll see
>my book in progress on "Agile Estimating and Planning."  Chapter 13
>("Improving Accuracy with Buffers") is explicitly about incorporating
>Critical Chain-style buffers into Scrum projects.
>
>
>
>Also, see David Anderson's book, "Agile Management for Software Engineering"
>for a great deal on TOC and agile in general.
>
>
>
>--Mike Cohn
>
>Author of User Stories Applied for Agile Software Development
>
>www.mountaingoatsoftware.com
>
>www.userstories.com
>
>   _____
>
>From: David Laffineuse [mailto:dlaffineuse@...]
>Sent: Wednesday, January 05, 2005 4:10 PM
>To: scrumdevelopment@yahoogroups.com
>Subject: [scrumdevelopment] Scrum and CCPM
>
>
>
>Does anyone have experience using Scrum and Critical Chain Project
>Management in combination?
>
>Much interested in your experiences if you have.
>
>
>
>David Laffineuse
>
>dlaffineuse@...
>
>
>
>


Send email straight to your blog. Upload jokes, thoughts and even photos. Click here to find out how!

#5904 From: Francois Beauregard <fbeauregard@...>
Date: Fri Jan 7, 2005 5:10 am
Subject: ScrumMaster Certification in Montreal - February 7, 8
fbeauregard49
Send Email Send Email
 
Just wanted to announce that there will be a ScrumMaster certification in Montreal, Canada on February 7 and 8.
 
Those interested can contact me to get more details.
 
François

#5905 From: Boris Gloger <boris.gloger@...>
Date: Fri Jan 7, 2005 7:45 am
Subject: Re: Formalizing Scrum Chronicles #1
borisgloger
Send Email Send Email
 
Hi Tom, I like your approach of writing chronicals. Can you sent a
more clear information in which way we should write our own
chronicals. If we structure all stories in the same way, we would have
a first story database, right?
boris


On Wed, 05 Jan 2005 15:18:21 -0000, tsteele3rt <tsteele@...> wrote:
>
>
> What are the Formalizing Scrum Chronicles?
>
> The Formalizing Scrum Chronicles (FSC) will be a series of posts to
> the Scrum mailing list detailing my attempt at formally introducing
> Scrum to an organization/team. My main goal for these posts is to
> share my experiences and observations. I am also interested in
> feedback and suggestions from members of this group.
>
> My Background
>
> I have been an Agile advocate for several years, primarily focusing
> on XP. A few months back, I began investigating Scrum and discovered
> I had been following more Scrum practices than XP practices. I agree
> with the conventional understanding that Scrum and XP are
> complimentary, but currently favor the lower entry barrier that Scrum
> provides.
>
> Project Background
>
> Inspired by "stealth" Scrum discussed in Chapter 5 of Ken's second
> Scrum book, we are roughly following the Scrum approach without
> anyone knowing it. We are organizing the work on our project around
> monthly releases (Sprint). Initial release work is planned as a group
> (Sprint Planning), with our manager (Product Owner) prioritizing what
> he would like to see us accomplish (Product Backlog). We conduct
> daily meetings with the project team (Daily Scrum) and demonstrate
> new features to stakeholders prior to release (Sprint Review).
>
> Things are going pretty well, so why try to "formalize" things? My
> reasons include:
>
> 1) Despite my example, our Daily Scrums are far from optimal.
>
> 2) The Product Owner continually interrupts the team during a Sprint
> with "fire drill" work.
>
> 3) The team will be expanding in the New Year, and I think a more
> formal description of what we are trying to accomplish could help the
> transition.
>
> 4) While the Scrum Team plans work collectively and meets daily,
> there does not seem to be commitment.
>
> 5) I maintain a private Product Backlog based on conversations with
> the Product Owner.
>
> 6) Only two of the team members maintain the Sprint Backlog.
>
> Please feel free to comment and look for the next installment of the
> Formalizing Scrum Chronicles.
>
> Tom
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com
> Yahoo! Groups Links
>
>
>
>
>

#5906 From: Boris Gloger <boris.gloger@...>
Date: Fri Jan 7, 2005 7:47 am
Subject: Re: ScrumMaster Certification in Montreal - February 7, 8
borisgloger
Send Email Send Email
 
Hi Francois,
I want to wish you a big success with your class.

Boris

btw - I will do a class on the 17th and 18th of Jan in Vienna. It will
be a class in German, because all attendees are native German
speakers. We do have open seats.



On Fri, 07 Jan 2005 00:10:00 -0500, Francois Beauregard
<fbeauregard@...> wrote:
>
> Just wanted to announce that there will be a ScrumMaster certification in
> Montreal, Canada on February 7 and 8.
>
> Those interested can contact me to get more details.
>  François
>
>  To Post a message, send it to:   scrumdevelopment@eGroups.com
>  To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@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@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

#5907 From: Joseph Pelrine <jpelrine@...>
Date: Fri Jan 7, 2005 8:08 am
Subject: Re: ScrumMaster Certification in Montreal - February 7, 8
josephpelrine
Send Email Send Email
 
Hi Francois!
At 06:10 07.01.2005, you wrote:
Just wanted to announce that there will be a ScrumMaster certification in Montreal, Canada on February 7 and 8.

Good luck! I wish you all the best.

Cheers

--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: jpelrine@...
Web:   http://www.metaprog.com

You don't become enormously successful without encountering some really interesting problems.
- Mark Victor Hansen


#5908 From: "Scott Worley" <worleys@...>
Date: Fri Jan 7, 2005 8:18 am
Subject: RE: ScrumMaster Certification in Montreal - February 7, 8
zhangscott
Send Email Send Email
 

Arrgghh hand when I am not in Montreal, my normal home <sometimes I hate being stuck in shanghai…>

 

Good luck on the Cert Course… one day there will be one in Shanghai J

 

Scott Worley

  Shanghai Mobile Phone: +86 13061780020

  Email: scott.worley@...

  MSN Messenger ID: scott.worley@...

  Skype ID: scott.worley


From: Boris Gloger [mailto:boris.gloger@...]
Sent: Friday, January 07, 2005 3:48 PM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] ScrumMaster Certification in Montreal - February 7, 8

 

Hi Francois,
I want to wish you a big success with your class.

Boris

btw - I will do a class on the 17th and 18th of Jan in Vienna. It will
be a class in German, because all attendees are native German
speakers. We do have open seats.



On Fri, 07 Jan 2005 00:10:00 -0500, Francois Beauregard
<fbeauregard@...> wrote:

> Just wanted to announce that there will be a ScrumMaster certification in
> Montreal, Canada on February 7 and 8.
>  
> Those interested can contact me to get more details.
>  François
>
>  To Post a message, send it to:   scrumdevelopment@eGroups.com
>  To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@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@yahoogroups.com
>  
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


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




#5909 From: Steven Mak <tcmak@...>
Date: Fri Jan 7, 2005 9:21 am
Subject: RE: ScrumMaster Certification in Montreal - February 7, 8
tcmak
Send Email Send Email
 
Hi,

It would be nice if there's one in Shanghai (though it
would takes me 2 hour flight to get there...)..and
would it be in Mandarin or English? :P

Steven

--- Scott Worley <worleys@...>
wrote:

> Arrgghh hand when I am not in Montreal, my normal
> home <sometimes I hate
> being stuck in shanghai�>
>
>
>
> Good luck on the Cert Course� one day there
will be
> one in Shanghai :-)
>
>
>
> Scott Worley
>
>   Shanghai Mobile Phone: +86 13061780020
>
>   Email: scott.worley@...
>
>   MSN Messenger ID:
> <mailto:scott.worley@...>
> scott.worley@...
>
>   Skype ID: scott.worley
>
>   _____
>
> From: Boris Gloger [mailto:boris.gloger@...]
> Sent: Friday, January 07, 2005 3:48 PM
> To: scrumdevelopment@yahoogroups.com
> Subject: Re: [scrumdevelopment] ScrumMaster
> Certification in Montreal -
> February 7, 8
>
>
>
> Hi Francois,
> I want to wish you a big success with your class.
>
> Boris
>
> btw - I will do a class on the 17th and 18th of Jan
> in Vienna. It will
> be a class in German, because all attendees are
> native German
> speakers. We do have open seats.
>
>
>
> On Fri, 07 Jan 2005 00:10:00 -0500, Francois
> Beauregard
> <fbeauregard@...> wrote:
> >
> > Just wanted to announce that there will be a
> ScrumMaster certification in
> > Montreal, Canada on February 7 and 8.
> >
> > Those interested can contact me to get more
> details.
> >  François
> >
> >  To Post a message, send it to:
> scrumdevelopment@eGroups.com
> >  To Unsubscribe, send a blank message to:
> > scrumdevelopment-unsubscribe@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@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to the Yahoo!
> Terms of Service.
>
>
> To Post a message, send it to:
> scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@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@yahoogroups.com
>
<mailto:scrumdevelopment-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>
> * Your use of Yahoo! Groups is subject to the Yahoo!
> <http://docs.yahoo.com/info/terms/>  Terms of
> Service.
>
>




__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

#5910 From: Joseph Pelrine <jpelrine@...>
Date: Fri Jan 7, 2005 9:26 am
Subject: RE: ScrumMaster Certification in Montreal - February 7, 8
josephpelrine
Send Email Send Email
 
At 10:21 07.01.2005, you wrote:

>Hi,
>
>It would be nice if there's one in Shanghai (though it
>would takes me 2 hour flight to get there...)..and
>would it be in Mandarin or English? :P

I'm still trying to get one organized over there some place, although it
looks like it might be in Sydney this time - and yes, it would be in
English (unless you prefer German :-).

Cheers

--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: jpelrine@...
Web:   http://www.metaprog.com

You don't become enormously successful without encountering some really
interesting problems.
- Mark Victor Hansen

#5911 From: "Deb" <deborah@...>
Date: Fri Jan 7, 2005 2:42 pm
Subject: Re: Scrum management job Offer in Granby, QC, Canada
debhart9
Send Email Send Email
 
Another Scrum job in my home province - how wonderful.
I can vouch for how beautiful Granby is, even in w-w-w-winter.
And close to skiing and the zoo - could be a dream for a young family!
(But I'd wither and die of city-deprivation, myself - Montreal must be
90 minutes away? What would I do about these sudden urgent shoe
shopping attacks? lol)

Consider it folks - Quebec has significantly lower personal income tax
than Ontario... to my shock, I got back roughly $10,000 CDN in Quebec
tax money the year I moved to Toronto.

Claude, you don't mention language - what kind of French proficiency
would be needed?

Bonne Annee! Meilleurs Voeux pour une annee bien Agile!
deb

--- In scrumdevelopment@yahoogroups.com, "Claude Montpetit"
<claude@m...> wrote:
>
> Hi,
>
> The company I work with is currently looking to fill a position of
> Software Manager. The development approach here is "almost" scrum and
> Scrum concepts have been accepted throughout the company.
>
> The company wants to hire a full time manager, not a contractor. It is
> located in cold-snowy-frozen-Canada, close to the ski hills of the
> Eastern Townships (Estrie), 45 min. outside of Montreal.
>
> The company's site is at http://www.nertec.com but the site is very
> obsolete as the company has recently been restructured and changed
> name. It is a small company of around 30 employees broken into
> software, firmware, and hardware teams. The software team is around 10
> people including some contractors.
>
> Scrum was started last summer with good initial success but a manager
> that has the discipline of promoting the need to have outsiders
> defining priorities (client), daily scrums, and tight monthly cycle
> closure will be an asset to the team.
>
> Software developement is done mainly in server-side Java.
>
> If you are interested or need more info, send me an email.
>
> Claude

#5912 From: "Deb" <deborah@...>
Date: Fri Jan 7, 2005 3:19 pm
Subject: Re: Scrum management job Offer in Granby, QC, Canada
debhart9
Send Email Send Email
 
--- In scrumdevelopment@yahoogroups.com, "Deb" <deborah@h...> wrote:
>
> ...
> Consider it folks - Quebec has significantly lower personal income tax
> than Ontario... to my shock, I got back roughly $10,000 CDN in Quebec
> tax money the year I moved to Toronto.

Doh! My migraine pill is kicking in now... the correct conclusion
above is that Quebec taxes are *higher* ! It's the cost of living
that's lower. It's surprising what a painkiller and an ice-pack can do
for one's view of income taxes...

My teammates /have/ noticed that I need to take my socks off to do
higher math... the REAL reason I prefer two-week sprints :-) brrrr

#5913 From: Gary Feldman <g1list_1a@...>
Date: Fri Jan 7, 2005 3:23 pm
Subject: Re: Scrum and CCPM
gfyho
Send Email Send Email
 
David Laffineuse wrote:
> Mike,
>
> Thank you for the reference, much appreciated.  Another question for
> you, is it possible to reconcile approaches such as Scrum with process
> requirements based on SW-CMM?

I'm not quite sure what you mean by "process requirements" instead of just
asking whether Scrum and SW-CMM can be reconciled.  The answer to that is that
it's not a matter of reconciliation (which implies that a conflict has been
acknowledged).  The better question is whether Scrum can be used to achieve
SW-CMM certification, to which the answer is yes.  This is on the FAQ at
http://www.controlchaos.com/old-site/faq.htm , item 12.  For more discussion see
the section on CMM in the musings paper recently posted by Ken Schwaber at
http://www.controlchaos.com/download/Scrum%20Musings.pdf (page 21).

There is another perspective, illustrated at the same site by
http://www.controlchaos.com/old-site/debate.htm and
http://www.controlchaos.com/old-site/ap.htm , that classifies CMM as a defined
process, and hence in contrast to the empirical process approach with Scrum.  My
take on this, however, is that CMM is really about an effective, __documented__
process.  An underlying goal of CMM is for the customer (i. e., the DoD which
funded the SEI's CMM work) to be able to assess their suppliers' abilities. 
It's easy to read into this the idea of planning a project several years out,
and measuring how well a team meets that plan.  But that's not what the KPAs
demand.  What they're really after is knowing that the development team is being
run very well, can be trusted to deliver on their commitments, and can continue
to improve, keeping up with the state of the art.  Scrum certainly delivers on
that.

Gary

Messages 5882 - 5913 of 56957   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help