I use lines-of-code for metrics all the time. I just dont use it to
measure productivity. I use it to measure sizes of things, like
* number of lines added/removed/changed per commit
* number of lines merged when merge conflict occurs
* number of lines of merged -vs- "original" code per "commit"
* number of defects per lines of code
* lines of code per file
* lines of code per method
* lines of code changed per day, week
* lines of code added/changed/removed between labeled builds

For a given project, these eventually indicate trends in activity that
give me a clue about the likely complexity of a merge/commit, and
possible relationships between merge complexity and change-size and
integration/build frequency, and defects.
--
Brad Appleton <brad {AT} bradapp.net>
    Agile CM Environments (http://blog.bradapp.net/)
    & Software CM Patterns (www.scmpatterns.com)
"And miles to go before I sleep" -- Robert Frost

On Friday, March 31, 2006, at 12:54:06 AM, Alex Pukinskis wrote:

> On 03 30 2006 9:09 PM, "Ron Jeffries" <ronjeffries@...> wrote:

>> Every team I have visited in the last ten years has been doing too
>> much. Some of them have also been omitting key practices that they
>> sorely need, but every single one of them has been doing quaint and
>> curious Rococo things that are neither necessary nor productive.
>>
>> Every single one. That makes me willing to bet that if you are
>> reading this right now, your team is doing more than is ideal.

> This is fascinating to me.  While it's absolutely true that most
> organizations do this, I definitely have worked with some who don't have
> enough process.  There are startups out there that are doing ad-hoc,
> code-and-fix, crisis mode development all the time, with no formal process
> at all.

> Where most companies see waste because they have too much process, these
> groups constantly churn because they lack the focus and structure Scrum
> provides.  For them, adding a prioritized backlog, iterations, and daily
> standup meetings constitute a net increase in the amount of process.

> I guess I'm just surprised you haven't hit one or two of these.

Oh I have ... everyone doesn't do enough of the right stuff, and
everyone does too much of the wrong stuff.

The "Advanced" ideas, whether Advanced Scrum or Advanced Waterfall,
are what puts people in the state of mind of doing too much of the
wrong stuff. It's that side of the coin I'm focused on for the
moment.

Ron Jeffries
www.XProgramming.com
There's a difference between righteous anger and just being crabby.
   --Barbara Richmond

On Friday, March 31, 2006, at 1:46:42 AM, Tobias Mayer wrote:

> A team that is doing ad-hoc, code-and-fix, crisis mode development
> is almost certainly doing too much. Introducing the Scrum process
> to such a team is exactly about doing less. Scrum, when
> implemented well, is usually about removal, not addition, don't
> you think?

Exactly! Well put!

Ron Jeffries
www.XProgramming.com
Speak the affirmative; emphasize your choice
by utterly ignoring all that you reject. -- Ralph Waldo Emerson

Hi,

I am a recent addition to the Scrum community and I thought that this
was the right time to throw in my penny's worth after having followed
various threads here for some time.
I see scrum as set of tools (proverbially) that I utilize to better
accomplish my mission (developing better software/solutions). Like
with any toolset, it is up to me to decide which particular tool in
the box I use for any particular aspect of the job and maybe sometimes
I can improve a tool.
But generally I am user of that toolkit. There are, however, the
people that provide the toolkit. These are the guardians, the people
that collect input and form new tools or modify existing tools to
better serve the needs of their customers (us, the scrum masters).
And, as with any toolkit, they are also the ones who mold the
philosophy behind the toolkit.
I as the user can at any point decide that this toolkit doesn't do
what I need it to do and change the kit. I can make proposals, etc.
But I am not the owner.
Ownership belongs to the people that dedicate *all* their time making
scrum a useful toolkit. If that happens to be a group that rallies
around the "inventor", I cannot see anything wrong with it.

Wolfgang

> Tobias,
>
> Most successful movements have vocal, well-known leaders.
>
> Co-located self-organizing teams are one thing, but a widely
> distributed network of barely acquainted, differently motivated people
> like this list doesn't seem like the optimal environment for success.
>
> I'm still waiting for people of the world to self-organize and end
> war, poverty and hunger.
>
> So as far as Ken and/or a small group of lieutentants "owning" or
> maybe "guiding" Scrum, I'm all for it.
>
> XP benefited greatly in it's early days (and still does) from the
> outspoken voices of Kent Beck, Ron Jeffries, Ward Cunningham and
> others.  Even when I disagreed with their positions on specific areas,
> I still appreciated knowing what was "official XP" vs. my variation.
>
> On the other hand, if we can manage to self-organize the evolution of
> Scrum on this list, can world peace be far behind?
>
> --Dave
>
> David Churchville
> http://www.extremeplanner.com/blog
>

There's something biblical in this scenario.

I don't know where Ken was, but he seemed to disappear from this group for
a period of months.  I know that he has had some health issues in the past,
and I hope that he is well.

Moses spent some time away too, and when he came down from the mount with
the 10 Commandments he found the rest of the Israelites had started
worshipping a golden idol in his absence.  Moses got mad.

I'm not trying to say Scrum is a religion, or anything like that, but the
parallels are little too compelling to ignore.

Personally, I'm with Ken 100% on these issues.  There's no need for
"Advanced Scrum (tm)", or "Scrum A", "Scrum B" or whatever.  While it is
true that each and everyone of us adapts Scrum to our own personal
situations - changing the names of things, or bending a rule here and there
- the important thing is that we're all starting from the same starting
point.  No one is thinking, "I've come up with an improved version of
Scrum" and if we moved to a new situation, I think most of us realize that
the best way to adapt would be start from pure Scrum again and find what
works and doesn't work from there.  Not to try to continue evolving from
the adapted version from the last scenario.

Personally, I don't believe I've ever seen anything that would support the
notion that Scrum needs to "evolve", and I certainly don't see that as the
point of this group.  Part of the beauty of Scrum is it's simplicity (at
one level), and it's lack of baggage.  I remain open to the notion that
someone might one day come up with a bona fide improvement to Scrum, but I
reamain unconvinced that there's any underlying need to "evolve or become
extinct" at work right now.


