RE: [scrumdevelopment] Re: working according to the screen vs. improvisation
- Thank you Paul ... we're creeping up on it, I think.
But, isn't one of the apparent benefits of agile development that development is actually more productive than the traditional approach.
Therefore, all other things being equal, an agile approach should always be undertaken to take advantage of the productivity that is inherent in the approach.
Surely this is applicable to a project where "the team is well established, the business domain is well known, the system is well known etc."? Of course, the question must be asked, is the business domain ever sufficiently well known, or the system sufficiently well known?
I also would make the point that where a system has been in use for a significant period, and enhancements and modifications are to be done, which are clearly identified requirements, then developing and delivering those enhancements would be done very effectively and efficiently, and with higher productivity, if they were done using an agile, iterative approach. It would just be that the development need not be so 'agile', but just iterative.
And we should never discount the benefits of having your outcomes validated and verified at regular intervals, regardless of how much we think we know the requirements.
And to what degree of certainty can we really ever 'know what we don't know'. That seems a bit like the statement that 'By now, we just know 10% of all knowledge'. How do we know what the 100% is?
So 'knowing what we don't know' seems a bit of a contradiction in terms, to me.
Thank you for the references, by the way. I will follow them up.
Date: Tue, 4 Sep 2007 11:00:33 +0000
Subject: [scrumdevelopment] Re: working according to the screen vs. improvisation(responding to Roy)
> Does anyone know the characteristics of projects that
> are best undertaken in a planned, phased, rigorous
> pre-definition style, and what are the characteristics
> of a projects that are best done done in an agile,
> iterative manner?
> Or, to put it another way, in the terms of this email
> discussion, What are "The attributes of a project that
> determine how we ought to approach it"?
Several writers have addressed this question directly,
e.g. Boehm & Turner's book "Balancing Agility and
Discipline" and Alistair Cockburn's 'Crystal' series.
One level more abstract, there is Phil Armour's book
"The Laws of Software Process" that is essential
reading for any methodologist - if a bit too abstract
for the real world :-)
Using that latter source as inspiration I can give a short
answer to your question:
Software development process is at its strongest in
helping us when we don't know what we don't know.
Waterfall development process is at its strongest when
we know what we don't know. Thus if Waterfall is ever
the right process, it would be where, say, the team
is well established, the business domain is well known,
the system is well known, and the development team
and customer have been working with each other for a
long time. Upgrades to a well-established system may
Assuming you mean what I would mean by "rigorous pre-
definition", then all other projects would not
qualify. We just don't know what we don't know, so
we cannot pre-define a good solution, and doing it
'rigorously' would waste even more effort.
Find out. SEEK Salary Centre: What are you really worth?
- I understand that, Fay, but you are saying that the standards don't change ... but the code will change, by virtue of being developed ... and if it is being developed, then it can be iteratively and frequently tested against the standards, and verified and validated regularly.
And, yeah, I wish I had the million dollars to put up :)
Date: Mon, 10 Sep 2007 17:05:02 +0200
Subject: [scrumdevelopment] Re: working according to the screen vs. improvisation
Although I would love to get the one million dollars mentioned in the mail J…. So, one area, where requirements do not change too much is programs that have to be compatible with standards. One such area, that I have seen was telecommunication, actually mobile phone systems. Sure, there were requirements modifications while developing the program, but a very important part was that a software has to fulfill standardized requirements, and standards do not change that fast. This is how products from different vendors can cooperate, so it is a key requirement. And the systems are big as hell!
I suppose that situation can be enhanced to areas where you have to cooperate with an existing system.
Watch Today! Roast a Rock Star: watch video interviews with hot music acts.