Re: Agile Development, Anyone?

FWIW I've been doing agile for years then. Before I start designing or
coding I sit with the user making the request and talk over the process to
ensure that I have the actual desired outcome spelled out (rather than the
normal "this is what I want/need" garbage). Of course our "Process
Improvement Team" (formerly known as "Six Sigma Black Belts") should do
this work but I generally get better requirements from the actual user
community than the glorified BAs. To do otherwise seems to be
counter-productive to me. If I designed and coded based on the BAs
specs/understanding of the issue 9 times out of 10 I'd be redesigning &
rewriting every project that comes down the pike.

That being said there's times where I have to get the Notes developers
involved since the better solution for the users would be developing the
app in Notes rather than RPG (or a combo of both). At the end of the day
it comes down to providing the best possible solution for the business and
it's users.





From: Buck <kc2hiz@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 08/30/2011 09:50 AM
Subject: Re: Agile Development, Anyone?
Sent by: midrange-l-bounces@xxxxxxxxxxxx



On 8/29/2011 11:46 AM, Joe Pluta wrote:

On 8/29/2011 9:09 AM, David Gibbs wrote:

On 8/25/2011 11:57 AM, Buck wrote:

I am a lifelong RPG programmer -
33 years and a bit - and I think that the agile philosophies have
much to offer me. My colleagues and management don't necessarily
share that view which constrains my ability to adapt particular
methodologies like pair programming. If I could though, I'd
definitely prefer a more agile group.

This is the biggest impediment to Agile / Scrum adoption ... it's a
MAJOR change. You have to change the way you THINK.

And some of it frankly makes me shudder. Pair programming in particular
is a concept that could be as damaging as it is helpful. Two people
doing one job? Just to break even you have to finish the job in half
the clock time with the same number of errors. Fewer errors is
certainly good, but enough to make up for an additional worker? I doubt
you get that sort of improvement for your best developers.

Pair programming stinks for grunt work. Cut & paste from this program
to that, etc. On the other hand, pair programming excels at creative
work, especially work where the solution isn't known before beginning.
When I started work all those years ago, and I moved from the night
shift to the day shift, the office I was in was the only office. I
shared it with the other programmer (the Data Processing Director). I
learnt so much from him and oddly, he from me during the years our chair
backs crashed into each other. We didn't call it pair programming in
the 80s, we called it 'no room to put two desks.'

I would return to that model in a heartbeat for any of my creative work.
It seems to me that I've spent so many of these 30 years focussed on
delivering code when I should have been focussed on delivering business
solutions. Agile appeals to me because the focus is on getting the user
community and your fellow programmer to all work together to deliver the
best solution in the shortest time. Not to deliver N LOC/hour.

Because I've delivered many a thousand LOC that exactly met the written
requirements and yet did not solve the user's business problem. One can
certainly argue that the requirements gathering was incomplete and I'd
agree fully with that, but after 30 years I think the takeaway is that
requirements are never complete and up to date.

Agile appeals to me because it shortens the release cycle from years or
months to weeks. I'll still do rework, just like the waterfall code,
but instead of tearing up 6 months of work, I'll only have to go through
2 or 3 weeks worth.

Personally, I think pair programming is probably much better for new
programmers than for experts. And I think other agile concepts are
probably the same: they make sense in some situations and not in others.

Very true. Agile is not a mechanical 'do this or DOOM' process, it is a
philosophy. It is not a silver bullet, any more than adding a business
analyst was a silver bullet in waterfall. It's still hard work. But I
think the notion of focussing on delivering business solutions sooner is
the right way to think about what I do.

This isn't intended to tell anyone else they are wrong, or to be an
all-powerful convincing argument for adopting Agile. It's my personal
perception and I sort of hope that by sharing it, some folks will
understand why a lifetime RPG guy might think Agile is a really good
idea as opposed to another fad I read about in Dr Dobb's.
--buck