On 11/21/2016 10:09 AM, Hugh Blair-Smith wrote:
I've been an Agile victim now for several years. While it has its merits, I find the process frustrating at times. In our projects there's *NEVER* any time to address technical debt, which often means that "new things" get harder and harder to implement, since there was never an architectural backbone upon which to hang stuff.
On the other hand (regarding embedded computer systems), here’s a take from Wired:
http://www.ca.com/us/rewrite/articles/devops/did-agile-land-a-man-on-the-moon.html
Wish I’d thought to be more explicit on those points in “Left Brains for the Right Stuff!”
------------------------------------------------------------------------
*From:*arocket-bounce@xxxxxxxxxxxxx [mailto:arocket-bounce@xxxxxxxxxxxxx] *On Behalf Of *Stephen Daniel
*Sent:* Monday, November 21, 2016 7:14 AM
*To:* arocket@xxxxxxxxxxxxx
*Subject:* [AR] Agile Software Engineering (was: Re: Re: Testing Scaling Law)
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.
