RE: [AM] Too ambitious?

It sounds like there are actually quite a few things that are candidates for
change beyond just modeling. Here are some considerations.

- Don't preach modeling. It's likely you'll encounter some resistance
anytime
you try to change things, and if they haven't modeled in the past, there
will
be those who resist. Instead, incorporate your ideas into your new project
slowly, and in places where you feel you'll get the biggest bang for the
buck.
Really though, I put a few other practices above modeling on the list of
important practices to follow.
- IME, quality issues are usually due to management issues. And I'm not just
talking high level managers and project managers, but also the developers
ability to manage the code, their time, and their resources. This can be
addressed through aggressive testing, and a frequent build cycle. I'm not
sure
how often you build presently, but consider at least a daily build, which
includes a full run of an automated test suite. Make that build available so
that people can see what you're doing.
- Long term, all projects are waterfall. Mostly, this is how management has
to
see things to plan, establish vision, etc. But from a developers
perspective,
you can do a lot to develop iteratively. This starts with a daily build and
a
lot of testing, along with some design and then modeling.
- Functional specs and the meetings that go along with them are boring. I
always try to get the product in front of the client as quickly as possible.
A
few screen shots, a functional prototype, or a proof that's a tangible
simulation of how the system will function evokes a tremendous amount of
thought and discussion among people. It's amazing how much you can learn
about
what the client wants when you put something in front of them that they can
see
and touch. Growing the functional spec using some screen shots to drive the
discussion can make for a very interesting session.
- The developers are the folks writing the code, and they must have an
intimate
understanding of the rules. Involve developers in those meetings where you
talk
about the requirements.

It's likely that you won't be able to change things overnight. Pick a few
things that you consider most important, and try them out. These are just a
few
samples of what could be considered.

Kirk Knoernschild                       |
Senior Consultant/Instructor            |       www.kirkk.com
TeamSoft, Inc.                          |       www.extensiblejava.com
Training, Mentoring, Consulting |       www.teamsoftinc.com



  -----Original Message-----
  From: Steven Wong [mailto:[email protected]]
  Sent: Thursday, March 11, 2004 12:19 AM
  To: [email protected]
  Subject: [AM] Too ambitious?


  Hi all,

  I've been subscribed to this list for quite some time now and have always
enjoyed learning from the postings here.

  This is my first posting and its probably not totally related to Agile
processes at all... but more on soliciting advice as to whether I am being
too ambitious in my current situation...

  Compared to most of the people here, I consider myself really junior with
only about 5.5 yrs of software development experience... Been working in the
software industry for 7.5 yrs, but the last 2 yrs has been pretty much
architecting on paper without much opportunity for hands-on coding work... I
know... still very fresh! :)

  Anyway, I recently joined a software organization that builds front-end
applications for banks (like internet banking and credit mgmt workflow
applications) that does not believe in modeling, or rather, they 'believe'
in modeling, but project timeframe quoted to customers typically does not
justify it. Instead of modeling or designing, they are more into developing
software templates that are then passed on to developers to "copy and
fill-in the empty bits". Probably the only design done before coding is
probably the database design... and screen flow design (which is aka
Functional Specifications here). Doing so allow them to produce modules very
quickly... although there are quite a lot of quality issues popping up in
past projects these days.... but that's another story... :-)

  Anyway, the organization is now thinking of moving into building their own
product (for example, an Internet Bank product) that will be sold and
customized for each individual bank as the profit margin is higher this
way.... As luck would have it, yours truly has been selected to be the
software architect for this productization effort (maybe due to my excessive
preaching on the use of modeling and design). I see this as an opportunity
to drive the organization towards a model/design first before build culture.
On the other hand, I am also apprehensive of the fact that I will be working
with people (developers as well as business analysts) who come from the
traditional "template" approach as well as Project managers that follows
Waterfall lifecycle models rather than iterative-incremental approaches. I
would say that probably I would be the only person on the team with some
experience in modeling (and I am not very experienced at that!).This leads
me to think that this could potentially back-fire and encourage the
disbelief of the organization on modeling and design.

  In addition to corporate culture, the development process that I will be
facing is probably not going to be iterative-incremental... and inputs will
probably still be Functional Specs (containing just screen design with field
descriptions and logic description)...

  I've said a lot... but I guess to sum it all up, I just wanted to find out
if I am being too ambitious to try to get the entire team to do modeling and
design first before coding as well as solicit as much advice as I can from
all the experienced people here on how to approach this.

  Thanks in advance,

  Steven.
For more information about AM, visit the Agile Modeling Home Page at

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------