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.

---

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

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.

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. :-)

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

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

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

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/

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

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

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@...

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

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

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

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

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

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.

Just wanted to announce that there will be a ScrumMaster certification in Montreal, Canada on February 7 and 8.

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

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

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

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

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