--- In scrumdevelopment@yahoogroups.com, "aefager" <aefager@...> wrote:

> I just want to get a clarification here.
> 1. You are a proponent of accurate estimation.
> 2. You are a proponent of Scrum.
> 3. You are a proponent of story points over hours.
>
> Does this mean that in a burndown chart, you would use story points,
> in place of hours?  Do you still have burndowns, and are now doing
> them on story points, or did I misunderstand?
>


What I have found that works best for the teams I work with, is sizing
points at the story level withing the product backlog, and then
estimating hours for each task identified for each planned story
during sprint planning.  This is also what Mike Cohn speaks about in
his "Agile Estimation and Planning" session.  This way you are able to
have a Sprint Burndown in hours, reflecting work remaining for the
sprint, and Release Burndown or Product Burndown in Story Points.

Giora Morein
gmorein@...

Documentation:

One cannot say that 'agile development methodologies do not document'.
Different methodologies have different opinions about documentation. I think
XP is the most extreme but FDD or the Crystal family have more
documentation.

The point about documentation is that is should be 'barily enough'. The more
documentation you have the more effort you need to keep it synchronized.
Keeping things synchronized is process waste.

Posibilities to eliminate this waste is either generating the documentation
from your sourcecode (e.g. JavaDoc) or use a coarse granularity of
documentation. An example is 'user stories' instead of RUP style 'Use
Cases'. (And yes, I have intensively worked with the 10-page use cases of
RUP...)

Personally I think that the value of documentation is overvalued. I'm
currently creating a Java version of a propriatary company communication
framework and even though there is quite some documentation I trust the
sourcecode to tell me everything, not the documentation.

I'd suggest to pick up a copy of Alistair Cockburn's 'Agile Software
Development'  (ISBN 0-201-69969-9). It gives a thorough description of the
powers that influence software development. Chapter one includes gems such
as 'Continuus Documentation, Just Never Documentation and Suffiency of Work
Products'.

Support:
Again, I do not see why agile could be bad for support. Support is just
another backlog item that the product owner gets to schedule. In case your
most valued customer reports a showstopper of the kind
'we-go-bankrupt-if-you-dont-fix-it-and-we-will-drag-you-down-with-us'  you
can always cancel your current sprint. However most support issues can wait
until the next sprint. This helps you keep focussed, gives you rest during a
sprint and gives ease of mind to the product owner because she knows she
will be able to have it scheduled at next sprint.

In both cases I speak from real world, not from book knowledge (I have added
the book knowledge later).

Maurice le Rutte.

>From: "Rohilla, Pryank" <pryank.rohilla@...>
>Reply-To: scrumdevelopment@yahoogroups.com
>To: <scrumdevelopment@yahoogroups.com>
>Subject: RE: [scrumdevelopment] Digest Number 1533
>Date: Tue, 1 Aug 2006 16:43:11 +0100
>
>Hi,
>
>I am a developer doing some support work of an agile project. My team mate
>keep criticising agile methodologies. His points are: Agile is not good for
>Support as it doesn't provide proper documentation of developed
>applications and it's a pain to support projects developed using agile.
>
>
>
>Can some of you agile gurus point out how Agile helps in doing support of
>live applications?
>
>

_________________________________________________________________
Iets leuks meegemaakt? Zet het op je Space! www.spacemomentje.nl/start.aspx

Documentation should be a part of the product to the degree required by the
Product Owner. In other words, if a product does not have documentation
written (once the relevant code has been completed, that is, so that your
documentation is actually valid) , it is not the fault of the process
(Agile), but of the Product Owner (or Product Manager or whatever you want
to call the guy responsible for overall development/management of that
product).

The question of supporting live applications is not really connected to the
development methodology, it is connected to the artifacts defined as part of
the product by the Product Owner. Insofar, your last question doesn't really
make sense.

Your team mate suffers from a very common problem: shortsightedness.

Many subscribers on this list will also answer along the lines of "Agile
methods help the support of live applications by inherently producing higher
quality code, which requires less support" and I can definitely subscribe to
that.

Regards,

Wolfgang