Dave Barrett,
Lawyers' Professional Indemnity Company

Alex,
 
A team that is doing ad-hoc, code-and-fix, crisis mode development is almost certainly doing too much.  Introducing the Scrum process to such a team is exactly about doing less.  Scrum, when implemented well, is usually about removal, not addition, don't you think?
 
Tobias

Alex Pukinskis <Alex.Pukinskis@...> wrote:
 

On 03 30 2006 9:09 PM, "Ron Jeffries" <ronjeffries@...> wrote:

> Every team I have visited in the last ten years has been doing too
> much. Some of them have also been omitting key practices that they
> sorely need, but every single one of them has been doing quaint and
> curious Rococo things that are neither necessary nor productive.
>
> Every single one. That makes me willing to bet that if you are
> reading this right now, your team is doing more than is ideal.

This is fascinating to me.  While it's absolutely true that most
organizations do this, I definitely have worked with some who don't have enough process.  There are startups out there that are doing ad-hoc, code-and-fix, crisis mode development all the time, with no formal process at all.  

Where most companies see waste because they have too much process, these groups constantly churn because they lack the focus and structure Scrum provides.  For them, adding a prioritized backlog, iterations, and daily
standup meetings constitute a net increase in the amount of process.

I guess I'm just surprised you haven't hit one or two of these.

-Alex  

Just imagine, if we could talk about these issues in person... and not
just the "Practicing" CSMs and Trainers.

Oh wait! Agile 2006 is a couple of months away! Now, if only it had an
OpenSpace component... What!! It does!!?

How much fun would that be? Is everyone thinking about the topics they
will propose? I've been thinking about mine for months...

deb

(does anyone not know what OpenSpace is? I'm an OS facilitator, if you
like I can scare up some links for you...)

On Wednesday, March 29, 2006, at 2:51:24 PM, Ken Schwaber wrote:

> Then it isn't an "Advanced ScrumMaster Course." It is a course for
> ScrumMasters to practice their craft. I have to wonder, though, because
> based on the below description, people that don't even know Scrum and aren't
> even grounded in the principles can take an "Advanced ScrumMaster Course"
> and become "Advanced." Where exactly do they learn the basics, and how
> exactly aren't they being misled into believing that there are advanced
> Scrums with more and more practices, rules, and techniques that will make
> them more effective.

