Ruven,
They may be true stories but from my reading of the agile literature, I
would see that the practices represented in the stories would be regarded as
inaccurate representations of agile practice.
In the most recent, you had "code for today". How can that be interpreted.
The coders decided without consultation with the customer as to what was
good to program today. Yes, I agree a bad practice. The naming is clearly
designed to be critical of agile practices without wanting to look at any
rigour or cross checks that might be in those practices. If what was
selected as the stories for this iteration or today's coding where based on
the priorities and risk factors worked out with the customer, is it still
agile practice? Would this ensure that the project had some focus to deliver
something of "benefit to the customer"?
There were other aspects of the story that showed a lack of understanding of
agile practices and how they may be applied to ensure maintainable design.
The thing is that any development practice can have disaster stories told
that reflect badly on the practices. Also having been on commercial projects
that have used upfront design strategies and agile practices, I have come to
see the strengths and weaknesses of these approaches. I have used some of
these stories in my own teaching to emphasise why we want practices that
will address these issues. My preference is clearly agile. It is also clear
to me that many upfront design projects would benefit from the use of some
agile practices such as behaviour-driven development or refactoring.
Too many of the design upfront projects that I have been involved with have
only come to completion because the programmers changed the design so it
worked. They often floundered in maintenance because of duplicate coding and
the lack of refactoring. They also ended up with redundant documentation
that no longer reflected the operating code often because the designers had
moved on to other projects or parts of the project and didn't want to talk
with the programmers.
Whose fault was this? No doubt the programmers, the designers, the analysts,
the project managers, the changing requirements, the ...
In this message you say "From the point of view of nearly all of the writing
in the agile world, the statement that "indeed different organizations have
different needs" would be considered heresy, much less something that one
could go ahead and stipulate." From what I understand of agile methods, they
are tailored for each project based on the client's and the project's
requirements. Yes, there are some core practices but the team has
flexibility to tailor the practices and tool set to meet the project
requirements.
Schwaber may not say that Scrum is unsuitable for some organisations but I
am equally sure that he doesn't say that Scrum should be implemented
identically in all organisations. Sure there are some core practices that
they would want to see in all projects.
Let's stop knocking others because their paradigm of software development
doesn't fit ours and look at ways of learning from each other's strengths
and seeing our weaknesses.
I say this because I quite like some of the model-driven ideas but I would
like to temper their thinking with some test or behaviour driven ideas.
Isn't there something to be gained by having a well modelled system that is
also proven with a solid set of automated tests that can be updated and
reapplied each time a system change is requested.
Yes, let us not forget that software spends most of its life in maintenance
and not in development. So what happens if we produce development methods
that focus on maintainable software rather than on development. In my
research into software development (yet to be published), a high percentage
of those I interviewed saw design quality and maintainability as the
critical aspects in software development. Many of these people also talked
of using some agile practices to help achieve those objectives.
Let us not be blind to the possibilities presented by alternative paradigms
to our own.
---------------------------
Errol Thompson
Massey University
PO Box 756
Wellington 6140
Phone +64 4 801 2794 x 6531
Mobile: +64 21 210 1662
Home: +64 4 938 5069
Skype: Kiwielt
MSN: [EMAIL PROTECTED]
Email: [EMAIL PROTECTED]
Web: www.teach.thompsonz.net
---------------------------
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Ruven E Brooks
Sent: Thursday, 4 October 2007 11:27 p.m.
To: discuss@ppig.org
Subject: Re: PPIG discuss: When agile goes bad....
[EMAIL PROTECTED] wrote on 10/02/2007 01:40:08 PM:
>
> I'm confused by the point of these anecdotes. Is there some study
> that backs up these stories?
>
> Without defending the pros and cons of these (so called) agile
> methodolgies we can stipulate that indeed different orginaztions
have
> different needs. However, these anecdotes come across as an
attack on
> non-formal methodologies and not a careful study of when and where
> orginaztions need to apply different methodologies.
>
> Frankly, it seems just an attempt to troll for controversy. Any
> methodology has aspects that can be abused.
>
> Cheers,
> Chris Dean
The "stories" are true stories, things that actually happened. If
need be,
I could have an outside auditor in to verify that. As things that
actually
happened in the real world, they're probably far better data than
you'd get out
of most controlled studies.
From the point of view of nearly all of the writing in the agile
world, the statement
that "indeed different organizations have different needs" would be
considered heresy, much less something that one could go ahead and
stipulate. I've
been reading "Agile Project Management with Scrum" by Ken Schwaber.
No where does it
say that SCRUM might be unsuitable for some organizations; in fact,
it attempts to suggest
that when SCRUM fails, it probably is due to inadequate training
(Chapter 3).
Before we can do our "careful study of when and where organizations
need to apply
different methodologies," there has to be some awareness that this
is, in fact,
worth doing, because methodologies do, in fact, fail. It's also
useful to have some real world
data on which to base theories of methodology suitability. I offer
my "stories"
as serving both purposes.
Ruven Brooks
----------------------------------------------------------------------
PPIG Discuss List (discuss@ppig.org)
Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss
Announce admin: http://limitlessmail.net/mailman/listinfo/announce
PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
