Agile Attitudes- Frequent Releases

[agileattitudes at agilerules.com]

Agile Attitudes
Volume 1, Issue 14                                    Dec. 16, 2004
                  A free bi-weekly email newsletter
                         Brought to you by
                       Agile Rules consulting
                         www.agilerules.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Welcome to Agile Attitudes, a newsletter of ideas, insights and
technical tips that help people find better ways to develop
software. Feel free to share this with anyone - just be sure you
send or print the whole thing, including the copyright notice.

Directions for managing your subscription are below.

                         O><O><O><O><O><O

This will be the last Agile Attitudes for this year. Nancy, Ron
and Dave wish you a wonderful Holiday Season.

XP Day to be held Saturday, February 19th in Toronto! Registration
is only $299 if done by January 19. See  http://www.xpday.info
for more details.


                         O><O><O><O><O><O

                        Frequent Releases
                         by Ron Morsicato

In order to insure you're on the right track, the agile practice
of frequent releases allows the developer to nearly continuously
get feedback from the customer. Nevertheless, I've heard time
and time again that the customer doesn't want to be bothered
often by the increments of functionality. There may be legitimate
reasons for this. The cost of deployment may be high, or user
retraining may be involved. But you need to ask yourself, is this
cost considered high because the customer sees your track record
as delivering buggy code? Is the retraining issue really a smoke-
screen for users' expecting the unexpected, and once again have
to learn new ways to avoid unpleasentries?

Your relationship with customers is vital to your success. The
frequent, periodic demonstrations for your customers are a tool
that allows you to foster a collaborative working relationship.
Getting involved and seeing working, low defect code (because
of strong, continuous testing and integration practices) adds
to their enthusiasm of working closely with you. The important
thing to remember is that although the periodic demonstration
to your customer should require you to produce frequent code
bases that are deployable, it does not mean that the code will
actually be released to the general user community.

Releasing code to users is a business decision. If you really
want to be agile, you need to allow the business as a whole to
be agile. This means that from a software team's point of view,
they serve management well if release decisions can be made
independent of development progress. When, for example, a new
release is called for to respond to a competitor's recent actions,
you're doing no one a favor if you have to delay the release to
perform regression testing, regarded as a follow-on phase to
code development. Instead, make the effort to automate regression
testing just as we recommend you automate unit and acceptance
testing. (I guess you can call automated regression testing the
maintenance of previous acceptance testing; i.e., don't break
your past acceptance tests: update them as their relationship
to the current code base changes.) This will allow you to put
out a product when the business demands it.

In summary, good agile practices are good business practices.
By being there with deployable code for demonstration for the
customer and quickly releasable code when the business demands
it allows the software development team to truly be a value
center, not a cost center, to the business
 

                        O><O><O><O><O><O
More articles on Agile software topics at http://www.agilerules.com
Within our company we have a sub-specialty in embedded systems.
Our site has articles on embedded XP and we support a discussion
list focused on the use of agile methods for building embedded
software. The list signup info is at
http://www.agilerules.com/mailinglists.phtml

                        O><O><O><O><O><O
To help you get started with in-depth research into Agile Attitudes
topics, we have added a Library section to our web site at
http://www.agilerules.com/library.phtml
Order using our links and receive discounts up to 30%!

                         O><O><O><O><O><O
If you enjoyed this issue or found it useful, forward it to a
friend! Help spread the word about better ways to build software.
Invite your friends and colleagues to join our growing reader
community at http://www.agilerules.com/mailinglists.phtml

                         O><O><O><O><O><O
Looking for a speaker for your next corporate or society meeting?
We present dynamic, informative programs on topics of interest
to managers and technical staff in their transition to more
flexible, robust ways to create software.

                         O><O><O><O><O><O
Want to reprint this issue in your company or society newsletter?
For permission to reprint any of the articles, contact us at
info at agilerules.com.

                         O><O><O><O><O><O
If you would like to receive an email as soon as we know of
an event in the Boston area of interest to the agile software
community, you can sign up for the announcements list at
http://www.agilerules.com/mailman/listinfo/agileannounce

                         O><O><O><O><O><O
Your feedback is welcome! Send feedback to info at agilerules.com

To manage your subscription:
http://www.agilerules.com/mailman/listinfo/agileattitudes

                         O><O><O><O><O><O
             Brought to you by Agile Rules consulting
               162 Marrett Road, Lexington MA 02421

                  Copyright (c) 2004 Agile Rules
                       info at agilerules.com

                        O><O><O><O><O><O
Privacy notice: We will not release a subscriber's address to any
third party for any reason. This is a strictly opt-in newsletter.
No one is ever subscribed without their explicit request.