Yes, well. If it only takes a few days to be Certified, why would it
take longer to become Advanced? That train already left.

> If this is a course about using the techniques that have been honed
> exquisitely at PatientKeeper, keep it straight and say so. I mean, does
> "more complex environments" include those at Noikia, Motorola, Cisco,
> Microsoft, gaming companies, etc., or what? Have as a prerequisite that the
> people will have a similar context to PatientKeeper and can actually
> somewhat use these.

Do most of the people who enter into the pyramid today already have
a context amenable to Scrum Zero?

Ron Jeffries
www.XProgramming.com
You don't need to see my identification.
These aren't the ideas you're looking for. Move along.

We recently attended the CSM course presented by Victor and Tobias.
One of our contingent was our COO, who happens to also be the former
CEO of First Interstate Bank (which was acquired by Security Pacific,
which was acquired by BofA, and so on... such is the banking business).

Anyway, aside from becoming one of the few banker CSMs (if not the
only), Mike had this to say during the class:

     Scrum is taught by koan.

Which brought to my mind:

     Must resist the urge
     to suggest using haiku
     Way too much structure!

:-)

Bill House

OK, I'll admit it -- I don't know what OpenSpace is.  So, scare away!

Bill House

--- In scrumdevelopment@yahoogroups.com, "Deb" <deborah@...> wrote:
>
> Just imagine, if we could talk about these issues in person... and not
> just the "Practicing" CSMs and Trainers.
>
> Oh wait! Agile 2006 is a couple of months away! Now, if only it had an
> OpenSpace component... What!! It does!!?
>
> How much fun would that be? Is everyone thinking about the topics they
> will propose? I've been thinking about mine for months...
>
> deb
>
> (does anyone not know what OpenSpace is? I'm an OS facilitator, if you
> like I can scare up some links for you...)
>

> From: David A Barrett
>
> Personally, I don't believe I've ever seen anything that would support
the
> notion that Scrum needs to "evolve", and I certainly don't see that as
the
> point of this group.  Part of the beauty of Scrum is it's simplicity
(at
> one level), and it's lack of baggage.  I remain open to the notion
that
> someone might one day come up with a bona fide improvement to Scrum,
but I
> reamain unconvinced that there's any underlying need to "evolve or
become
> extinct" at work right now.
>

I couldn't agree more.  The huge benefit we've seen with Scrum can be
directly attributed to its simplicity.  Our teams have artists,
designers and programmers.  You couldn't have a wider range of people
who look at the world differently.  I can't imagine throwing one of the
more "evolved methodologies" at them.  We'd end up wading through the
practices (perhaps drowning) and never understanding the principles.

This isn't to say we haven't modified things carefully after practicing
Scrum for some time.  At best, we'll share the modifications as stories
at the next gathering.  I love to hear about how others are modifying
their Scrum practices for their own environment.  The insights we gain
from it are enormous.

What's out there now is a beautiful template for anyone starting Scrum.
Any tweaks to it should be done with extreme caution (like a
constitutional amendment).

-------------- Original message --------------
From: "Deb" <deborah@...>

> --- In scrumdevelopment@yahoogroups.com, Steven Farlie wrote:
> >
> > Metrics are usually so hard to do right and give such a false sense of
> > security that I would only recommend it to people that hate metrics. At
> > least they have the right level of skepticism about them.
> > --
> > Steven
> >
>
> Yes, I like this too.
>
> When my colleagues sceptically ask me "why on earth" I was writing on
> metrics recently, my answer embodied this sentiment, though you've
> crystallized it much better than I did when I replied: "if we don't
> write the basics on Agile metrics now, people who worship metrics will
> grab the subject and bury us in meaningless metrics recommendations".
>
> For me, the basics of Agile metrics seem to be:
>
> 1. Measure value delivered
> 2. Figure out how to produce more value (this might require local
> diagnostics like velocity, defect count, whatever a team thinks will help)
> 3. Figure out what doesn't matter any more (and stop measuring it)
> 4. Deliver some value
> 5. Iterate
>
> Your recommendation to include "people who hate metrics" in the
> metrics development process seems very wise to me. It's not going to
> be a pleasant role, but a necessary one. An agile practitioner with
> the maturity to play this role well would be an asset on any team
> (development team, management team) thinking about what to start/stop
> measuring. I specify "agile practitioner" because I think that a deep
> understanding of the Agile Values does inform metrics choices in a
> particular way that enables and protects our teams.
>
> Let's not leave metrics to the metrics-minded!
> (That's why this dyslexic, number-phobic gal is writing on metrics.
> Now, how twisted is that? :-)
>
> ciao
> deb
>
>
>
>
>
>
>
> 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:
> http://docs.yahoo.com/info/terms/
>
>
>

