[AM] Too ambitious?

[Steven Wong]

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 www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Scott Ambler]

Post by Steven Wong
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.

Have they taken a look at www.agilemodeling.com/essays/amdd.htm at
all? Seems like a low investment, high-payback approach to me.

They may still by thinking that you must take a serial approach to modeling.

Post by Steven Wong
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".

Sounds like a slow way to do it, the people doing that could be bottlenecks.

Post by Steven Wong
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... :-)

Stuff happens.

Post by Steven Wong
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).

Congratulations!

Post by Steven Wong
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.

That's going to be challenging. You'll need to find a good middle ground
with these people.

Post by Steven Wong
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.

Yes, there's a huge danger here. You should consider involving someone
with significant modeling experience.

Post by Steven Wong
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.

My suggestion would be to lead by example. Get them involved in the
modeling effort but also allow them to do what they're good at too. Try to
be as iterative and incremental as possible. Perhaps try to convince them
to follow an "extended AMDD" approach where you do a little more modeling
up front than I would normally suggest, perhaps several weeks, to make them
comfortable with the concept, but don't strive to get the models
complete. Then evolve the models as you need. I'd also suggest pushing
for iterations, perhaps longer ones (4-6 weeks at first) to get them
comfortable with the concept.

- Scott

Post by Steven Wong
Thanks in advance,
Steven.

====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[p***@aol.com]

Steven:

But think of the opportunity!

Aside from displacing the current culture with an agile approach, which is
sometimes the most difficult part, understanding what the "agile" in agile
modeling really means and conveying that to the team members and stakeholders might
be your most significant task. Teams that have been using traditional
development methodologies in traditional team structures and processes often have a
difficult time adapting to agile methods.

From my perspective, the use of templates to build a new product should not

pose undue liability, particularly if the new system is intended to be similar
in some way to existing systems (for continuity in appearance, maintenance,
etc.). I have been using a similar approach to building application systems and
products using what might be called a "dynamically customizable system
template" for quite some time, and it has worked very well for both me and my
clients.

One thing I'd suggest for sure is that you keep in mind is that agile
modeling is not about new and excitng development tools, exotic programming languages
or the latest and greatest "best practices" techniques, it's about people and
process. I sometimes describe it as a "state of mind". To paraphrase
(somewhat poorly) a current television advertisement for a chemical company: "Agile
Modeling doesn't build software, it makes building software better".

Good luck in your new venture, and keep us posted on your progress.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Kirk Knoernschild]

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:***@orbit-centric.com]
Sent: Thursday, March 11, 2004 12:19 AM
To: ***@topica.com
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: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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