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 forMessage 1 of 33 , Aug 1, 2006View Source
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?
From: email@example.com [mailto:firstname.lastname@example.org]
Sent: 30 July 2006 11:51
Subject: [scrumdevelopment] Digest Number 1533
Messages In This Digest (9 Messages)
Are SCRUM and XP actually Process Oriented? From: Vickydhiman
Agile 2.0 From: Marco Abis
Re: Are SCRUM and XP actually Process Oriented? From: Ron Jeffries
Re: Are SCRUM and XP actually Process Oriented? From: Steven Gordon
Re: Are SCRUM and XP actually Process Oriented? From: Vickydhiman
Re: Are SCRUM and XP actually Process Oriented? From: Ilja Preuss
Re: Are SCRUM and XP actually Process Oriented? From: PaulOldfield1@...
Re: Are SCRUM and XP actually Process Oriented? From: Ron Jeffries
Re: [XP] Agile 2.0 From: Ron Jeffries
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 differenceVicky, I don't think that's key at all. I think that what's key is
> 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.
what the people actually /do/.
> However, some people in my team find SCRUM is rigid where it wantsRigid? You know people who call that rigid? What are they doing now,
> to be [daily meetings, release planning, product backlog et al].
coming in to work if and when they feel like it? ;->
> Another possible version is that Agile focusses on processes thatOf these, frequent delivery, for some use of the word "frequent", is
> 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]
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 onI think I'd advise not worrying much about differentiating Agile vs
> the same BUT it also focusses on whole lot other things. Is that
> the main difference?
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.
In programming, do, or undo. There is always try. --Yoda
Sat Jul 29, 2006 5:35 pm (PST)
(Message over 64 KB, truncated)
... Because, keeping information in more than one place is fundamentally flawed. Keeping documentation in synch with something else is a big waste ofMessage 33 of 33 , Aug 4, 2006View SourceOn 8/4/06, David H. <dmalloc@...> wrote:
>Because, keeping information in more than one place is fundamentally
> On 04/08/06, Steven Gordon <sgordonphd@...> wrote:
> > On 8/3/06, David H. <dmalloc@...> wrote:
> > >
> > > And as mentioned here before, in such situations go revisit DITA
> > DITA? Would that be "Darwin Information Typing Architecture"?
> > If so, I do not believe any single predefined information meta-model
> > can be appropriate for all projects (unless you melt down to trivially
> > atomic knowledge representations like ER). Even if it was, I do not
> > see how it would solve the problem of static information inevitably
> > getting stale and being a poor substitute for timely communication and
> > collaborative feedback.
> What is "static information" ?
> Every piece of documentation is as alive as you keep it.
> Now if every story develops a task that reads "keep documentation in
> sync" or whatever you call it, PLUS the fact that you can
> auto-generate a hell of a lot of documentation, I do not quite see why
> this picture of big monolithinc, static documents is dso prevelant?
flawed. Keeping documentation in synch with something else is a big
waste of resources. In practice, you get:
1. Resistance to change because the cost of change is at least double, or
2. Documentation not kept up to date when the going gets tough, or
3. Both (the usual case).
Of course, autogeneration is a fine option (although I do not
understand why DITA would be a more useful format than UML). Better
yet is expressive, readable test code that specifies what each
component/class of the system does in a verifiable manner (so that you
know when either the spec or the system is wrong).
>You get what you pay for. I have found passive measures, while
> > Yes, it is important that the domain model in the head of every
> > project member is compatible, but codifying it formally does not
> > guarantee that mental models agree nor does it solve the major issues
> > involved with communication, mutual understanding, and ramping up new
> > people.
> Ramping up people costs money. I appreciate that this is a necessity
> in any project under any methodology, but written documentation is
> passive and can be cosumed any time, any where. Ramping someone up
> through communication and interaction will most likely produce better
> results because there is an immideate feedback loop, but it costs a
> lot more money.
> If you can combine both approaches I would argue that you get
> excellent results, no?
consumable at any time, are an ineffective way to communicate and
learn. And it also costs resources to produce and especially maintain
I know personally, that if you pair me with the individuals on any
team in any technology in any domain while they are doing the work
they would normally be doing, I will learn much more effectively than
by sitting in a cube by myself reading. Furthermore, I would be
contributing value to the team from day, if only by questioning code
and practices that the team has gotten into the habit of doing without
thinking about why.
At least in my case, it costs more for an organization to pay me to
read documents because pairing returns immediate value and trains me
up faster. I do not think I am unusual among professional software