Tobias ... let me presume to offer some comments here ...

On Thursday, March 30, 2006, at 3:13:45 PM, Tobias Mayer wrote:

> When Ken Schwaber posted "Scrum and NonScrum" on Tuesday -
> http://groups.yahoo.com/group/scrumdevelopment/message/12506 -
> many of us breathed a sigh of relief, and posted responses
> accordingly. It seemed fitting that Ken should step in and provide
> clarity to all the confusion. But then I got to thinking...

> Does Ken own Scrum? Are we allowing Ken to own Scrum - are we
> encouraging Ken to own Scrum? Why did it matter so much what Ken
> thought about the whole A/B/C thing? Why were we (some/many of us)
> almost waiting for Ken's verdict on this? I have to wonder, for
> myself, did I want Ken's endorsement on my own point of view, my
> own position on Scrum? Sad answer is yes, yes I did.

I'm not so sure the answer should be sad. Not that Ken is God, or
even /a/ god. Ken raises some valid points, in my opinion, and if
they sting some folks, well, they should.

The essence of Scrum, XP, Agile, is something simple. Yes, there is
a richness to it all -- emergent behavior is like that. But there
are times when what is happening reminds me a lot of the austere
simplicity of Baroque art, compared to the more elaborate and
intricate Rococo.

> But today's exchange on the Rally "Advanced Scrum" course left a
> really bad taste. It was essentially a public telling off from the
> father of Scrum to a wayward child. This is not healthy. This is
> the kind of paternalistic approach that we as "agents of agile
> change" are hoping to overcome within organizations. Yet we
> encourage it here. Something is wrong with that.

I don't see that that follows. First of all, teaching Scrum is not
Scrum. Second, if Scrum is about simplicity and common sense, and
things are being said in its name that are about complexity and
elaboration, then those things are, in some important way, not as
much like Scrum as they might be.

> The original discussions around Scrum Types, whether an advanced
> course was useful/appropriate, etc. were healthy discussions.
> Different points of view were aired. The theme was explored,
> people got passionate, but never offensive, and much was learned.
> To me that felt good. It represented self-organization at it's
> best.

That's fine. I like to talk about the whichness of the why myself.
It helps me learn and helps me understand. But that same behavior
doesn't always help me -- I need to be reminded to do the damn work,
not philosophize all day. And it is not only not helpful, it is
downright harmful to people who do not yet "get" Scrum/XP/Agile.

My experience-based assessment is that people who haven't as yet
done the simple stuff Do Not Get It. They read these deep
discussions and consider these complex variations, and they assume
that those things apply to them. THEY DO NOT APPLY TO THEM.

Every team I have visited in the last ten years has been doing too
much. Some of them have also been omitting key practices that they
sorely need, but every single one of them has been doing quaint and
curious Rococo things that are neither necessary nor productive.

Every single one. That makes me willing to bet that if you are
reading this right now, your team is doing more than is ideal.

> Ken, you started this group, and you have as much right as any of
> us to post messages. And I, for one, am very glad that you are so
> actively involved. But Scrum cannot be owned - by you or anyone.

You're right, it cannot be owned. It has escaped. And not everything
that is happening to it in the wild is going according to at least
some of us who set the thing free.

> Comments like

>> For a while, I thought that I could just "let" Scrum emerge, but I've already seen a number
>> of deleterious trends that will leave it as nothing but another overcomplicated process...

> do not promote the self-organization principle.

Where does it say that the self-organization principle that Scrum
works on is, or should be, part of defining what Scrum itself is?

Now, mind you, I'm all for people working together. But I don't
believe that excellence, precision, sharpness of ideas, clarity, is
a matter of group process.

> Nor does denouncing a training course, that a lot of people are
> interested in, as "not Scrum":

