I found agile to be a poor fit for hardware projects. This is because
hardware has issues like
1. It takes time to make something
2. When something is damaged, you can't just recompile it
3. There are externalities on physical objects that software does not have.
I know it is not hip or cool, but I like my Gantt charts. They clearly
communicate durations and dependencies.
I will never use the agile method in my company.
Analytical management says, if you can't measure it, you can't manage it. I
would disagree. There is an endless list of unmeasurable qualities in any
organization that can be managed against if you are aware of them.
Metrics are helpful, but they are no panacea.
On Mon, Nov 21, 2016 at 7:47 AM, Marcus D. Leech <mleech@xxxxxxxxxx> wrote:
On 11/21/2016 10:09 AM, Hugh Blair-Smith wrote:
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
<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.
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.
I find Agile to be a manifestation of something that Brooks said "add
little to a little, and you end up with a big pile".
Now, I've always been a big fan of what was once called "iterative
design". But I'm finding that approach, when scaled to non-trival teams
leads to big amorphous piles of crap. Not the kind of thing you want for
mission-critical systems...