> -----Original Message-----
> From: scrumdevelopment@yahoogroups.com
> [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Rohilla, Pryank
> Sent: 01 August 2006 16:43
> To: scrumdevelopment@yahoogroups.com
> Subject: RE: [scrumdevelopment] Digest Number 1533
>
> Hi,
>
> I am a developer doing some support work of an agile project.
> My team mate keep criticising agile methodologies. His points
> are: Agile is not good for Support as it doesn’t provide
> proper documentation of developed applications and it’s a
> pain to support projects developed using agile.
>
>
>
> Can some of you agile gurus point out how Agile helps in
> doing support of live applications?
>
>
>
> Pryank
>
>
>
> ________________________________
>
> From: scrumdevelopment@yahoogroups.com
> [mailto:scrumdevelopment@yahoogroups.com]
> Sent: 30 July 2006 11:51
> To: scrumdevelopment@yahoogroups.com
> Subject: [scrumdevelopment] Digest Number 1533
>
>
>
> Scrum Users
> <http://groups.yahoo.com/group/scrumdevelopment;_ylc=X3oDMTJkM
G8wZzM2BF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBHNlYwNoZ
HIEc2xrA2hwaARzdGltZQMxMTU0MjU2Njg0>
>
> Messages In This Digest (9 Messages)
>
> 1a.
>
> Are SCRUM and XP actually Process Oriented? From: Vickydhiman
>
> 1b.
>
> Agile 2.0 From: Marco Abis
>
> 1c.
>
> Re: Are SCRUM and XP actually Process Oriented? From: Ron Jeffries
>
> 1d.
>
> Re: Are SCRUM and XP actually Process Oriented? From: Steven Gordon
>
> 1e.
>
> Re: Are SCRUM and XP actually Process Oriented? From: Vickydhiman
>
> 1f.
>
> Re: Are SCRUM and XP actually Process Oriented? From: Ilja Preuss
>
> 1g.
>
> Re: Are SCRUM and XP actually Process Oriented? From:
> PaulOldfield1@...
>
> 1h.
>
> Re: Are SCRUM and XP actually Process Oriented? From: Ron Jeffries
>
> 2.
>
> Re: [XP] Agile 2.0 From: Ron Jeffries
>
> View All Topics
> <http://groups.yahoo.com/group/scrumdevelopment/messages;_ylc=
X3oDMTJma29oaXVqBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIx
BHNlYwNkbXNnBHNsawNhdHBjBHN0aW1lAzExNTQyNTY2ODQ-?xm=1&m=p&tidx=1>  | Create
> New Topic
> <http://groups.yahoo.com/group/scrumdevelopment/post;_ylc=X3oD
MTJmMmJwMXMyBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBHNl
YwNkbXNnBHNsawNudHBjBHN0aW1lAzExNTQyNTY2ODQ->
>
> Messages
>
> 1a.
>
> Are SCRUM and XP actually Process Oriented?
> <http://groups.yahoo.com/group/scrumdevelopment/message/14963;
> _ylc=X3oDMTJyb2JhdW4zBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTYzBHNlYwNkbXNnBHNsawN2bXNnBHN
> 0aW1lAzExNTQyNTY2ODQ->
>
> Posted by: "Vickydhiman" vickydhiman@...
> <mailto:vickydhiman@...?Subject=Re:%20Are%20SCRUM%20and%
> 20XP%20actually%20Process%20Oriented%3F>   vickydhiman
> <http://profiles.yahoo.com/vickydhiman>
>
> Sat Jul 29, 2006 2:54 am (PST)
>
> I understand Agile focuses *more on* interaction and
> collaboration rather than processes. However, someone
> recently asked me, is not updating product backlog, having
> sprint meetings, release planning - all basically a process?
> It may be a more effective process but it is a process. Do you agree?
>
> I said its not a process, its a light weight framework and is
> different from a process. Then he asked me whats the
> difference between the two. I tried to Google it out with no luck.
>
> Any thoughts?
>
> Thanks
>
> Vicki
>
>
> ---------------------------------
> Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US
> (and 30+ countries) for 2¢/min or less.
>
> Back to top
>
> Reply to sender
> <mailto:vickydhiman@...?Subject=Re:%20Are%20SCRUM%20and%
> 20XP%20actually%20Process%20Oriented%3F> | Reply to group
> <mailto:scrumdevelopment@yahoogroups.com?Subject=Re:%20Are%20S
> CRUM%20and%20XP%20actually%20Process%20Oriented%3F> | Reply
> via web post
> <http://groups.yahoo.com/group/scrumdevelopment/post;_ylc=X3oD
MTJyYXUwOTNrBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBG1z
Z0lkAzE0OTYzBHNlYwNkbXNnBHNsawNycGx5BHN0aW1lAzExNTQyNTY2ODQ-?>
act=reply&messageNum=14963>
> Messages in this topic
> <http://groups.yahoo.com/group/scrumdevelopment/message/14963;
> _ylc=X3oDMTM3bm9ucmx1BF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTYzBHNlYwNkbXNnBHNsawN2dHBjBHN
> 0aW1lAzExNTQyNTY2ODQEdHBjSWQDMTQ5NjM-> (8)
>
> 1b.
>
> Agile 2.0
> <http://groups.yahoo.com/group/scrumdevelopment/message/14964;
> _ylc=X3oDMTJyaDNrYXFkBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTY0BHNlYwNkbXNnBHNsawN2bXNnBHN
> 0aW1lAzExNTQyNTY2ODQ->
>
> Posted by: "Marco Abis" abis@...
> <mailto:abis@...?Subject=Re:%20Agile%202%2E0>
> capotribu <http://profiles.yahoo.com/capotribu>
>
> Sat Jul 29, 2006 3:04 am (PST)
>
> Please tell me it's a joke :-)
>
> Scott Ambler has published some interesting data related to a
> surveys done via Dr. Dobb's Journal. Questions, raw data and
> summary here http://www.ambysoft.com/surveys/
> <http://www.ambysoft.com/surveys/>
>
> In the last slide of the summary presentation (ppt) I read:
> "There was a statistical correlation between adoption of
> "Agile 2.0" methods such as Agile Unified Process (AUP) or
> MSF Agile and adoption of Agile Model Driven Development (AMDD)"
>
> Please please please can we try to avoid such a thing as Agile 2.0?
> And who says that AUP, MSF Agile and AAMD are Agile 2.0? what
> do we/you/they mean by Agile 2.0? I still am not sure AUP and
> MSF Agile are "Agile 1.0"... ;-)
>
> Marco Abis
>
> "let's not talk about Type A Scrum unless we also want to
> talk about Type W Scrum, which is more commonly called
> Waterfall" (Mike Cohn)
>
> http://www.agilemovement.it <http://www.agilemovement.it>  ::
> Italian Agile Movement
>
> Back to top
>
> Reply to sender
> <mailto:abis@...?Subject=Re:%20Agile%202%2E0> |
> Reply to group
> <mailto:scrumdevelopment@yahoogroups.com?Subject=Re:%20Agile%2
> 02%2E0> | Reply via web post
> <http://groups.yahoo.com/group/scrumdevelopment/post;_ylc=X3oD
MTJyY3EyZXMyBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBG1z
Z0lkAzE0OTY0BHNlYwNkbXNnBHNsawNycGx5BHN0aW1lAzExNTQyNTY2ODQ-?>
act=reply&messageNum=14964>
> Messages in this topic
> <http://groups.yahoo.com/group/scrumdevelopment/message/14963;
> _ylc=X3oDMTM3N3J0NzNtBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTY0BHNlYwNkbXNnBHNsawN2dHBjBHN
> 0aW1lAzExNTQyNTY2ODQEdHBjSWQDMTQ5NjM-> (8)
>
> 1c.
>
> Re: Are SCRUM and XP actually Process Oriented?
> <http://groups.yahoo.com/group/scrumdevelopment/message/14965;
> _ylc=X3oDMTJyNmw1YjRzBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTY1BHNlYwNkbXNnBHNsawN2bXNnBHN
> 0aW1lAzExNTQyNTY2ODQ->
>
> Posted by: "Ron Jeffries" ronjeffries@...
> <mailto:ronjeffries@...?Subject=%20Re%3A%20Are%20SCRUM%20a
> nd%20XP%20actually%20Process%20Oriented%3F>   RonaldEJeffries
> <http://profiles.yahoo.com/RonaldEJeffries>
>
> Sat Jul 29, 2006 5:00 am (PST)
>
> On Saturday, July 29, 2006, at 5:53:26 AM, Vickydhiman wrote:
>
> > I understand Agile focuses *more on* interaction and collaboration
> > rather than processes. However, someone recently asked me, is not
> > updating product backlog, having sprint meetings, release planning
> > - all basically a process? It may be a more effective
> process but it
> > is a process. Do you agree?
>
> > I said its not a process, its a light weight framework and is
> > different from a process. Then he asked me whats the difference
> > between the two. I tried to Google it out with no luck.
>
> > Any thoughts?
>
> It's a process. A process is "what you do". Everyone has a process.
>
> As you point out, the manifesto says "this OVER that", not
> "this INSTEAD OF that", and we said it that way, and
> emphasized it, on purpose. In that line we had in mind that
> we will need good processes and good tools. But what we need
> most is good people working well together.
>
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide whether
> it's true for you.
>
> Back to top
>
> Reply to sender
> <mailto:ronjeffries@...?Subject=%20Re%3A%20Are%20SCRUM%20a
> nd%20XP%20actually%20Process%20Oriented%3F> | Reply to group
> <mailto:scrumdevelopment@yahoogroups.com?Subject=%20Re%3A%20Ar
> e%20SCRUM%20and%20XP%20actually%20Process%20Oriented%3F> |
> Reply via web post
> <http://groups.yahoo.com/group/scrumdevelopment/post;_ylc=X3oD
MTJyMzRjYzlsBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBG1z
Z0lkAzE0OTY1BHNlYwNkbXNnBHNsawNycGx5BHN0aW1lAzExNTQyNTY2ODQ-?>
act=reply&messageNum=14965>
> Messages in this topic
> <http://groups.yahoo.com/group/scrumdevelopment/message/14963;
> _ylc=X3oDMTM3dGJkcTFqBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTY1BHNlYwNkbXNnBHNsawN2dHBjBHN
> 0aW1lAzExNTQyNTY2ODQEdHBjSWQDMTQ5NjM-> (8)
>
> 1d.
>
> Re: Are SCRUM and XP actually Process Oriented?
> <http://groups.yahoo.com/group/scrumdevelopment/message/14966;
> _ylc=X3oDMTJyajhua2NtBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTY2BHNlYwNkbXNnBHNsawN2bXNnBHN
> 0aW1lAzExNTQyNTY2ODQ->
>
> Posted by: "Steven Gordon" sgordonphd@...
> <mailto:sgordonphd@...?Subject=%20Re%3A%20Are%20SCRUM%20
> and%20XP%20actually%20Process%20Oriented%3F>   sfman2k
> <http://profiles.yahoo.com/sfman2k>
>
> Sat Jul 29, 2006 5:17 am (PST)
>
> The agile approaches are empirical or adaptive processes as
> opposed to defined or deterministic processes.
>
> The difference is that agile processes are less rigid and
> driven by principles rather than perscription. This allows
> teams to adapt the process to context, which in turn allows
> the process to be more concise and lightweight (because the
> process does not have to explicitly cover every contingency).
>
> On 7/29/06, Vickydhiman <vickydhiman@...
> <mailto:vickydhiman%40yahoo.com> > wrote:
> >
> >
> >
> >
> >
> >
> > I understand Agile focuses *more on* interaction and collaboration
> > rather than processes. However, someone recently asked me, is not
> > updating product backlog, having sprint meetings, release
> planning - all basically a process?
> > It may be a more effective process but it is a process. Do
> you agree?
> >
> > I said its not a process, its a light weight framework and is
> > different from a process. Then he asked me whats the difference
> > between the two. I tried to Google it out with no luck.
> >
> > Any thoughts?
> >
> > Thanks
> >
> > Vicki
> >
> >
> > ________________________________
> > Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the
> US (and 30+
> > countries) for 2¢/min or less.
> >
> >
> >
> >
>
> Back to top
>
> Reply to sender
> <mailto:sgordonphd@...?Subject=%20Re%3A%20Are%20SCRUM%20
> and%20XP%20actually%20Process%20Oriented%3F> | Reply to group
> <mailto:scrumdevelopment@yahoogroups.com?Subject=%20Re%3A%20Ar
> e%20SCRUM%20and%20XP%20actually%20Process%20Oriented%3F> |
> Reply via web post
> <http://groups.yahoo.com/group/scrumdevelopment/post;_ylc=X3oD
MTJyajM4dnJ2BF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBG1z
Z0lkAzE0OTY2BHNlYwNkbXNnBHNsawNycGx5BHN0aW1lAzExNTQyNTY2ODQ-?>
act=reply&messageNum=14966>
> Messages in this topic
> <http://groups.yahoo.com/group/scrumdevelopment/message/14963;
> _ylc=X3oDMTM3dnRqcnBlBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTY2BHNlYwNkbXNnBHNsawN2dHBjBHN
> 0aW1lAzExNTQyNTY2ODQEdHBjSWQDMTQ5NjM-> (8)
>
> 1e.
>
> Re: Are SCRUM and XP actually Process Oriented?
> <http://groups.yahoo.com/group/scrumdevelopment/message/14967;
> _ylc=X3oDMTJyZ3ZxMHJyBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTY3BHNlYwNkbXNnBHNsawN2bXNnBHN
> 0aW1lAzExNTQyNTY2ODQ->
>
> Posted by: "Vickydhiman" vickydhiman@...
> <mailto:vickydhiman@...?Subject=%20Re%3A%20Are%20SCRUM%2
> 0and%20XP%20actually%20Process%20Oriented%3F>   vickydhiman
> <http://profiles.yahoo.com/vickydhiman>
>
> Sat Jul 29, 2006 5:30 am (PST)
>
> Interesting comments from Steven and Ron. I am not sure if I
> have "THE" answer.
>
> I might be wrong but the key is to define what is difference
> between process and framework. Probably a very loose version
> if the a very light weight process which is based more on
> principles then set amount of dos and donts is a framework.
> Or probably framework is collection of some best practices.
>
> However, some people in my team find SCRUM is rigid where it
> wants to be [daily meetings, release planning, product
> backlog et al].
>
> Another possible version is that Agile focusses on processes
> that facilitate communication and collaboration in the team
> and with the customer. I am not very familiar with RUP [I
> think frequent delivery/ daily meetings/ transparency/
> debunking processions/ TDD can be achieved with RUP as well]
> but I guess it also focusses on the same BUT it also focusses
> on whole lot other things. Is that the main difference?
>
> Thanks
>
> Vicki
>
> Steven Gordon <sgordonphd@...
> <mailto:sgordonphd%40gmail.com> > wrote: The agile approaches
> are empirical or adaptive processes as opposed to defined or
> deterministic processes.
>
> The difference is that agile processes are less rigid and
> driven by principles rather than perscription. This allows
> teams to adapt the process to context, which in turn allows
> the process to be more concise and lightweight (because the
> process does not have to explicitly cover every contingency).
>
> On 7/29/06, Vickydhiman <vickydhiman@...
> <mailto:vickydhiman%40yahoo.com> > wrote:
> >
> >
> >
> >
> >
> >
> > I understand Agile focuses *more on* interaction and collaboration
> > rather than processes. However, someone recently asked me, is not
> > updating product backlog, having sprint meetings, release
> planning - all basically a process?
> > It may be a more effective process but it is a process. Do
> you agree?
> >
> > I said its not a process, its a light weight framework and is
> > different from a process. Then he asked me whats the difference
> > between the two. I tried to Google it out with no luck.
> >
> > Any thoughts?
> >
> > Thanks
> >
> > Vicki
> >
> >
> > ________________________________
> > Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the
> US (and 30+
> > countries) for 2¢/min or less.
> >
> >
> >
> >
>
>
>
>
>
> ---------------------------------
> Yahoo! Music Unlimited - Access over 1 million songs.Try it free.
>
> Back to top
>
> Reply to sender
> <mailto:vickydhiman@...?Subject=%20Re%3A%20Are%20SCRUM%2
> 0and%20XP%20actually%20Process%20Oriented%3F> | Reply to
> group
> <mailto:scrumdevelopment@yahoogroups.com?Subject=%20Re%3A%20Ar
> e%20SCRUM%20and%20XP%20actually%20Process%20Oriented%3F> |
> Reply via web post
> <http://groups.yahoo.com/group/scrumdevelopment/post;_ylc=X3oD
MTJybzc0ZG41BF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBG1z
Z0lkAzE0OTY3BHNlYwNkbXNnBHNsawNycGx5BHN0aW1lAzExNTQyNTY2ODQ-?>
act=reply&messageNum=14967>
> Messages in this topic
> <http://groups.yahoo.com/group/scrumdevelopment/message/14963;
> _ylc=X3oDMTM3Y29hcHI0BF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTY3BHNlYwNkbXNnBHNsawN2dHBjBHN
> 0aW1lAzExNTQyNTY2ODQEdHBjSWQDMTQ5NjM-> (8)
>
> 1f.
>
> Re: Are SCRUM and XP actually Process Oriented?
> <http://groups.yahoo.com/group/scrumdevelopment/message/14968;
> _ylc=X3oDMTJyZGE2dG8wBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTY4BHNlYwNkbXNnBHNsawN2bXNnBHN
> 0aW1lAzExNTQyNTY2ODQ->
>
> Posted by: "Ilja Preuss" it@...
> <mailto:it@...?Subject=%20Re%3A%20Are%20SCRUM%20and%
> 20XP%20actually%20Process%20Oriented%3F>   ipreussde
> <http://profiles.yahoo.com/ipreussde>
>
> Sat Jul 29, 2006 5:46 am (PST)
>
> To me the difference is that for an Agile time, the process
> is there to serve the people - in contrast to the people
> being there to execute a prescribed process.
>
> If a team finds that some Scrum (or XP, Crystal, etc.)
> practice isn't helping them, they are supposed to stop doing
> it (or, if they are new to it, preferably try to find out
> whether they could make it work by doing it differently).
>
> Cheers, Ilja
>
> Back to top
>
> Reply to sender
> <mailto:it@...?Subject=%20Re%3A%20Are%20SCRUM%20and%
> 20XP%20actually%20Process%20Oriented%3F> | Reply to group
> <mailto:scrumdevelopment@yahoogroups.com?Subject=%20Re%3A%20Ar
> e%20SCRUM%20and%20XP%20actually%20Process%20Oriented%3F> |
> Reply via web post
> <http://groups.yahoo.com/group/scrumdevelopment/post;_ylc=X3oD
MTJyOXZkMjB1BF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBG1z
Z0lkAzE0OTY4BHNlYwNkbXNnBHNsawNycGx5BHN0aW1lAzExNTQyNTY2ODQ-?>
act=reply&messageNum=14968>
> Messages in this topic
> <http://groups.yahoo.com/group/scrumdevelopment/message/14963;
> _ylc=X3oDMTM3NWc2NnB0BF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTY4BHNlYwNkbXNnBHNsawN2dHBjBHN
> 0aW1lAzExNTQyNTY2ODQEdHBjSWQDMTQ5NjM-> (8)
>
> 1g.
>
> Re: Are SCRUM and XP actually Process Oriented?
> <http://groups.yahoo.com/group/scrumdevelopment/message/14969;
> _ylc=X3oDMTJyaGkzdTVvBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTY5BHNlYwNkbXNnBHNsawN2bXNnBHN
> 0aW1lAzExNTQyNTY2ODQ->
>
> Posted by: "PaulOldfield1@..." PaulOldfield1@...
> <mailto:PaulOldfield1@...?Subject=%20Re%3A%20Are%20SCRUM%2
> 0and%20XP%20actually%20Process%20Oriented%3F>   pauloldfield1
> <http://profiles.yahoo.com/pauloldfield1>
>
> Sat Jul 29, 2006 6:15 am (PST)
>
> (responding to Vicki)
>
> I'll attempt an answer, hope it gives more light than obfuscation...
>
> > I might be wrong but the key is to define what is
> difference between
> > process and framework. Probably a very loose version if the a very
> > light weight process which is based more on principles then
> set amount
> > of dos and donts is a framework. Or probably framework is
> collection
> > of some best practices.
>
> A framework is something on which we select and hang good practices.
> A framework with a set of practices is a process. In building
> a framework we almost certainly have to identify some
> practices as 'best'. i.e. each instantiation of the framework
> will include these practices because they are part of the framework.
>
> For example, the RUP framework is Risk driven (a 'best'
> practice in RUP). As a result it comes with 4 out-of-the-box
> phases that focus on specific types of risk, in sequence. It
> comes with a vast array pf practices that we may choose to
> adopt, omit or modify. Unfortunately all too many folk try to
> adopt the lot and end up with more process than product.
> These 4 phases are also a good practice - in theory they can
> be added to or modified, but the practice is so good that few
> RUP projects change them.
> In reality, people who know better in this respect would not
> choose to do RUP.
>
>
> For example? A really agile team may knock off the risks to
> be addressed in RUP's Inception and Elaboration phases well
> within the first 2 weeks, so the overhead of doing these
> phases formally is not warranted.
>
> Bear in mind these are opinions, feel free to differ.
>
> Paul Oldfield
>
> Back to top
>
> Reply to sender
> <mailto:PaulOldfield1@...?Subject=%20Re%3A%20Are%20SCRUM%2
> 0and%20XP%20actually%20Process%20Oriented%3F> | Reply to
> group
> <mailto:scrumdevelopment@yahoogroups.com?Subject=%20Re%3A%20Ar
> e%20SCRUM%20and%20XP%20actually%20Process%20Oriented%3F> |
> Reply via web post
> <http://groups.yahoo.com/group/scrumdevelopment/post;_ylc=X3oD
MTJyZHVvam0xBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBG1z
Z0lkAzE0OTY5BHNlYwNkbXNnBHNsawNycGx5BHN0aW1lAzExNTQyNTY2ODQ-?>
act=reply&messageNum=14969>
> Messages in this topic
> <http://groups.yahoo.com/group/scrumdevelopment/message/14963;
> _ylc=X3oDMTM3djdsNzM4BF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTY5BHNlYwNkbXNnBHNsawN2dHBjBHN
> 0aW1lAzExNTQyNTY2ODQEdHBjSWQDMTQ5NjM-> (8)
>
> 1h.
>
> Re: Are SCRUM and XP actually Process Oriented?
> <http://groups.yahoo.com/group/scrumdevelopment/message/14970;
> _ylc=X3oDMTJyYmJ2Z2RvBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTcwBHNlYwNkbXNnBHNsawN2bXNnBHN
> 0aW1lAzExNTQyNTY2ODQ->
>
> Posted by: "Ron Jeffries" ronjeffries@...
> <mailto:ronjeffries@...?Subject=%20Re%3A%20Are%20SCRUM%20a
> nd%20XP%20actually%20Process%20Oriented%3F>   RonaldEJeffries
> <http://profiles.yahoo.com/RonaldEJeffries>
>
> Sat Jul 29, 2006 8:30 am (PST)
>
> On Saturday, July 29, 2006, at 8:30:23 AM, Vickydhiman wrote:
>
> > Interesting comments from Steven and Ron. I am not sure if
> I have "THE" answer.
>
> > I might be wrong but the key is to define what is
> difference between
> > process and framework. Probably a very loose version if the a very
> > light weight process which is based more on principles then
> set amount
> > of dos and donts is a framework. Or probably framework is
> collection
> > of some best practices.
>
> Vicky, I don't think that's key at all. I think that what's
> key is what the people actually /do/.
>
> > However, some people in my team find SCRUM is rigid where
> it wants to
> > be [daily meetings, release planning, product backlog et al].
>
> Rigid? You know people who call that rigid? What are they
> doing now, coming in to work if and when they feel like it? ;->
>
> > Another possible version is that Agile focusses on processes that
> > facilitate communication and collaboration in the team and with the
> > customer. I am not very familiar with RUP [I think frequent
> delivery/
> > daily meetings/ transparency/ debunking processions/ TDD can be
> > achieved with RUP as well]
>
> Of these, frequent delivery, for some use of the word
> "frequent", is important in RUP. The others are not terms I
> generally read in the RUP literature. But RUP isn't even a
> process, if we must use the word. RUP is a "process
> framework". That is, it's a big laundry list of ideas that
> all hang together in a reasonable-seeming pattern.
>
> > but I guess it also focusses on
> > the same BUT it also focusses on whole lot other things. Is
> that the
> > main difference?
>
> I think I'd advise not worrying much about differentiating
> Agile vs anything, or process vs framework. I'd advise
> learning what Agile teaches, what the key practices are, and
> so on. And having learned what they are, I'd advising trying them.
>
> What matters isn't the headings on the folders in our filing
> cabinet: what matters is what we do with the materials in there.
>
> Ron Jeffries
> www.XProgramming.com
> In programming, do, or undo. There is always try. --Yoda
>
> Back to top
>
> Reply to sender
> <mailto:ronjeffries@...?Subject=%20Re%3A%20Are%20SCRUM%20a
> nd%20XP%20actually%20Process%20Oriented%3F> | Reply to group
> <mailto:scrumdevelopment@yahoogroups.com?Subject=%20Re%3A%20Ar
> e%20SCRUM%20and%20XP%20actually%20Process%20Oriented%3F> |
> Reply via web post
> <http://groups.yahoo.com/group/scrumdevelopment/post;_ylc=X3oD
MTJycGFpMXRvBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBG1z
Z0lkAzE0OTcwBHNlYwNkbXNnBHNsawNycGx5BHN0aW1lAzExNTQyNTY2ODQ-?>
act=reply&messageNum=14970>
> Messages in this topic
> <http://groups.yahoo.com/group/scrumdevelopment/message/14963;
> _ylc=X3oDMTM3dGk3N2JwBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTcwBHNlYwNkbXNnBHNsawN2dHBjBHN
> 0aW1lAzExNTQyNTY2ODQEdHBjSWQDMTQ5NjM-> (8)
>
> 2.
>
> Re: [XP] Agile 2.0
> <http://groups.yahoo.com/group/scrumdevelopment/message/14971;
> _ylc=X3oDMTJycXRnZTFpBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTcxBHNlYwNkbXNnBHNsawN2bXNnBHN
> 0aW1lAzExNTQyNTY2ODQ->
>
> Posted by: "Ron Jeffries" ronjeffries@...
> <mailto:ronjeffries@...?Subject=%20Re%3A%20%5BXP%5D%20Agil
> e%202%2E0>   RonaldEJeffries
> <http://profiles.yahoo.com/RonaldEJeffries>
>
> Sat Jul 29, 2006 5:35 pm (PST)
>
> Hello, Marco,
>
> On Saturday, July 29, 2006, at 6:45:04 AM, you wrote:
>
> > [rant]
> > Please tell me it's a joke. Scott W. Ambler has published some very
> > interesting data related to a surveys done via Dr. Dobb's Journal.
> > Questions, raw data and summary can be found at
> > http://www.ambysoft.com/surveys/ <http://www.ambysoft.com/surveys/>
>
> It's certainly not a joke, and I see the results as generally
> very favorable toward Agile, especially XP and Scrum.
>
> > In the last slide of the summary presentation (ppt) I read:
> "There was
> > a statistical correlation between adoption of "Agile 2.0"
> methods such
> > as Agile Unified Process (AUP) or MSF Agile and adoption of Agile
> > Model Driven Development (AMDD)"
>
> Well, there was apparently a correlation. About 5 percent of
> respondents reported using those, um, approaches. How many
> were used together isn't clear from what we seen in the data now.
>
> > Please please please can we try to avoid such a thing as Agile 2.0?
> > And who says that AUP and MSF Agile are Agile 2.0? what do
> we/you/they
> > mean by Agile 2.0? I still am not sure AUP and MSF Agile
> are "Agile 1.0"...
> > [/rant]
>
> Yes. Scott has been pushing his approach hard, in every
> conceivable forum. It has achieved some penetration. I would
> be very interested to see the correlation between the various
> methods and the levels of satisfaction, quality, and so on.
> Perhaps the upcoming article[s] will address that.
>
> The notion of "Agile 2.0" is, in my opinion, odious in the
> "extreme". There are a lot of people out there pushing Agile,
> there are lots of training courses, lots of consultants, lots
> of new entrants into the market, many of whom cannot trace
> their participation to anyone in the original Agile lineage.
> That troubles me a bit.
>
> I continue to see individuals and organizations saying that
> they're Agile without even getting close to what "Agile 1.0" suggests.
> Adding more modeling, and adding more process elements, will
> not improve this situation. People ought to learn to do Agile
> 1.0 before worrying much about what's next. There's plenty
> there to learn.
>
> It's all part of "crossing the chasm", I reckon. Everything
> gets watered down.
>
> Ron Jeffries
> www.XProgramming.com
> Keep away from people who try to belittle your ambitions.
> Small people always do that, but the really great make you
> feel that you, too, can become great." -- Mark Twain.
>
> Back to top
>
> Reply to sender
> <mailto:ronjeffries@...?Subject=%20Re%3A%20%5BXP%5D%20Agil
> e%202%2E0> | Reply to group
> <mailto:scrumdevelopment@yahoogroups.com?Subject=%20Re%3A%20%5
> BXP%5D%20Agile%202%2E0> | Reply via web post
> <http://groups.yahoo.com/group/scrumdevelopment/post;_ylc=X3oD
MTJyaHIzZjFqBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBG1z
Z0lkAzE0OTcxBHNlYwNkbXNnBHNsawNycGx5BHN0aW1lAzExNTQyNTY2ODQ-?>
act=reply&messageNum=14971>
> Messages in this topic
> <http://groups.yahoo.com/group/scrumdevelopment/message/14971;
> _ylc=X3oDMTM3ZGkyNHI4BF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc
> 3BJZAMxNjAyMjA5MDIxBG1zZ0lkAzE0OTcxBHNlYwNkbXNnBHNsawN2dHBjBHN
> 0aW1lAzExNTQyNTY2ODQEdHBjSWQDMTQ5NzE-> (1)
>
> Recent Activity
>
> *                        31
>
> New Members
> <http://groups.yahoo.com/group/scrumdevelopment/members;_ylc=X
3oDMTJmdXU3ZGlrBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxB
HNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzExNTQyNTY2ODQ->
>
> Visit Your Group
> <http://groups.yahoo.com/group/scrumdevelopment;_ylc=X3oDMTJld
GpkOWg3BF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBHNlYwN2d
GwEc2xrA3ZnaHAEc3RpbWUDMTE1NDI1NjY4NA-->
>
> SPONSORED LINKS
>
> *                       Scrum
> <http://groups.yahoo.com/gads;_ylc=X3oDMTJjdnZjOWR0BF9TAzk3MzU
5NzE1BF9wAzEEZ3JwSWQDMTU2OTA2NARncnBzcElkAzE2MDIyMDkwMjEEc2VjA3NsbW9kBHN0aW1
lAzExNTQyNTY2ODQ-?t=ms&k=Scrum&w1=Scrum&c=1&s=11&g=3&.sig=tPjpNbc52R3kwtb6j-
> Ad7w>
>
> New web site?
>
> Drive traffic now.
> <http://us.ard.yahoo.com/SIG=12h9a30cq/M=493064.8985663.976076
> 9.8674578/D=groups/S=1707209021:NC/Y=YAHOO/EXP=1154263884/A=38
> 48642/R=0/SIG=131eshi2t/*http:/searchmarketing.yahoo.com/arp/s
> rchv2.php?o=US2004&cmp=Yahoo&ctv=Groups3&s=Y&s2=&s3=&b=50>
>
> Get your business
>
> on Yahoo! search.
>
> Yahoo! Groups
>
> Start a group
> <http://groups.yahoo.com/start;_ylc=X3oDMTJvaXJqM2RoBF9TAzk3Mz
U5NzE1BF9wAzIEZ3JwSWQDMTU2OTA2NARncnBzcElkAzE2MDIyMDkwMjEEc2VjA25jbW9kBHNsaw
Nncm91cHMyBHN0aW1lAzExNTQyNTY2ODQ->
>
> in 3 easy steps.
>
> Connect with others.
>
> Y! Toolbar
>
> Get it Free!
> <http://us.lrd.yahoo.com/_ylc=X3oDMTJvZ2ppYmU0BF9TAzk3MzU5NzE1
BF9wAzMEZ3JwSWQDMTU2OTA2NARncnBzcElkAzE2MDIyMDkwMjEEc2VjA25jbW9kBHNsawN0b29s
YmFyBHN0aW1lAzExNTQyNTY2ODQ-;_ylg=1/SIG=11c6dvmk9/**http%>
3a/toolbar.yahoo.com/%3f.cpdl=ygrps>
>
> easy 1-click access
>
> to your groups.
>
> Need to Reply?
>
> Click one of the "Reply" links to respond to a specific
> message in the Daily Digest.
>
> Create New Topic
> <http://groups.yahoo.com/group/scrumdevelopment/post;_ylc=X3oD
MTJlbHJ2NnUwBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBHNl
YwNmdHIEc2xrA250cGMEc3RpbWUDMTE1NDI1NjY4NA--> | Visit Your Group on the Web
> <http://groups.yahoo.com/group/scrumdevelopment;_ylc=X3oDMTJjd
jhhaTNsBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBHNlYwNmd
HIEc2xrA2hwBHN0aW1lAzExNTQyNTY2ODQ->
>
> Messages
> <http://groups.yahoo.com/group/scrumdevelopment/messages;_ylc=
X3oDMTJlb21wY3MxBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIx
BHNlYwNmdHIEc2xrA21zZ3MEc3RpbWUDMTE1NDI1NjY4NA-->  | Files >
<http://groups.yahoo.com/group/scrumdevelopment/files;_ylc=X3o
DMTJmZmd0c2F2BF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBHN
lYwNmdHIEc2xrA2ZpbGVzBHN0aW1lAzExNTQyNTY2ODQ->  | Photos >
<http://groups.yahoo.com/group/scrumdevelopment/photos;_ylc=X3
oDMTJlZjZvNTdtBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBH
NlYwNmdHIEc2xrA3Bob3QEc3RpbWUDMTE1NDI1NjY4NA-->  | Links >
<http://groups.yahoo.com/group/scrumdevelopment/links;_ylc=X3o
DMTJmZjk1OHMwBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBHN
lYwNmdHIEc2xrA2xpbmtzBHN0aW1lAzExNTQyNTY2ODQ->  | Database >
<http://groups.yahoo.com/group/scrumdevelopment/database;_ylc=
X3oDMTJjMGtodnE5BF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIx
BHNlYwNmdHIEc2xrA2RiBHN0aW1lAzExNTQyNTY2ODQ->  | Polls >
<http://groups.yahoo.com/group/scrumdevelopment/polls;_ylc=X3o
DMTJmcm4xa3FmBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBHN
lYwNmdHIEc2xrA3BvbGxzBHN0aW1lAzExNTQyNTY2ODQ->  | Members >
<http://groups.yahoo.com/group/scrumdevelopment/members;_ylc=X
3oDMTJlNm0xdWRvBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxB
HNlYwNmdHIEc2xrA21icnMEc3RpbWUDMTE1NDI1NjY4NA-->  | Calendar >
<http://groups.yahoo.com/group/scrumdevelopment/calendar;_ylc=
X3oDMTJkc21vc2xiBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIx
BHNlYwNmdHIEc2xrA2NhbARzdGltZQMxMTU0MjU2Njg0>
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@eGroups.com
>
> Yahoo! Groups
> <http://groups.yahoo.com/;_ylc=X3oDMTJkMTBqaHRkBF9TAzk3MzU5NzE
> 1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBHNlYwNmdHIEc2xrA
> 2dmcARzdGltZQMxMTU0MjU2Njg0>
> You are receiving a Daily Digest Change Delivery Settings
> <http://groups.yahoo.com/group/scrumdevelopment/join;_ylc=X3oD
MTJmc3NrcGkwBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBHNl
YwNmdHIEc2xrA3N0bmdzBHN0aW1lAzExNTQyNTY2ODQ->
> Visit Your Group
> <http://groups.yahoo.com/group/scrumdevelopment;_ylc=X3oDMTJkZ
WU0ZXByBF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBHNlYwNmd
HIEc2xrA2hwZgRzdGltZQMxMTU0MjU2Njg0> | Yahoo! Groups Terms of Use >
<http://docs.yahoo.com/info/terms/> | Unsubscribe
> <mailto:scrumdevelopment-unsubscribe@yahoogroups.com?subject=U
> nsubscribe>
>
>
> <http://geo.yahoo.com/serv?s=97359715&grpId=1569064&grpspId=16
> 02209021&msgId=1533&stime=1154256684&nc1=3848642&nc2=2&nc3=3>
>
>
> _____________________________________________________________________
> This e-mail has been scanned for viruses by MessageLabs. The
> information contained in this message is confidential and is
> intended for the addressee only. If you have received this
> message in error, please notify Conchango plc as soon as
> possible. The unauthorised use, disclosure, copying or
> alteration of this message is prohibited and may be unlawful.
> The internet cannot guarantee the integrity of this message
> and therefore Conchango plc will not be liable for the
> message if modified.
>
> Reg. Heritage House, Church Road, Egham, Surrey, TW20 9QD T
> 44 (0) 1784 222 222 F 44 (0) 1784 222 200 E
> talktous@... No. 2598884
>
>
>
>

--- In scrumdevelopment@yahoogroups.com, "M. le Rutte" <mkg6@...>
wrote:

>
> The point about documentation is that is should be 'barily
enough'.

Yes.  A detailed discussion of that can be found at
http://www.agilemodeling.com/essays/barelyGoodEnough.html

<snip>
>
> Posibilities to eliminate this waste is either generating the
documentation
> from your sourcecode (e.g. JavaDoc)

The general idea is to single source information
(http://www.agilemodeling.com/essays/singleSourceInformation.htm),
to record a concept once in the most appropriate place possible and
then generate the needed views (e.g. run JavaDoc).  Often the best
place is source code, but not always.


> or use a coarse granularity of
> documentation. An example is 'user stories' instead of RUP
style 'Use
> Cases'. (And yes, I have intensively worked with the 10-page use
cases of
> RUP...)

I'm not sure where in RUP it says to generate 10 page use cases.
I've seen use cases written in point form on index cards, and
actually remember writing a bit about the differences in use case
writing styles.  See
http://www.agilemodeling.com/artifacts/systemUseCase.htm and
http://www.agilemodeling.com/artifacts/essentialUseCase.htm for
examples and discussion.


>
> Support:
> Again, I do not see why agile could be bad for support.

It's not.  A lot of people look for excuses not to go agile (we're
working on something complex, we're in a regulated environment,
we're dispersed, ...).  My October column in DDJ addresses the most
common excuses, although I missed the support issue, and discusses
why they're nothing more than excuses.

- Scott

Ken, I was wondering if you had a chance to consider the questions I
posed below.  It seems fair to me that you should at least indicate
whether or not you had even read it before attacking it.

Thanks in advance.

- Scott

--- In scrumdevelopment@yahoogroups.com, "Scott Ambler" <swa@...>
wrote:
>
> --- In scrumdevelopment@yahoogroups.com, "Ken Schwaber" wrote:
>
> <snip>
> > "Look at me, this is a great Agile
> > approach. Pay me." etc. has nothing to do with improving the
software
> > development profession, it has to do with making money, market
> position,
> > etc. EUP, AUP, etc. are such. They just don't get that Agile
isn't
> > prescriptive, and every step toward commercialization,
> specialization is a step toward prescription.
>
> Ken, thank you for attacking my work publicly without bothering to
> copy me on it.  Be that as it may, I have a few questions for you.
>
> First, regarding the AUP:
> 1. Have you even looked at it?  It can be downloaded free of
charge at
> http://www.ambysoft.com/unifiedprocess/agileUP.html if you haven't
yet
> done so.
> 2. If you have, could you please explain to me the
commercialization
> aspects surrounding the AUP.  It is available free of charge and
> always has been.
> 3. If you have, could you please explain to me its prescriptive
> nature?  As you can see, the disciplines (e.g. Model, Implement)
are
> described as a collection of tips (e.g. model just in time) and
> suggested issues that you should consider addressing throughout
the
> various project phases.  Granted, I suppose you could consider the
> fact that I insist on a minimum of 8 deliverables (radical things
such
> as the system itself, tests, source code, and minimal supporting
> documenation) to be prescriptive, but is that really so bad?
>
> Second, regarding the EUP:
> 1. Have you ever read the book?  An overview of it is available at
> http://www.ambysoft.com/books/enterpriseUnifiedProcess.html
> 2. Could you please point me to where I claimed that the EUP is an
> agile process?  In fact, I seem to remember clearly stating that
it's
> typically instantiated as a prescriptive process, although perhaps
I'm
> confused on this issue.  Granted, in the EUP book we did try to
steer
> people towards being as agile as possible, but at the enterprise
level
> that can be difficult at times.
> 3. Could you please point me towards writings about enterprise
issues
> soch as enterprise architecture, reuse, portfolio management, and
so
> on where they've managed to go into more depth regarding how to
make
> these things even more agile?
> 4. Once again, I'm a bit confused about the commercialization
issue.
> At www.enterpriseunifiedprocess.com I've gone out of my way to
provide
> free information about the EUP.  Granted, I am trying to motivate
> people to buy the book which provides far more details.
>
> Thanks in advance for answering these questions.  I'm a little
> confused as to why you'd make such sweeping statements about the
AUP
> and EUP without backing them up.
>
> - Scott
>

Hello aefager,

Thanks for your email. On Tuesday, August 1, 2006, at 11:17:07 AM,
you wrote:

> --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
> <ronjeffries@...> wrote:
>>
>> Well, that's one way. As one of the original proponents of story
>> points, I'm more inclined to use them throughout if at all, since if
>> they don't match up pretty well, then the points become less useful.
>> (snip)
>> I don't find hours to be particularly useful in iteration/sprint
>> planning, by the way, because they are so rarely accurate enough. I
>> much prefer for the team to eyeball the list and make a commitment,
>> rather than relying on the numbers. This is after a long period of
>> doing it the other way, as I was taught.
>>
> I just want to get a clarification here.
> 1. You are a proponent of accurate estimation.

The more accurate the estimates, the better things go. I would not
consciously make the estimates more variable than they already are.

> 2. You are a proponent of Scrum.

I think Scrum has some good points. I've been spending the last
couple of years helping teams that are nominally doing Scrum
actually develop /software/ while doing Scrum.

> 3. You are a proponent of story points over hours.

I have been. I observe that if stories are sufficiently close to the
same duration, story count works just about as well as either points
or hours.

> Does this mean that in a burndown chart, you would use story points,
> in place of hours?  Do you still have burndowns, and are now doing
> them on story points, or did I misunderstand?

I think Sprint burndowns are harmful. I think that project burndowns
should be done in stories (not points or hours), or better yet,
story /value/.

> Clinton Keith had some comments on this in this article.  I know he
> posts here, so I won't speak for him, but even here, he still asks
> for the team to estimate the hours, I believe.

> http://www.agilegamedevelopment.com/2006/03/hours-vs-story-points.html

Yes. There are reasons why hours are useful. For example, Beck likes
to make commitments based on elapsed hours, if I understand his
position.

What matters, in my opinion, is the ability to predict how much will
be done by any given date, and to use that information to adjust
what the team does, primarily by adjusting scope.

Estimating in hours is, in my experience, false precision. Points
are more obviously false, and less precise if you keep them in a
narrow range, and I like that.

> At least in the Scrum implementation I was on, the story points were
> done in advance by the product owner.

That seems to me to be

   (a) ridiculous, because the product owner can't possibly know
       how long it will take the team to do things;
   (b) counter to what Scrum teaches, if I understand it.

> The team would then give the
> hours they felt it would take them, based on their knowledge of
> themselves.  If the burndown is only based upon the PO points, the
> Scrum team would lose some of their ability to feel commitment to the
> Sprint goals, in my opinion.

Yes, but the bug in this equation was that the team didn't create
the points, not that points were used.

> I felt as a member of the team that seeing the burndown slope, and
> seeing my impact on the final result, was valuable, even if my hours
> estimate was off.  If I was working on abstract points, I would feel
> less confident at giving what my remaining points were, compared to
> my remaining hours.  Perhaps I could adjust (life is adjustments),
> but the estimation of effort in man-hours is fairly well engrained
> from mowing the lawn, painting a fence, or testing a web page.

I'm all for hours if you want to use them. I personally estimate in
either "perfect time", which I also call "bar time", the amount of
time I would estimate in a bar if after a few beers someone asked me
how long I'd need to do something; or in "sessions", which is the
amount of work Chet and I can get done at Panera before lunch.

Points are useful, primarily, for two reasons:

   1. They are less controversial to some teams, who are concerned
     that if they say something will take 8 hours, they'll be
     expected to have it done by this time tomorrow. I've seen that
     expectation be there, so this concern is at least sometimes
     valid.

   2. Points are likely to be more accurate than hours when looking
      at the big picture, in my experience, and they are more than
      sufficiently accurate for planning purposes.

As I hope you can see, my position is not well described by yes/no
answers to your three questions. ;->

Ron Jeffries
www.XProgramming.com
In programming, do, or undo. There is always try.  --Yoda

Hi Prakash,
You can get the details from
http://www.controlchaos.com/certification/

Regards,
Baiju

--- In scrumdevelopment@yahoogroups.com, "Charles Prakash Dasari"
<cdasari@...> wrote:
>
> Hi All,
>
> Is there some place where all the upcoming CSM trainings are posted?
I need
> to send 4 of my guys for the CSM training and am looking for the closest
> opportunity.
>
> Regards,
> Prakash
>

Hello Scott,

Thanks for your email. On Tuesday, August 1, 2006, at 1:04:19 PM,
you wrote:

> Ken, I was wondering if you had a chance to consider the questions I
> posed below.  It seems fair to me that you should at least indicate
> whether or not you had even read it before attacking it.

Until you squealed, Scott, I didn't even know that Ken's remarks
were "attacking" you or your words. He seemed to me to be talking in
terms of his general beliefs, though he did list a TLA or two that
you associate yourself with ...

Ron Jeffries
www.XProgramming.com
You do ill if you praise, but worse if you censure,
what you do not understand.   --Leonardo da Vinci

Hello Ken,

Thanks for your email. On Tuesday, August 1, 2006, at 8:18:22 AM,
you wrote:

> I've talked to God about this and he/she refuses to make me the sole source
> of knowledge regarding Scrum, if you can imagine that. Direct communication
> with the disciple is still used.

GLENDOWER
I can call spirits from the vasty deep.

HOTSPUR
Why, so can I, or so can any man;
But will they come when you do call for them?

> I don't think there is a next thing. Until we undo the mess of both
> waterfall and command and control, nothing will work.

Yes. In my opinion, we are, at the same time, doing pretty well at
this, and doing terribly poorly.

> Deborah Hartman attended a talk I gave on Agile quality. ... The responses
> immediately were of the following type:

>> Yes, because (gosh-darn-it) we're important, and the universe
>> (not to mention the executive management of our company) revolves
>> around the state of our current software project, and the
>> executive management of our company should just be sitting
>> waiting to revise the financial statements of the company just to
>> show what idiots they are for making us sacrifice the quality of
>> our masterpiece."

> And, more like it. We are so unprofessional it is incredible. The legacy of
> waterfall is so dominant it is scary.

Yes ... the above is perfect evidence that our message is not
getting across as well as we would like it to. That suggests to me
that we are doing something wroxxx not as well as we might.

Ron Jeffries
www.XProgramming.com
Steering is more important than speed,
in driving and in software development.

--- In scrumdevelopment@yahoogroups.com, Ron Jeffries
<ronjeffries@...> wrote:

>
> Until you squealed, Scott, I didn't even know that Ken's remarks
> were "attacking" you or your words. He seemed to me to be talking
in
> terms of his general beliefs, though he did list a TLA or two that
> you associate yourself with ...

From my point of view he was pretty clear that he thought that AUP
and EUP were prescriptive.  He at least implied it.  That might be
true of EUP but it isn't of AUP.  Although to be fair, I don't
remember claiming that EUP was an agile process so why is it being
criticized for not being agile?

He also indicated that the people behind those methods don't seem to
get it.  I'm among the people behind those methods, and arguably the
primary person behind them, so yes, I may have jumped to the
conclusion that I'm being attacked.

- Scott

Hello Scott,

Thanks for your email. On Tuesday, August 1, 2006, at 1:58:28 PM,
you wrote:

> From my point of view he was pretty clear that he thought that AUP
> and EUP were prescriptive.  He at least implied it.  That might be
> true of EUP but it isn't of AUP.  Although to be fair, I don't
> remember claiming that EUP was an agile process so why is it being
> criticized for not being agile?

The EUP literature declares RUP "insufficient", suggesting that EUP
is "more" than RUP. RUP may or may not be intended to be
prescriptive, but it bloody well /is/ prescriptive on the ground.

EUP is also trademarked, which IMO is worthy of question if not
criticism.

As for AUP, the home page says that if you are looking for something
"between" XP and RUP, then AUP is "likely" for you. XP is in fact an
instance of RUP, which makes me wonder just what "between" might
mean, and why, of all the things we can imagine between XP and
full-on RUP with all bells and whistles, AUP is the likely
candidate.

The so-called "disciplines" of AUP are defined by huge and complex
diagrams showing roles I've never heard of before, and a plethora of
little arrowed boxes representing activities. The text does say that
you don't need to do everything in the list, but seems to give
little guidance as to when and when not. To be safe ... should I
create a thing, or not create it? Too many people conclude that they
should, if RUP is any example.

Why, by the way, AUP at all? RUP is perfectly adequate to describe
essentially any iterative process. Surely AUP is an instance of RUP,
but it seems that AUP is presented as an /alternative/ to RUP, not
as a way of doing RUP.

Randomly ...

The workflow for "Implementation" appears to be phasist, and
requires six documents that are not conventionally "official" Agile
docs: (requirements model, design model, usability guidance,
enterprise development guidance, proof of concept prototype, and
defect report). It creates a new role, "Agile DBA".

The workflow for "Testing" also seems manifestly phasist to me. It
again shows more than one model in its picture, thus in effect
requiring those models to "exist". This blesses modeling -- which is
consistent with your position ab initio -- and while there is lip
service to doing only what's necessary, on the ground that seems to
turn into "a lot", not "a little". This page creates yet another
role "Test Manager" that I've never heard of before.

Having a separate workflow for development and testing isn't
obviously in line with Agile principles, by the way.

I could go on ...

> He also indicated that the people behind those methods don't seem to
> get it.  I'm among the people behind those methods, and arguably the
> primary person behind them, so yes, I may have jumped to the
> conclusion that I'm being attacked.

As I read that document, it does not cry out as Agile. It cries out
to me as a heavily-documented flowcharted process creating roles
that are likely to be identified as individuals. It shows managers
driving everything.

The Inception phase (I thought that Agile != phased, by the way)
does not include software as its exit criterion.

Neither does Elaboration.

In the Construction phase, the software is built and tested. Until
now, I thought that starting with analysis, proceeding to design,
then building the software was called "waterfall", not "Agile".

In the Transition phase, we schedule rework. I thought that rework
was a part of every part of Agile, not just some final "phase".

Well, this is just off the cuff. But it doesn't read like "Agile" to
me. I can see how I could perhaps fake this process while doing
Agile, but I'd have to be faking a lot of people and a lot of
documents, and I'd have to be coding in at least two "phases" where
it's apparently against the rules.

How say you?

Ron Jeffries
www.XProgramming.com
Reason is and ought only to be the slave of the passions.  -- David Hume

--- In scrumdevelopment@yahoogroups.com, Ron Jeffries
<ronjeffries@...> wrote:
>
>
> The EUP literature declares RUP "insufficient", suggesting that EUP
> is "more" than RUP. RUP may or may not be intended to be
> prescriptive, but it bloody well /is/ prescriptive on the ground.

Yes, most organizations instantiate RUP to be very prescriptive,
even though they're strongly advised not to do this.  Some, however,
do not choose to go this route but they're clearly in the minority.

>
> EUP is also trademarked, which IMO is worthy of question if not
> criticism.

Yes, we initiated that effort a few years ago after discovering that
a rather large (ok, exceptionally large) organization had started to
use the term without any sort of reference to our work.  This is the
first and only time I have ever trademarked or patented anything,
and as you know I'm in a position where I could have easily done so
many times.  It was purely defensive for EUP.

To be anal, "Enterprise Unified Process" is trademarked by me, not
EUP (that trademark is held by someone else in a completely
different context).

>
> As for AUP, the home page says that if you are looking for
something
> "between" XP and RUP, then AUP is "likely" for you. XP is in fact
an
> instance of RUP,

Hmmm....  then perhaps I'm over underestimating the number of
organizations that have instantiated RUP in an agile manner.

> which makes me wonder just what "between" might
> mean, and why, of all the things we can imagine between XP and
> full-on RUP with all bells and whistles, AUP is the likely
> candidate.

Between would probably means something along the lines of more than
XP, less than RUP out of the box (OTB).

>
> The so-called "disciplines" of AUP are defined by huge and complex
> diagrams showing roles I've never heard of before, and a plethora
of
> little arrowed boxes representing activities. The text does say
that
> you don't need to do everything in the list, but seems to give
> little guidance as to when and when not. To be safe ... should I
> create a thing, or not create it? Too many people conclude that
they
> should, if RUP is any example.

One of the philosophies of the AUP, which is described in the HTML
pages, is that the people following it are competent.  That means
that they have the ability to know when and when not to do
something, or more importantly how much/little to do.  The diagrams
are meant to provide a reminder to consider the issues, whether or
not you need to actually do those activities or produce those
artifacts depends on your situation and the choices that you make.


>
> Why, by the way, AUP at all? RUP is perfectly adequate to describe
> essentially any iterative process. Surely AUP is an instance of
RUP,
> but it seems that AUP is presented as an /alternative/ to RUP, not
> as a way of doing RUP.

It's an alternative to the RUP product.  You might choose to have
both I suppose, it's up to you.

>
> Randomly ...
>
> The workflow for "Implementation" appears to be phasist, and
> requires six documents that are not conventionally "official" Agile
> docs: (requirements model, design model, usability guidance,
> enterprise development guidance, proof of concept prototype, and
> defect report).

Actually, in that list only two are required (see the artifacts
list), the rest are optional.  Nowhere on the diagram does it
indicate what is required or not.

Furthermore, how comprehensive theose artifacts are is up to you.
The requirements model could be a stack of index cards and the
design model some whiteboard sketches or CRC cards.


> It creates a new role, "Agile DBA".

Yes.  I have a few ideas about that role at www.agiledata.org, one
of my many commercial endeavors where I give things away for free.

>
> The workflow for "Testing" also seems manifestly phasist to me.

If you choose to view it that way then that's your decision.  Of
course, for it to actually be phasist you'd have to ignore the
advice to organize the project into iterations.  That's up to you of
course, but if you're making that decision then it sounds to me like
you're no longer doing AUP.

> It
> again shows more than one model in its picture, thus in effect
> requiring those models to "exist".

Don't other methods require other artifacts, such as user stories or
acceptance tests.  Aren't they some form of model which also exist?
Is the fact that I've communicated aspects the method with diagrams
automatically make it prescriptive?

> This blesses modeling -- which is
> consistent with your position ab initio -- and while there is lip

Yes.  I'm very clear about the fact that agilists model.  We draw
sketches, we create index cards with text on them, we write
acceptance tests, and a whole bunch of other stuff.

> service to doing only what's necessary, on the ground that seems to
> turn into "a lot", not "a little".

That's a choice that some people make.  Seems to me that many XP
teams choose to do a little modeling, whereas UP teams choose to do
more modeling.  For years I've written about and tried to explain
the need for UP teams to do a lot less modeling and documentation.
Some people choose to listen, some people choose not to.

> This page creates yet another
> role "Test Manager" that I've never heard of before.

Yes.  That's part of the AUP method.  Also part of RUP but not XP.
Apparently there are differences between methods.

>
> Having a separate workflow for development and testing isn't
> obviously in line with Agile principles, by the way.

Interestingly, testing activities are also part of the
Implementation discipline.  If you read top-down, left to right,
then writing tests is the very first task of Implementation in the
AUP.

>
> I could go on ...
>
> > He also indicated that the people behind those methods don't
seem to
> > get it.  I'm among the people behind those methods, and arguably
the
> > primary person behind them, so yes, I may have jumped to the
> > conclusion that I'm being attacked.
>
> As I read that document, it does not cry out as Agile. It cries out
> to me as a heavily-documented flowcharted process creating roles
> that are likely to be identified as individuals. It shows managers
> driving everything.

Really?  Look again.  In the Model discipline Project Manager is
shown once as a secondary role.  In Implementation, the bulk of the
effort, no managers appear at all.  In Test the Test Manager
performs some tasks, but Testers and Stakeholders do the majority of
the work.


>
> The Inception phase (I thought that Agile != phased, by the way)
> does not include software as its exit criterion.

Really?  Then what's all the talk about "Iteration/Cycle 0" or "End
Game" iterations that I've heard about?  Iteration 0 sure sounds
like some form of "get the ball going" phase and "End Game" sure
sounds like some sort of "clean it up and deploy it" phase.

>
> Neither does Elaboration.

We're actually talking about combining the two because they seem to
run so quickly in practice that it's hard to discern the two.

>
> In the Construction phase, the software is built and tested. Until
> now, I thought that starting with analysis, proceeding to design,
> then building the software was called "waterfall", not "Agile".

Those are waterfall things, but that's not what the AUP promotes.

>
> In the Transition phase, we schedule rework. I thought that rework
> was a part of every part of Agile, not just some final "phase".

Never said that it wasn't.

>
> Well, this is just off the cuff. But it doesn't read like "Agile"
to
> me. I can see how I could perhaps fake this process while doing
> Agile, but I'd have to be faking a lot of people and a lot of
> documents, and I'd have to be coding in at least two "phases" where
> it's apparently against the rules.
>
> How say you?

Seems to me that you've taken a very biased read of it.

- Scott

Hello all,

I have posted this message in XP and APM group. Somebody recommended
me to seek help here. Sorry if the duplicated message bother you.

I am a student majoring in software engineering, tring to write a
survey about multi-project management.
There is usually multi-project environment in companies and multi-
project management (or portfolio and programme management) has been
studied in project management community. However, there seem little
papers about this topic in agile community.
I like agile method and hope to collect as much information in this
area as possible, including both regular papers and practitioner
experiences. Would you mind giving me some advices, recommending
some readings, or sharing your experiences?

I have searched the archive and still feel it's better to open a new
topic to seek deep understanding.
"Heavyweight" scheduling resources across multi-project requires
collecting clear information and predicting when to use which
resources. Do you think it's appropriate in agile environment? Do
you prefer to leave the final details to self-organized team? But
doesn't the self-organized team need some method to solve this
problem? I saw somebody mention they practice swapping pairs across
multi-project and this facilitate knowledge sharing and code reuse.
What do you think of it? What's your method if you indeed re-
allocate resource among multi-project? According to what to make
decision? And how to deal with the high uncertainty? How to
calculate the velocity when there is no obvious boundary between
projects or teams? I saw somebody prioritized stories(or other unit)
from different projects in one backlog. What do you think of it?
What's your criterion to prioritize or determine when and whether to
switch to another project and who does which piece of work, if you
have experienced such practices? ......
It is said that agile contribution to project portfolio management
is only: each delivery offers an opportunity to order the priorities
within each project, rebalance their allocation of resources to
projects and so on. Do you think there are other unique agile
perspectives about multi-project?

Please don't hesitate to tell your thoughts. Just some keywords are
also OK. Thank you very much.

Best Regards,
Dong Fei

> Hi Folks,
>
> Please excuse the SPAM - due to circumstances beyond our control we had to
change the meeting location AGAIN.
> I apologize for any inconvenience this may cause you.
>
Is that the virtual one that does not know Ken Schwaber or the real one? :)

--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

Hello Scott,

Thanks for your email. On Tuesday, August 1, 2006, at 3:08:46 PM,
you wrote:

> --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
> <ronjeffries@...> wrote:
>>
>>
>> The EUP literature declares RUP "insufficient", suggesting that EUP
>> is "more" than RUP. RUP may or may not be intended to be
>> prescriptive, but it bloody well /is/ prescriptive on the ground.

> Yes, most organizations instantiate RUP to be very prescriptive,
> even though they're strongly advised not to do this.  Some, however,
> do not choose to go this route but they're clearly in the minority.

Yes. I expect that since EUP is //more// than RUP, since RUP is
"insufficient", this trend will only be accelerated, which seems to
me to be exactly in the opposite direction to Agile.
>>
>> As for AUP, the home page says that if you are looking for
> something
>> "between" XP and RUP, then AUP is "likely" for you. XP is in fact
> an
>> instance of RUP,

> Hmmm....  then perhaps I'm over underestimating the number of
> organizations that have instantiated RUP in an agile manner.

You avoid my point. There is no "between" between XP and RUP. RUP is
a framework which describes many actual process instances, including
XP-style instances.

I note in review of our work here that AUP is described both as
"between XP and RUP", and as being a reaction to the notion that RUP
is "insufficient".

>> which makes me wonder just what "between" might
>> mean, and why, of all the things we can imagine between XP and
>> full-on RUP with all bells and whistles, AUP is the likely
>> candidate.

> Between would probably means something along the lines of more than
> XP, less than RUP out of the box (OTB).

RUP is a framework. It doesn't have an "out of the box". It is
required to be customized in every instance.

>> The so-called "disciplines" of AUP are defined by huge and complex
>> diagrams showing roles I've never heard of before, and a plethora
> of
>> little arrowed boxes representing activities. The text does say
> that
>> you don't need to do everything in the list, but seems to give
>> little guidance as to when and when not. To be safe ... should I
>> create a thing, or not create it? Too many people conclude that
> they
>> should, if RUP is any example.

> One of the philosophies of the AUP, which is described in the HTML
> pages, is that the people following it are competent.  That means
> that they have the ability to know when and when not to do
> something, or more importantly how much/little to do.  The diagrams
> are meant to provide a reminder to consider the issues, whether or
> not you need to actually do those activities or produce those
> artifacts depends on your situation and the choices that you make.

So, these competent people who know when and when not to do things,
and how much ... why do they need all this instruction, then?

And why does the instruction offer so little in terms of judging how
little or how much, but so much in terms of what?

>> Why, by the way, AUP at all? RUP is perfectly adequate to describe
>> essentially any iterative process. Surely AUP is an instance of
> RUP,
>> but it seems that AUP is presented as an /alternative/ to RUP, not
>> as a way of doing RUP.

> It's an alternative to the RUP product.  You might choose to have
> both I suppose, it's up to you.

I can see why someone would want to create a product to compete with
RUP. The product in question, as named, is "Agile", and it is
positioned between XP and a framework, and declares RUP
"insufficient", all at the same time. RUP is, if anything,
super-sufficient to anyone with an Agile bent. More than RUP would
be, well, more, wouldn't it?

>> Randomly ...
>>
>> The workflow for "Implementation" appears to be phasist, and
>> requires six documents that are not conventionally "official" Agile
>> docs: (requirements model, design model, usability guidance,
>> enterprise development guidance, proof of concept prototype, and
>> defect report).

> Actually, in that list only two are required (see the artifacts
> list), the rest are optional.  Nowhere on the diagram does it
> indicate what is required or not.

My point exactly. If everything is optional, then we don't need the
process. If some things are optional, we need to know which ones. If
some things are optional (or scalable) under certain circumstances,
we need to know which ones and when.

> Furthermore, how comprehensive theose artifacts are is up to you.
> The requirements model could be a stack of index cards and the
> design model some whiteboard sketches or CRC cards.

I know that. You know that. Your readers, by and large, at least the
ones I meet, do not know that. I am concerned that the AUP will
perpetuate the misunderstanding that is common in looking at "Agile
Modeling".

>> It creates a new role, "Agile DBA".

> Yes.  I have a few ideas about that role at www.agiledata.org, one
> of my many commercial endeavors where I give things away for free.

Unpaid political advert noted. Adding roles may be necessary, but
surely not every project needs the role. Many projects (I'd say
most) seem to interpret the existence of a role as justification for
existence of a person. That person now has a reason for being, and a
reason for being in the loop. That situation is commonly (I'd say
mostly) done at the expense of true agility.

A good Agile DBA would be in the loop, making decisions every few
minutes. Someone ought to write that down.
>>
>> The workflow for "Testing" also seems manifestly phasist to me.

> If you choose to view it that way then that's your decision.  Of
> course, for it to actually be phasist you'd have to ignore the
> advice to organize the project into iterations.  That's up to you of
> course, but if you're making that decision then it sounds to me like
> you're no longer doing AUP.

No, I wouldn't have to ignore that. It wouldn't even be necessary
not to notice it. The outline clearly shows testing separate from
implementation. The pictures do so as well. They do not look like a
free flow, from moment to moment, between testing to implementation
to testing, they look like phases, whether within iterations or not.

I might also note that much current thinking (predating Agile 2.0,
of course) is that testing comes /first/ in Agile, not second.

>> It
>> again shows more than one model in its picture, thus in effect
>> requiring those models to "exist".

> Don't other methods require other artifacts, such as user stories or
> acceptance tests.  Aren't they some form of model which also exist?
> Is the fact that I've communicated aspects the method with diagrams
> automatically make it prescriptive?

No, but the diagrams are segmented in what can appear to be time,
and they run mostly from left to right, which suggests to this
reader a flow of time. They do not look cyclical or free-flowing:
they look rectangular, structured, ordered.

Your intentions may be to be just as Agile as the most extreme among
us. I'm reporting what the presentation says to me as a reader.

>> This blesses modeling -- which is
>> consistent with your position ab initio -- and while there is lip

> Yes.  I'm very clear about the fact that agilists model.  We draw
> sketches, we create index cards with text on them, we write
> acceptance tests, and a whole bunch of other stuff.

Yes, we do those things. I am clear about what exists. You appear to
be clear about what /should/ exist, and in following your words,
people appear to think about lots of models that are much heavier
than index cards, and much less executable than tests.

You have spoken about modeling on a bar napkin or paper bag: I've
heard you do it. The listeners don't seem to get it. I suspect that
is in part due to the presentation.

>> service to doing only what's necessary, on the ground that seems to
>> turn into "a lot", not "a little".

> That's a choice that some people make.  Seems to me that many XP
> teams choose to do a little modeling, whereas UP teams choose to do
> more modeling.  For years I've written about and tried to explain
> the need for UP teams to do a lot less modeling and documentation.
> Some people choose to listen, some people choose not to.

I have heard you say that. I have also encountered an entire bloody
book on Agile Modeling. That's not "less" by most standards I'm
aware of. Again ... it's just not coming across in a minimalist
fashion, as I read the market.

>> This page creates yet another
>> role "Test Manager" that I've never heard of before.

> Yes.  That's part of the AUP method.  Also part of RUP but not XP.
> Apparently there are differences between methods.

Yes. It might be that minimalism is part of Agile. Proliferating
roles, especially ones that seem to me to be clearly optional, runs
counter to what I consider to be the Agile vibe.

>> Having a separate workflow for development and testing isn't
>> obviously in line with Agile principles, by the way.

> Interestingly, testing activities are also part of the
> Implementation discipline.  If you read top-down, left to right,
> then writing tests is the very first task of Implementation in the
> AUP.

Yes. But look at the exit criteria. There is no code in the exit
criteria, as I read them.

>>
>> I could go on ...
>>
>> > He also indicated that the people behind those methods don't
> seem to
>> > get it.  I'm among the people behind those methods, and arguably
> the
>> > primary person behind them, so yes, I may have jumped to the
>> > conclusion that I'm being attacked.
>>
>> As I read that document, it does not cry out as Agile. It cries out
>> to me as a heavily-documented flowcharted process creating roles
>> that are likely to be identified as individuals. It shows managers
>> driving everything.

> Really?  Look again.  In the Model discipline Project Manager is
> shown once as a secondary role.  In Implementation, the bulk of the
> effort, no managers appear at all.  In Test the Test Manager
> performs some tasks, but Testers and Stakeholders do the majority of
> the work.

How many times does a would-be manager have to look to see his job
justified? How many times does a reader have to read to get what
we're giving out.

If we're lucky, people will read our words once. Their impression
will be filtered by what they already believe in. I believe in
Agile, rather strongly, and my impression still is that the document
reads less like Agile than it might.
>>
>> The Inception phase (I thought that Agile != phased, by the way)
>> does not include software as its exit criterion.

> Really?  Then what's all the talk about "Iteration/Cycle 0" or "End
> Game" iterations that I've heard about?  Iteration 0 sure sounds
> like some form of "get the ball going" phase and "End Game" sure
> sounds like some sort of "clean it up and deploy it" phase.

Yes. Both of those are often aberrations, in my opinion. Even more
so is the infamous alternation between a dev iteration and a qa
iteration, or an offset of one between dev and qa.

In any case, does a poor expression in someone else's work justify
what's in mine? I'd think not. Are those phases tiny compared to the
inner ones? They don't look tiny in the pictures. Should they?

>> Neither does Elaboration.

> We're actually talking about combining the two because they seem to
> run so quickly in practice that it's hard to discern the two.

Are these two phases iterated? In the pictures it appears that only
construction is iterated. And what about frequent releases ... are
there loops you'd recommend strongly that are not shown as clearly
as they might be in the pictures?

>> In the Construction phase, the software is built and tested. Until
>> now, I thought that starting with analysis, proceeding to design,
>> then building the software was called "waterfall", not "Agile".

> Those are waterfall things, but that's not what the AUP promotes.

That's what the pictures said to me.

>>
>> In the Transition phase, we schedule rework. I thought that rework
>> was a part of every part of Agile, not just some final "phase".

> Never said that it wasn't.

You list it in only one place. That might suggest that that's where
it should be, mightn't it?

>>
>> Well, this is just off the cuff. But it doesn't read like "Agile"
> to
>> me. I can see how I could perhaps fake this process while doing
>> Agile, but I'd have to be faking a lot of people and a lot of
>> documents, and I'd have to be coding in at least two "phases" where
>> it's apparently against the rules.
>>
>> How say you?

> Seems to me that you've taken a very biased read of it.

Well, cool, blame the reader. I can handle that. I'd suggest that
there might be a better way to respond to feedback. I just hope it
doesn't involve Karate. ;->

Ron Jeffries
www.XProgramming.com
You are to act in the light of experience as guided by intelligence.
-- Nero Wolfe

--- In scrumdevelopment@yahoogroups.com, Ron Jeffries
<ronjeffries@...> wrote:
> > Does this mean that in a burndown chart, you would use story
points,
> > in place of hours?  Do you still have burndowns, and are now
doing
> > them on story points, or did I misunderstand?
> I think Sprint burndowns are harmful. I think that project burndowns
> should be done in stories (not points or hours), or better yet,
> story /value/.
So, for each user story, before getting into a sprint, there would be
a metric for value as well as for points.  Would it be a number (like
10 to 1 for high value to low value), or would it be an ordinal
hierarchy (most value to least value in the backlog).  Realize that
unlike some others here, I am more at the "still learning" phase, so
these are questions coming from at least partial ignorance.  I just
do not recall a value setting in the user stories.

> Estimating in hours is, in my experience, false precision. Points
> are more obviously false, and less precise if you keep them in a
> narrow range, and I like that.
Can you give an example where less precision on the estimates is a
good thing?  Here in Miami, the estimate of how long it will take to
fix my roof after a hurricane, or the estimate of how much it will
cost, is better for me if it is MORE precise, not less.

> > At least in the Scrum implementation I was on, the story points
were
> > done in advance by the product owner.
> That seems to me to be
>   (a) ridiculous, because the product owner can't possibly know
>       how long it will take the team to do things;
>   (b) counter to what Scrum teaches, if I understand it.
Quite possible.  Although we had a very good teacher of Scrum, we
have already discussed some of the dyfunctional parts of the Scrum I
was in.  I credit the teacher for continuing to keep me interested in
the method even after things went wrong.  So, in the general case,
the story points are also set up by the team, not given in the
backlog by the PO.  In that case, I would have less concern about
using the story points as my progression, since it would still be a
true measure of the team commitment.

> > The team would then give the
> > hours they felt it would take them, based on their knowledge of
> > themselves.  If the burndown is only based upon the PO points,
the
> > Scrum team would lose some of their ability to feel commitment to
the
> > Sprint goals, in my opinion.
> Yes, but the bug in this equation was that the team didn't create
> the points, not that points were used.
Agreed.  Thanks for the clarification.

> > I felt as a member of the team that seeing the burndown slope,
and
> > seeing my impact on the final result, was valuable, even if my
hours
> > estimate was off.  If I was working on abstract points, I would
feel
> > less confident at giving what my remaining points were, compared
to
> > my remaining hours.  Perhaps I could adjust (life is
adjustments),
> > but the estimation of effort in man-hours is fairly well
engrained
> > from mowing the lawn, painting a fence, or testing a web page.
> I'm all for hours if you want to use them. I personally estimate in
> either "perfect time", which I also call "bar time", the amount of
> time I would estimate in a bar if after a few beers someone asked me
> how long I'd need to do something; or in "sessions", which is the
> amount of work Chet and I can get done at Panera before lunch.
Interesting.  I bet more planning sessions would go smoothly if they
included some beer, some snacks, and some good music. :)

> Points are useful, primarily, for two reasons:
>   1. They are less controversial to some teams, who are concerned
>     that if they say something will take 8 hours, they'll be
>     expected to have it done by this time tomorrow. I've seen that
>     expectation be there, so this concern is at least sometimes
>     valid.
My turn to say that this should be wrong.  People get too many NVA
iterruptions to be able to put 8 hours straight into a task.  That
expectation should be something killed after the first retrospecive,
if not sooner, IMO.

>   2. Points are likely to be more accurate than hours when looking
>      at the big picture, in my experience, and they are more than
>      sufficiently accurate for planning purposes.
I don't know if I agree about more or less accurate, but at least now
I understand your position better.  Thanks.

> As I hope you can see, my position is not well described by yes/no
> answers to your three questions. ;->
No problem.  The questions were meant to be open-ended.

> Ron Jeffries
> www.XProgramming.com
> In programming, do, or undo. There is always try.  --Yoda

BTW, shouldn't this be:
> When agile programming, commit to do, or undo. There is no try.  --
Yoda

Or maybe:
> When object instantiating, do, or undo. There is always
try/catch.  --Yoda

:)

--- In scrumdevelopment@yahoogroups.com, Ron Jeffries

<snip>
>
> You avoid my point. There is no "between" between XP and RUP. RUP is
> a framework which describes many actual process instances, including
> XP-style instances.
>
> I note in review of our work here that AUP is described both as
> "between XP and RUP", and as being a reaction to the notion that RUP
> is "insufficient".

AUP and EUP are different things.

I guess I should have said, "RUP out of the box".

>
> > Between would probably means something along the lines of more
than
> > XP, less than RUP out of the box (OTB).
>
> RUP is a framework. It doesn't have an "out of the box". It is
> required to be customized in every instance.
>

Actually, older versions of RUP can be installed straight without any
customization at all.  In the latest version of RMC it comes with two
baselines, one for large projects and one for small projects.  Both
could be installed without any customization at all.

>
> So, these competent people who know when and when not to do things,
> and how much ... why do they need all this instruction, then?

Reminders.  And there really isn't much in the way of instruction,
just a bunch of tips and issues that you might want to address.

>
> And why does the instruction offer so little in terms of judging how
> little or how much, but so much in terms of what?

Many of the tips include URLs to articles on the web.  These articles
have more detail if you choose to read them.

<snip>
>
> I can see why someone would want to create a product to compete with
> RUP. The product in question, as named, is "Agile", and it is
> positioned between XP and a framework, and declares RUP
> "insufficient", all at the same time. RUP is, if anything,
> super-sufficient to anyone with an Agile bent. More than RUP would
> be, well, more, wouldn't it?

The EUP is the extension to the UP, the AUP is the tailoring of the
UP.  Different animals.

>
> > Actually, in that list only two are required (see the artifacts
> > list), the rest are optional.  Nowhere on the diagram does it
> > indicate what is required or not.
>
> My point exactly. If everything is optional, then we don't need the
> process. If some things are optional, we need to know which ones. If
> some things are optional (or scalable) under certain circumstances,
> we need to know which ones and when.

Optional is based on your situation.  You tailor it, hopefully just
in time, to meet your needs.

>
> > Furthermore, how comprehensive theose artifacts are is up to
you.
> > The requirements model could be a stack of index cards and the
> > design model some whiteboard sketches or CRC cards.
>
> I know that. You know that. Your readers, by and large, at least the
> ones I meet, do not know that. I am concerned that the AUP will
> perpetuate the misunderstanding that is common in looking at "Agile
> Modeling".

Which is probably why we need to help them to discover these
concepts.  Providing no guidance at all probably won't help. At least
with AUP, there are numerous links to appropriate articles regarding
these concepts.  Will people follow them?  Some will, some won't, but
at least some will be potentially be helped and may even help spread
the word.


>
> Unpaid political advert noted. Adding roles may be necessary, but
> surely not every project needs the role.

You need someone(s) in that role if there are data sources involved.

> Many projects (I'd say
> most) seem to interpret the existence of a role as justification for
> existence of a person.

That would be a mistake, but unfortunately a common one.

> That person now has a reason for being, and a
> reason for being in the loop. That situation is commonly (I'd say
> mostly) done at the expense of true agility.

Agreed, but not calling out the role confuses the heck out of
people.  I see just as many organizations say "There's no DBA role in
[INSERT AGILE METHOD HERE], therefore we'll just continue to follow
our incredibly dysfunctional approach and force the teams to conform
to our inane process because we have a death lock on the data." OK,
they may not think exactly in these terms but that's about the gist
of it.

So, damned if we do, damned if we don't.  My experience is that if
you explicitly include the data folks in the team, and give them a
bit of mentoring on this agile stuff, then it seems to work out
fairly well.  If you don't engage them effectively, or if you exclude
them, then things don't work out so well.


>
> A good Agile DBA would be in the loop, making decisions every few
> minutes. Someone ought to write that down.

I seem to remember writing a book on that subject.

> >>
> >> The workflow for "Testing" also seems manifestly phasist to me.
>
> > If you choose to view it that way then that's your decision.  Of
> > course, for it to actually be phasist you'd have to ignore the
> > advice to organize the project into iterations.  That's up to you
of
> > course, but if you're making that decision then it sounds to me
like
> > you're no longer doing AUP.
>
> No, I wouldn't have to ignore that. It wouldn't even be necessary
> not to notice it. The outline clearly shows testing separate from
> implementation. The pictures do so as well. They do not look like a
> free flow, from moment to moment, between testing to implementation
> to testing, they look like phases, whether within iterations or not.

If I do that, then the diagrams get even bigger.  Believe me, I've
been down that path.

If somebody only looks at a single diagram without reading the rather
minimal material provided by the rest of the AUP, then yes, bad
things will likely happen.  Sort of like reading a single page in a
book and then nothing more.
>
> I might also note that much current thinking (predating Agile 2.0,
> of course) is that testing comes /first/ in Agile, not second.

I seem to remember pointing out that write a test was the very first
thing in the Implementation discipline, assuming that you look at
diagrams in a relatively western manner.


>
> No, but the diagrams are segmented in what can appear to be time,
> and they run mostly from left to right, which suggests to this
> reader a flow of time. They do not look cyclical or free-flowing:
> they look rectangular, structured, ordered.

And if I moved things around then they'd appear messy, disorganized,
and ill-thought out, just like the traditionalists expect of
this "agile hacker stuff".


>
> Your intentions may be to be just as Agile as the most extreme among
> us. I'm reporting what the presentation says to me as a reader.

Which I appreciate.  Thank you.


>
> >> This blesses modeling -- which is
> >> consistent with your position ab initio -- and while there is lip
>
> > Yes.  I'm very clear about the fact that agilists model.  We draw
> > sketches, we create index cards with text on them, we write
> > acceptance tests, and a whole bunch of other stuff.
>
> Yes, we do those things. I am clear about what exists. You appear to
> be clear about what /should/ exist, and in following your words,
> people appear to think about lots of models that are much heavier
> than index cards, and much less executable than tests.

I try to be clear about doing just barely enough, and a lot of people
struggle with that concept.  Probably a result of the decades of
brainwashing by the traditionalists I suppose.

>
> You have spoken about modeling on a bar napkin or paper bag: I've
> heard you do it. The listeners don't seem to get it. I suspect that
> is in part due to the presentation.

Probably.  I've also seen people walk away from XP because they can't
see a coherent message about modeling and documentation, even though
you've written a fair bit about that (as have others of course).

>
> I have heard you say that. I have also encountered an entire bloody
> book on Agile Modeling. That's not "less" by most standards I'm
> aware of. Again ... it's just not coming across in a minimalist
> fashion, as I read the market.

And I get beat up from the other end of the spectrum saying that it
isn't enough.

A lot of the book, btw, was examples.  And if memory serves, most of
the examples were pretty darn slim.

<snip>
>
> Yes. But look at the exit criteria. There is no code in the exit
> criteria, as I read them.

Yikes.  I better go look at that then.  Working software and source
code are primary deliverables.


<snip>
> How many times does a would-be manager have to look to see his job
> justified? How many times does a reader have to read to get what
> we're giving out.

If that's the case, it's going to happen no matter what.

>
> If we're lucky, people will read our words once. Their impression
> will be filtered by what they already believe in. I believe in
> Agile, rather strongly, and my impression still is that the document
> reads less like Agile than it might.

That could be.  I'll take another pass at it.

<snip>
>
> In any case, does a poor expression in someone else's work justify
> what's in mine? I'd think not. Are those phases tiny compared to the
> inner ones? They don't look tiny in the pictures. Should they?

That's a good point.  I can rework that easy enough.

>
> >> Neither does Elaboration.
>
> > We're actually talking about combining the two because they seem
to
> > run so quickly in practice that it's hard to discern the two.
>
> Are these two phases iterated?

Potentially, but it's usally so quick that a single iteration, often
just a week (if that), is needed.

> In the pictures it appears that only
> construction is iterated. And what about frequent releases ... are
> there loops you'd recommend strongly that are not shown as clearly
> as they might be in the pictures?

My suggestion is that you have working software at the end of each
iteration, and you should at least release it into some sort of
demo/test environment.

> That's what the pictures said to me.
>
> >>
> >> In the Transition phase, we schedule rework. I thought that
rework
> >> was a part of every part of Agile, not just some final "phase".
>
> > Never said that it wasn't.
>
> You list it in only one place. That might suggest that that's where
> it should be, mightn't it?

Good point.

<snip>
> Well, cool, blame the reader. I can handle that. I'd suggest that
> there might be a better way to respond to feedback. I just hope it
> doesn't involve Karate. ;->
>

Never underestimate the impact of a good front kick.

- Scott

I've read that velocity is calculated using historical estimates
(what the team estimated and committed to) vs. the actuals a team
did. An example (condensed for easy math):

5 day iteration, three developers are expected to burn 5 hrs a day
(the other 3 hrs are slop/buffer for email, meetings, etc - last
day), there are 3 stories (for each developer).

Story 1 - 20 hrs estimated - 22 actual
Story 2 - 20 hrs estimated - 38 actual
Story 3 - 20 hrs estimated - 18 actual

Would you not then say the velocity as 78 (average of the 3 actuals,
26 * 3), and maybe schedule 70-75 hrs next iteration, or is it just
60.  I am having a difficult time explaining this to our project
manager to understand why actuals don't equal velocity -- or should
they?  In Mike Cohn's book it seems to indicate velocity is based on
historical estimates, not the actuals.


-Nick

Hi Scott,

I would like to think that I am one of those competent developers able
to discriminate what to follow from your process/product
and what to ignore. As such I choose to ignore all of it. Ron has given
a detailed critique which was very valid IMO. My response to your work
is more general. It just doesn't feel right, it emphasises the wrong
things and it perpetrates myths that many of us have spent years trying
to dispel.

I first came across your work in Agile Modelling, and whilst my general
view was that it was poor, I did think that perhaps it was a useful
attempt to bridge a gap between just code as a model (no model) and big
upfront design. Since then you have been prolific. Unfortunately IMO the
number of products/podcasts/articles etc are not matched by the quality.

For many you are becoming the face of Agile. I have had many discussions
on the server side where your work has been quoted by people who IMO
have very little understanding of Agile, most of them falling into the
pitfalls described by Ron.

I respect the fact that you have come on to this forum to discuss and
defend your work. For me, even with over 12 years of experience behind
me, I didn't get Agile until learning through doing, working alongside
two very experienced Agile Coaches (Rachel Davies and Ivan Moore). I
have not looked into your work in detail since I do not value it, but
from the little I see I do not sense an emphasis on building competence
through practice and coaching. Rather I see a focus on artefacts and
labelled roles and activities, all of which can be readily packaged and
sold, but do not necessarily help people to "get it".

Please in your own words explain the philosophy behind your work, and
how you feel it will help the many "unwashed" out there to "get it".

Paul.





>
>
>