I think it /isn't/ Scrum, not that my opinion is worth much. I think
saying that it isn't Scrum is a valuable and important thing to say.

I think that the course in question might better be called something
like "Advanced Techniques for Scrum Projects".

By my lights, an "Advanced Scrum" class might better focus on how to
do your Scrum stuff more simply -- how to cut away all the fat on
your bloated half-assed attempt at a Scrum project. (I mean that in
the most respectful way, of course.)

>> All participants of the course should be aware that this is not a
>> Scrum course, but a deviant of Scrum course that probably should
>> be using a completely different name. Sigh, I guess it is time to
>> get the name Scrum formally registered as a trademark.

I do think that would be a very serious mistake. However ...

> I have an enormous amount of respect for you, and for all that you
> have done, and continue to do for this community. But now please
> practice the Scrum principles within this group. You cannot be the
> arbiter of all things Scrum. It is an impossible position to
> uphold, and I don't believe you want it anyway.

Think beyond that. Think what must be going on if a founder of a
movement wants to take it back. Think how wrongly things must be
going, in some important way, to elicit that reaction. Recognize
that the ideas and techniques in question are truly important, but
they are somehow nontheless "not Scrum" to this visionary.

Think about that! Someone with a solid vision thinks what's going on
in the Agile arena is screwed up! Two someones, matter of fact!

> I honestly believe the whole issue of Scrum/NotScrum would have
> found its own solution, according to the needs of this community.
> It is not for any one of us to decide on behalf of the Scrum
> community that one idea is right and another wrong.

Maybe it isn't. But I don't mind telling you that I'd like to find a
way to put the Extreme back into Extreme Programming, and to refocus
the whole Agile community back on what I consider to be the
essentials.

> Future issues of this type should be allowed a healthy airing,
> resulting in consensus reached by the community; this may take
> time, and that's okay. I hope you contribute, and I equally hope
> that others in this group (self included) take your comments as
> just one more voice. I think we do you a disservice by raising you
> up to Godfather status.

It's not a matter of elevation. It's something different from that.

> Let Scrum be what it will be. The foundation is rock solid. I vote
> that we trust to that.

I vote that we get back to that.

Ron Jeffries
www.XProgramming.com
We cannot solve our problems with the same thinking we used when we created them.
  -- Albert Einstein

Is it alright to post a request for agile folks on
this listing? We have positions, now.

/hba

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

I'll put something together on OpenSpace and post a link here when
it's ready.

deb

Ron,

One of the main techniques to keep Scrum/XP/Agile simple is inspecting
and adapting. In order to have this principle add to the simplicity of
an agile method it needs focus on (amongst others) removing waste: do
not do/produce things that don't add value.

What is your opionion on these principles (removing waste (muda)): do
they require attention and space & time to think about how waste moved
into our processes, unwanted and unseen? Cause that is what our course
is about, removing waste through study of flow and load.

--Hubert

On 3/31/06, Ron Jeffries <ronjeffries@...> wrote:
> On Thursday, March 30, 2006, at 7:15:01 PM, mike.dwyer1@... wrote:
>
> >  Quite the contrary  Scrum devolves over time.
>
> You use this phrase sometimes, and I assume (and hope) it's
> advisedly.
>
> The Agile methods are, in my opinion, DEvolving. People are tarting
> them up and watering them down, all with good will I have no doubt.
>
> To me, there is an /essential/ simplicity to the ideas behind Agile,
> Scrum, XP. Those ideas can be applied in large and complex
> situations, as Jeff and you, and Jim Highsmith and Glen Alleman, and
> others are showing. Those are good contributions.
>
> However, the elaboration and the watering down, though they make the
> ideas palatable where they'd be rejected, or practical where they'd
> not be robust enough, are, in my opinion literally damaging to the
> essential notion of simplicity.
>
> I make a decent living visiting software teams all around, who are
> trying to do Scrum or XP or Agile of some flavor or other.
> Invariably, and I mean that literally, they are not doing things as
> simply or directly as the methods, as I understand them, truly call
> for.
>
> I do mean invariably. I'd wager my fee double or nothing that I can
> walk into any project in the universe and find something that if
> they did it more simply, more in line with the simple dictates of
> Scrum or XP, they would do better.
>
> I love the richness of Agile. I think about it all the time, try to
> figure out how it works, how to make it work, how to express it so
> that people can understand it, how to fit it to the situations I
> encounter. I've found, over recent years, that I have "softened" my
> story. That makes it easier to sell the ideas, which gets Agile out
> there and helps people who would otherwise not be helped.
>
> But I think it's not entirely consistent with the ideas -- with the
> thing that I perceive as the "real" agile.
>
> So if it has to be Ken and me against the world ... I'm glad to have
> him back on line. Besides, he makes me look reasonable. ;->
>
> Ron Jeffries
> www.XProgramming.com
> If it is more than you need, it is waste. -- Andy Seidl
>
>
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com
> Yahoo! Groups Links
>
>
>
>
>
>
>


