I've implemented Agile techniques in IBM i shops a number of times and while
I'm certain to get some philosophical arguments from some folks on the list
I'll point out some of the aspects we at Agile Technology Architects
concentrate on:
1) Object oriented design techniques tend to work best in this environment.
Waterfall and the other development processes just are not built for Agile
development. Don't confuse Object Oriented Design with Object Oriented
Development. While they can work together they don't have to.
2) forget the "Agile" techniques as described by the agile zealots, they
don't always work in anything but shops that have been doing it a long time,
and or started with those techniques.
3) The teams are the key, if they are formed correctly then it'll work, if
not it's a failure from the starting gun. You want teams that include power
users, developers, and management. The last one is key, Management. They
have to step up and take responsibility for the team's actions while
allowing the team to work its own way without "guidance" from the manager.
Usually the team will have a stand up at least once a day normally in the
start of the shift, but that's not critical, let the team work it out.
Sometimes they will meet multiple times a day. Stand up is to avoid hiding
in conference rooms for hours, and limits the meeting to about 15 minutes.
Get rolling white boards that can be positioned anywhere, so if the team
needs to visualize something they can. The hallway is a great meeting
place. Bad meeting places, conference rooms, break rooms etc.
4) Sprints (small deliverables) must be set up to build on one another, so
they become building blocks. Each sprint will provide methods that are used
in the next sprint. 40 hour sprints are the best, 80 hour is acceptable but
longer is not. If it can't be done in 80 hours break it down into smaller
parts.
5) Each sprint should have a deliverable the end user can see. It does not
have to be big, but something they know about. Ideally the deliverable is
once a week. The schedule I try to use is simple. Move to production every
Wednesday night. Thursday to end of business on Tuesday are development and
unit testing. Wednesday is integration testing and final approvals.
Thursday morning there might be support requests, those come first. So each
sprint actually starts on Thursday as soon as all support needs are done.
6) Repeat. You'll know you've won the battle when the water cooler
discussion Thursday morning becomes one where the users are discussing the
latest changes.
The fastest way out of the "liability or cost center" into a profit center
is deliverables. When management is actually able to see tangible results
on a weekly basis, the tide starts to turn. It might take a while but it
will happen.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan
Sent: Thursday, July 19, 2018 9:53 PM
To: RPG400-L@xxxxxxxxxxxx; Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxx>
Subject: Agile coming to our shop (supposedly)
(Cross-posted to RPG & Midrange lists)
So, our newish manager threw out this bone at a recent team standup. I have
no experience with Agile, although early in my tenure at a large insurance
company, our iSeries folks worked in the same office as the web dev team,
which was described to be full-on Agile. They were also known as the Agile
team, so there's that.
I remember reading this thread 5 years ago:
https://archive.midrange.com/rpg400-l/201310/msg00393.html
Never gave it much more thought, since it has never come up in that time.
I'm not sure where the impetus for trying to "implement" Agile is coming
from. This company has always treated IT as a liability. The tenured i
developers here feel that they are set up to fail, with new overhead
responsibilities but with the same tight deadlines to get projects
completed. Any new "philosophy" like Agile will be met with
Superman-strength resistance. I laughed when I read about "paired
development", cuz heads would explode if that were ever tried here. The
tenured devs and the new contractors they just recently brought on are
absolute old-school, monolithic developers, for whom 2000+ lines of mainline
code are standard fare. Service programs are avoided like the plague. I
developed a service program last year with functions that could be used in
almost every day development, but I am the only one who uses them.
I am curious if there are any old-school iSeries shops with "heels dug in"
devs who have attempted to "implement" any part of the Agile philosophy, and
how that went.
- Dan
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
midrange.com
