[AR] Agile Software Engineering (was: Re: Re: Testing Scaling Law)
- From: Stephen Daniel <swd@xxxxxxxxx>
- To: arocket@xxxxxxxxxxxxx
- Date: Mon, 21 Nov 2016 07:13:34 -0500
Even in engineering in general (I'm in the software field), there's a
trend towards "agile" approaches which seem to be almost doomed to
failure due to disorganization. It's advocates reject the (whatever)
wisdom may have been learned and rush forword without a big picture.
For example, I'm on one "agile" project where all design is done with
wiki pages and agile sprints which seem completely disorganized. In my
opinion, these are major steps backward. It's almost as if they're
saying "not only can we not estimate properly, we're not even going to
try to organize properly." I know business "leaders" seem not to take
engineering seriously, but at least we engineers should be serious
As a long-time software product manager, I will say that one bad experience
with agile development should not lead you to reject it. Software
development, even on a small scale, is rarely estimated accurately. When
run by experienced leadership, agile development methods provide more
reliable schedule estimation than any other method I've used or seen used.
Of particular interest to me is agile's requirement that engineers estimate
work in "story points". The mapping of points to calendar time is done
empirically. In my experience this produces far more realistic estimates
than the normal method of asking the software engineers how long something
will take.
However, the model fits some software projects, not all. It works best
when the requirements are fuzzy, the list of "features" is long, and
schedule is at least as important as the exact feature set. If I were
developing control software for an embedded computer system I would not use
agile methods.
I suspect that agile is a poor fit to various forms of hardware
engineering.
Other related posts:
