Is there any joy left in this industry?

[david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org (David Kramer)]

On 10/28/2010 10:24 PM, Mark Woodward wrote:
> On 10/28/2010 12:00 PM, discuss-request-mNDKBlG2WHs at public.gmane.org wrote:
>> Date: Thu, 28 Oct 2010 00:42:02 -0400
>> From: David Kramer<david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org>

>> Most things made for 25 years become commoditized as the hard problems
>> get solved, eh?
>>    
> Perhaps, but I can't believe that there aren't any "hard problems" left.
> There are plenty, but the industry has basically decided to fight over
> commodities instead of growing the environment.

OK, go do it!  What's stopping you?  I did it.
I gave you several examples of companies.  Of course there aren't as
many as there used to be.  The combination of the bad economy and the
fact that very few executives are thinking more than a quarter or two
ahead makes companies more conservative.

>> I will agree that a lot of very stupid things are being done in the name
>> of Agile that are not Agile at all, but that's not the fault of Agile.
>>    
> 
> Here's my problem with Agile, the Agile proponents claim it is a good
> system, but decry that when people do it wrong, its the people's fault
> and not "Agile."  A system or practice that depends completely on the
> the people doing it right for success isn't really a system. The fact is

Uhm, so you're saying if you do Agile wrong and you fail, it's Agile's
fault?  "Doc, you told me to take one of these pills a day, but I felt
really bad so I took 8, and now I have a stomach ulcer, so I'm suing you".

Requirements gathering, software design, software development,
integration, testing, and deployment are all hard problems fraught with
innumerable opportunities for failure.  Yes, if you do it wrong, you
open yourself up for a world of problems.

Any practice that is so fault tolerant that you can do it poorly and
still succeed is trivial as to not be comparable to the business of
developing software.  The coffee maker at work isn't even that fault
tolerant.

Waterfall is much less fault tolerant that Agile is.  Even if you design
the perfect software program to suit the initial requirements, by the
time you're done, it's almost guaranteed to no longer be what's needed,
even if the initial design ever *was* what the user needed 8 months ago.

> "competent" people will do a competent job, and incompetent people will
> do an incompetent job. "Agile" does nothing to improve this truism. It

But it *can* mitigate its effects.  When you have to show your work
frequently, it becomes very obvious who is not holding their own.  It
also means if someone does muck things up, you've lost a few weeks
instead of a few months.  If you're pair programming (which I am a big
fan of), you may be able to compensate with proper pairing.

> only makes the development process short sighted and puts the team on an
> endless treadmill of unobtainable "sprints."

The developers are right there in the sprint planning meetings, daily
standups, and sprint retrospectives.  If the plan for the sprint is
unobtainable, the developers are just as much to blame.  If the
developers aren't thusly empowered, then it's not Agile.

Part of the process [in most flavors of Agile] is tracking velocity (how
many story points can be completed in a sprint) and how big a story
point should be (based on estimated vs actual).

> Agile becomes a cudgel for management to have developers ALWAYS behind
> the 8-ball because things always take longer than estimates. Agile's

Agile doesn't dictate how long things should take; you and your
coworkers do.  Even if you have two-week iterations, that doesn't mean
every piece of functionality has to be developed in two weeks.

One aspect of [most forms of] Agile is a balance of power  (the
following is an oversimplification and generalization):
- The PO (Product Owner) comes up with the stories (requirements).
- The PO and the developers discuss implementations and acceptance
criteria.
- The developers break stories up into tasks and assign story points
(time estimates).
- The PO, armed with this data, decides what stories should be in the
next sprint, subject to the story points adding up to less than the
length of the sprint plus testing time, etc.
- Everyone meets regularly so if things are going off-track, measures
can be taken to compensate (dropping stories from the sprint,
redeploying resources, etc).

You see, the *developers* say how long things should take, and the PO
says what gets worked on and when.  Balance of power.  The PO can only
put one sprint's worth of work *based on the developer's estimates* in
the sprint.

> time constraints forces a reduction in problem analysis which means
> that

Not reduction; deconstruction into manageable testable chunks, and not
working on things you don't need yet, because you may never need them.

> you don't really understand non-trivial problems until you are already
> late. Before you know it, you're at work at 9:00 PM working feverishly
> to complete a feature before the next day's stand up.

> In several companies I have worked at or with in the last few years, I
> see the same thing. The old adage is more true under "Agile" than ever
> before: "There never time to do it right, but there's always time to do
> it again."

I have never faced a situation in my current company or my last where I
was told to opt for the quick fix instead of redoing it right.
Shortsighted bad management is shortsighted bad management no matter
what process you claim to follow.

> Then, don't get me started on CEOs and MBA types that preach "Agile" to
> "get engineering under control." Kiss that 50 hour week goodbye. You
> might as well change your designation from "human" to "veal," because
> you are sitting in a small box for the foreseeable future.

You can fill in almost any process (Six Sigma, ISO-900X, TQM, waterfall)
for Agile in that sentence.  Managers want a silver bullet and are
unwilling to accept that TANSTAAFL.  As with all of these processes,
there are pundits who hawk it who don't understand it themselves, or
knowingly misrepresent it for their own gain.  That has nothing to do
with whether Agile is good or bad.

> Some of the core principles of agile are, of course, hold overs from the
> old days and hacking. Iteration instead of in-depth design, favoring
> napkins over velum is better, sure, but while "agile" might have started
> as a way to improve the software development model, like "Rock & Roll"
> it has become a corporate cesspool of the worst sort of practices.

Every method, tool, and practice is a compromise with costs and benefits
(See TANSTAAFL).  Agile does not claim to have invented a miracle cure.
 The various flavors of Agile propose that they have each come up with a
set of practices that compliment each other well, provide measurable
benefit when done right.  That benefit comes from coverage of required
safeguards and the benefits of one practice compensating for the costs
of another.

What this means that if you take Scrum, or XP, or Lean, or Kanban, and
decide to do *most* of it, it's as if you've followed a recipe leaving
out random ingredients.  It only required a dash of red wine vinegar,
but dammit that dash is important to balance the ph of the dish.

So if you decide you're going to do Scrum But ("We're doing Scrum, but
we're not doing practice X"), and decide to leave out pair programming,
unless you put some other practice (code reviews, brown bag
presentations, code analysis tools, internal knowledgebase, etc) in its
place to serve the purpose it was serving, you're gonna end up with a
big pile of Jenga pieces all over the table.

I have found that the most successful Agile projects take the practices
that will work best in their organization and follow them well.  I have
also found that the LEAST successful Agile projects take the practices
that will work best in their organization and follow them well.  The
difference?  Understanding what each practice is for, and picking
practices that cover what need to be covered and complement each other.

> In short, if you are doing "Agile" right, it isn't because of "agile,"
> it because of you and you just happen to have chosen agile. Agile in and
> of itself only makes things worse.

You haven't backed up that claim at all.  You've only proved if you do
Agile wrong it makes things worse, which I agree with.  If a 12 year old
steals his dads keys and gets into a car and smashes it into a pole, the
problem is probably not the car.

I have a recommendation for you.  Agile Bazaar started something new
last month, and we're doing it again for the next few monthly meetings.
 It's "Agile 101" courses that are only half an hour long and are before
the regular meeting.  There you will be able to understand the concepts
of Agile you are missing.  It's free, too.

Think of it as a job hunting activity.  In fact, stay for the meeting,
where we always have a "jobs needs and leads" segment.  You never know
what interesting problem you'll run into ;)