--

All opinions in this message are my own, and are not necessarily
shared by my employer.

--- In scrumdevelopment@yahoogroups.com, mike.dwyer1@... wrote:
>
> Deb;
> metrics in Agile and Scrum are simple.
> ...
>
> Anything else is feed for a chicken meeting.
> --

So, Mike:

Are "chicken meetings" less important? If the organization is
well-aligned, everyone's meetings should be about delivering value,
right? Ok, those in the non-agile parts of the organization may have
waaaay more waste... but it can't be constructive to look down our
noses at them (yes, it is tempting :-).

Let's simply assume they don't know any better yet. And, if we can
clearly show them the progress we are making, perhaps we can model a
different approach to them? This would be my hope in increasing
transparency through careful use of *value* metrics outside the team.

Eventual goal: break down the us/them wall and all get on with
delivering value...

deb
(someone's got to dream)

--- In scrumdevelopment@yahoogroups.com, mike.dwyer1@... wrote:
> ... Scrum devolves over time.
>
> What do I mean.  Scrum, as taught in the class, enters into the
> rhythm of an organization, not just the team.  People become used
> to and expect to have information on the questions 3, as trust
> builds information is shared over blurred lines of chickens pigs..

That first quoted line caught my eye again today. I think I agree with
your idea, Mike. But I think that it's not Scrum that devolves, but
team process. Let me explain. It's semantic, so change the channel now
if you hate that stuff.

I'm not sure that what we implement is Scrum. (GASP!!!) I've told
clients that Scrum is what's in the book, it's abstract. (As such,
it's pretty stable). I tell them that as soon as we implement it we
are doing "Scrum at ABC Corp." and that each implementation is
slightly different. (Yes, even though I *urge* them to keep to the
classic pattern at the beginning).

I think that Scrum is what we teach. It's the destination we aim at
when we get on our bicycle and start making course corrections - it's
a reference point, tells us where we are straying, if we care to look.
It is very useful that way, especially in its relatively "simple"
original form.

But Scrum Implemented, like everything to do with human nature, is
rife with trade-offs. Hopefully, only small ones, or at least
temporary ones.

:-)  deb

On Friday, March 31, 2006, at 3:49:03 PM, Hubert Smits wrote:

> One of the main techniques to keep Scrum/XP/Agile simple is inspecting
> and adapting. In order to have this principle add to the simplicity of
> an agile method it needs focus on (amongst others) removing waste: do
> not do/produce things that don't add value.

Yes ...

> What is your opionion on these principles (removing waste (muda)): do
> they require attention and space & time to think about how waste moved
> into our processes, unwanted and unseen?

Yes, of course, removing waste is good. In addition, I think use of
the Japanese terms, muda, mura, and mudi is pretentious and whatever
the opposite of mnemonic is.

Yes, of course, the principles do require attention.

> Cause that is what our course is about, removing waste through
> study of flow and load.

That's likely a good thing for a course to be about. I'd like all
such courses to have names like "Simplifying Scrum" or "Reluctantly
Adding Practices to Scrum in Unique Circumstances Which Probably
Don't Apply to You", rather than names like "Advanced Scrum", or for
that matter "<anyAdjective/> Scrum". Course names of the latter kind
suggest that there are "kinds" or "types" of Scrum. I believe that
to be harmful.

Ron Jeffries
www.XProgramming.com
Comments lie. Code doesn't.

On Friday, March 31, 2006, at 2:03:40 PM, Tobias Mayer wrote:

> Thanks for the thoughtful comments. As always, you show great
> insight. I wholeheartedly agree that Scrum (and other practices
> being carried out in the name of Agile) are becoming more
> complicated than they need to be; I'd also like to see a return to
> simplicity.

I look forward to seeing your work in that regard!

> As to having leadership and guidance from the founders of the
> movement, I have no argument with that either, but recognize that
> it is a short term solution. People die, and then what? Elected
> committees, self-appointed generals? Better perhaps, to just
> encourage self-organization from the start.

Does someone own Nuclear Physics, or Internal Medicine? I don't
think so. People /contribute to/ these things. What's going on in
Agile is that people are trying to /define/ these things. I am
extremely skeptical of the motives of at least some of those people.

>> Where does it say that the self-organization principle that Scrum
>> works on is, or should be, part of defining what Scrum itself is?

> It doesn't say that anywhere, to my knowledge. But that doesn't
> mean it isn't a good idea. Equally, it doesn't mean that it is.
> May be worth a few thought-cycles though. Of course, it doesn't
> really matter how Scrum is defined, or where it is written down;
> it will change. Sometimes in good ways, sometimes not. In the end,
> I believe the name will disappear, anyway, into an historical
> footnote as people realize this is just a natural, effective and
> enjoyable way of working. Like Ken says, this is not a
> methodology, this is a path. The world is changing; we are just a
> tiny part of a massive paradigm shift, a cog in the wheels of the
> next revolution. And yes, I am an idealist. :-)

