Agile Attitudes- Too Scared to Do The Right Thing: Offshoring and
Agile - Pt. 2
Ron Morsicato
morsicato at comcast.net
Thu Oct 7 21:24:03 EDT 2004
Agile Attitudes
Volume 1, Issue 9 Oct. 7, 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
See our publications page for Nancy's Embedded Systems Conference
paper and accompanying slides. The URL is:
http://www.agilerules.com/publications.phtml
O><O><O><O><O><O
Too Scared to Do The Right Thing: Offshoring and Agile
Part 2 of 2
by Nancy Van Schooenderwoert
In part 1 of this newsletter topic I relayed a conversation I had
with upper management at a small high tech company. They were
greatly concerned that they may be forced to send their software
work offshore to stay competitive.
Paul, the company President, said he'd like to see how I develop a
response to the concern that Americans cannot compete on price for
software services. After our conversation about agile software
development methods for embedded software, his feeling seemed to be
that nobody can concentrate on software methods while they fear
losing their job any day.
This same fear is why the software employment market has stayed so
tight for the past few years. Everyone's in survival mode - waiting
out the storm. We cannot compete on price (wages) with people in
other countries who have a far lower cost of living. So we have to
compete on innovation, on responsiveness to our customers, on superior
ways to interact with managers, marketers, and other engineering
disciplines that can lower costs while increasing quality, not at its
expense. This requires creative thinking, but people who are scared
out of their wits are not in a frame of mind to be creative, or to
take the calculated risks necessary for innovation.
That leaves us stuck in a downward spiral. Instead, let's consider
some practical examples of how we can compete in those other areas.
Businesses view the cost of software development as a necessary evil,
but they are eager to build strong relationships with their customers.
Agile development can help here, especially with early adopters. The
early iterations, and the contact with customers as they try out
functionality are valuable for a company's image as responsive and
innovative. It's an opportunity for a business to collaborate with
early customers on the design of a product. It's a great motivator
for software developers when they can support their product in field
use, making a difference for customers.
I've seen argumentative software teams that I'd never want to put in
front of a customer - what about that? Team building is a big topic -
too big to tackle here. Agile software methodologies balance the
"people side" of software work with technical practices that demand
genuine teamwork. They provide an excellent foundation (not a
guarantee) for building a high performance team.
Agile practices stimulate innovation by providing a structure to let
managers and technical people make optimal decisions when balancing
features and costs. For example in XP's "Planning Game" practice,
managers know how much effort and risk is associated with each
feature they want. They can rely on these estimates from the developers
because the developers do estimation every few weeks, and then work to
their own estimates.
Another way innovation happens in agile teams is that requirements are
directly communicated. In conversation with domain experts, developers
can grasp the reasoning behind requirements and use their expertise to
suggest new possibilities. This kind of spontaneous thinking is the
first thing to go away when distance or documents separate the
developers from the domain experts. That's not to say "don't document".
Documents are fine for recording ideas after the fact, but the
generation of new ideas, new approaches, etc. should happen directly
between people.
In an agile software team, nothing's ever 90% done. It's either done or
not done. And "done" means there is a test you can use to see it
working, so you always know where you stand.
Businesses using Agile practices will have:
* Superior technical/business resourcefulness through the mechanisms
for collaboration among different disciplines
* Solid reality checks whenever needed
* Ability to react quickly to market needs, and customer requests
because software is supported by those who built it (and they love
genuine teamwork so turnover is almost nil).
Any project that has significant unknowns at the start needs these
capabilities. It's imperative to get in first if the path is viable,
and also to cut losses quickly if it turns out not to be viable.
The projects with the significant unknowns are likely to be the most
lucrative because by definition they are breaking new ground. Agile
methods are designed to help a project either succeed or fail early.
Agile is all about good risk management.
When a business needs a true technical partner, value - not price -
is the key ingredient. An agile software team interleaved with a
business's domain experts and customers is the tool to provide
these agile capabilities.
So, are we too scared to do the right thing?
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.
_______________________________________________
AgileAttitudes mailing list
AgileAttitudes at agilerules.com
http://www.agilerules.com/mailman/listinfo/agileattitudes
More information about the AgileAttitudes
mailing list