Re: [scrumdevelopment] All 'defined' processes doomed that have intellectual ...
- On 6/26/06, PaulOldfield1@... <PaulOldfield1@...> wrote:
>My interpretation of Phil Armour's "The Laws of Software Process is
> (responding to Julian)
> > And therefore I'd propose that yes, all 'defined' processes that
> > have intellectual / creative elements in them are doomed to fail.
> > Thoughts / perspectives on this?
> I favour Phil Armour as a sensible writer on process ("The Laws
> of Software Process").
> I hope I'm correct in saying that he says the true value of having
> a process is in situations where we don't know what it is that we
> don't know. A process can tell us what questions we should be
> A process could also tell us how to go about answering those
> questions, but that is of nowhere near so much value.
> Some agile approaches favour a different approach - a safety net
> that can rapidly tell us that we didn't ask a question that we
> should have asked.
> One might say that the important thing is to do the right things,
> to take the right actions, in order to produce the right output.
> Alternatively, one might say what really matters is to think the
> right thoughts in order that one will choose to do the right things.
> Defined processes are only a problem when either (or both) the
> definer and the enacter believes there is no need for any thought
> process to be involved... I include 'management' as an aspect
> of the definer, before anyone jumps on that obvious loophole.
> I'm not sure whether that makes me in favour of defined, or of
> empirical; but I'm definitely in favour of thinking, and of anything
> that helps us to do that effectively..
> Paul Oldfield
that there are defined processes (such as builds and configuration
management) and empirical processes (such as solving a problem we have
never solved before) mixed together in software development.
Given that mix, we should totally automate the defined stuff, so that
we are free to use our creative energies on the empirical stuff.
After automating the defined stuff, we can proceed to ignore it.
Then, from the developer and customer points of view, all that remains
of the software process is the empirical.