Yes. I'm reminded here that in my opinion, Scrum, or XP, or Agile,
are not a "thing". They are not subject to definition or refinement
in any useful way. They are more like the names of schools of art or
of dance or of types of music.

>> But I don't mind telling you that I'd like to find a way to put
>> the Extreme back into Extreme Programming, and to refocus the
>> whole Agile community back on what I consider to be the
>> essentials.

> Let's focus it forward instead.  There is exciting, uncharted
> territory out there.  And dragons.

The current focus seems to me to be on elaboration, and branding.
The former is potentially valuable, the latter is in my opinion
deeply pernicious.

I would like to see more focus on simplifying, and I would like to
see the elaboration that is done include the focus on
simplification. Creating new types of Scrum, each more amazingly
complex than the last, concerns me deeply. I think it's wrong.

> Glad to know you, and proud to be a part of this community.

Thanks ...

Ron Jeffries
www.XProgramming.com
Just because XP doesn't talk about how to make fire, should we assume it
requires us to use sticks? -- Richard MacDonald

On Friday, March 31, 2006, at 8:14:30 PM, Jacobs, Jeffrey wrote:

> I'm probably the only person on this list that every wrote a program in
> Simula-67; I wont' say when other than it was later than 1967 :-)

> If you follow the link I provided, you'll clearly find that Simula-67 a)
> defined the principles and

Yes, there is no doubt that SImul67 first had classes and objects,
and that they called them classes and objects.

> b) first used the term; no need to rely on
> your memory.

I read the article, and searched it for all sentences containing the
string "orient". I see no instance where the paper says that the
term "object oriented" was in use with Simula 67. The references to
the term seem to me to be referring to the phrase as if it came into
use later.

Perhaps you could quote the part that you think nails down the term
"object oriented" as being invented back in the time of S67.

Not that it matters ...

> Or you can rely on my memory, which is very clear in this area :-)

As is my memory of being in the room at OOPSLA when Kay said what I
quoted.

Ron Jeffries
www.XProgramming.com
Any errors you find in this are the work of Secret Villains,
whose mad schemes will soon be revealed. -- Wil McCarthy

--- In scrumdevelopment@yahoogroups.com, Ron Jeffries
<ronjeffries@...> wrote:
>
> Huh? PO comes in, says what they want. Team draws a line. How do
> priorities like HML come into that?

I have /never/ been on a project where the team interation has been as
simple as you've suggested above ... certainly not at the start of a
project. On most projects that I've experienced, the very first sprint
planning meeting is long and difficult while the team discusses what
they currently have, and challenge the PO on the scope of the project.

I love the simplicity of what you describe, but it's doesn't jell with
what I've experienced. Maybe I've still got a lot to learn.

Best regards,
Kane Mar
W: http://www.Danube.com
B: http://KaneMar.Wordpress.com