9/18/2009 Agility@Scale: Strategies for Scaling Ag…

My Hom e Profiles Groups Blogs Bookm arks Activities ichiw ay100 Help Log out

developerWorks My developerWorks Connect

Search

My developerWorks: Blogs

Brow se Blogs My Blog My Updates

Subscribe to Blog Entries Agility@Scale: Strategies for ... Sim ilar Entries

Subscribe to Blog Blog Authors: ScottAmbler Our integrity debt c...

Com m ents Blog: Agility@Scale...

Previous | Main | Next
ScottAmbler
Subscribe to Com m ents Updated Wednesday 10:05
Is software development an art or a science? 9
for this entry 1 1
ScottAmbler | 30 Aug | Tags: m cif agile philosophy | Comments (4) | Add a Comment
I was recently in Bangalore speaking at the Rational Software Conference, which was really
Tips & Tricks on agi...
Tags well done this year, and visiting customers. In addition to discussing how to scale agile
Blog: Rational Even...
software development approaches, particularly when the team is distributed geographically KarenLee
and organizationally, I was also asked about what I thought about a software factory approach Updated 10 Sep
to development. My instinctual reaction was negative, software factories can result in lower 2 0
overall productivity as the result of over specialization of staff (I prefer generalizing specialists),
agile certification integrity- too many hand-offs between these specialists (I find close collaboration to be far more Re: 5 Things You Can...

debt mcif philosophy scrum effective), and too much bureaucratic overhead to coordinate these activities. I initially chalked it Blog: Sum a's Scribb...
up to these people still believing that software development was mostly a science, or perhaps SumaChakrabarti
View as cloud | list Updated 18 Aug
an engineering domain, whereas my experiences had made me come to believe that software
0 0
development is really more art than it is a science. Yet, the consistent belief in this strategy by
very smart and experienced people started me thinking about my position.
5 Things You Can Do ...
Blog: Rational Even...
Just let me begin by saying that this blog posting isn't meant to be yet another round in the age KarenLee
old, and relatively inane, "art vs. science" debate within the software development community. Updated 18 Aug
That debate is a symptom of versusitis, a dread disease which particularly plagues the IT 2 1
industry and which can any of us at any time. There is no known cure, although the
combination of experience, open-mindedness, and critical thought are the best inoculation Agile Proj ect Initia...
against versusitis that we have so far. In that vein, let me explore the issues as I see them and I Blog: Agility@Scale...
will let you think for yourself. ScottAmbler
Updated 12 Aug
0 0
On the one hand software development has aspects of being an art for several reasons. First,
the problem definition is never precise, nor accurate, and even when we have detailed
specifications the requirements invariably evolve anyway. The lack of defined, firm Archive
requirements requires us to be flexible and to adjust to the situation that we find ourselves in.
September 2009
Second, teams typically find themselves in unique situations, necessitating a unique process
and tool environment to reflect this (assuming that you want to be effective, otherwise there's August 2009
nothing stopping you from having a "repeatable process" and consistent tool environment).
July 2009
Third, software is built by people for people, requiring that the development team have the
ability to build a system with a user interface which meets the unique needs of their end users. June 2009
One has only to look at the myriad UI designs out there to see that surely there is a bit of art
May 2009
going on. Fourth, if software development wasn't at least partially art then why hasn't anyone
succeeded at building tools which take requirements as inputs and produce a viable solution April 2009
that we can easily deploy? It's been over four decades now, so there's been sufficient time and
March 2009
resources available to build such tooling. Fifth, regardless of how much of a
scientific/business facade we put over it, our success rate at producing up front detailed cost February 2009
estimates and schedules speak for itself (see Funding Agile Projects for links to articles).
January 2009

On the other hand software development has aspects of being a science for several reasons. November 2008
First, some aspects of software development have in fact been automated to a significant
October 2008
extent. Second, there is some mathematical basis to certain aspects of software development
(although in the case of data-oriented activities the importance of relational theory often gets September 2008
blown way out of proportion and I have yet to see a situation where formal methods proved to
August 2008
be of practical value).
May 2008
What does this have to do with Agility@Scale. As you know, one of the agile scaling factors is
March 2008
Organizational Complexity, and cultural issues are the hardest to overcome. Whether your
organization believes that software development is mostly an art or mostly a science is a February 2008
cultural issue which will be a major driver in you choice of methods and practices.
January 2008
Organizations which believe that software development is more of a science will prefer
strategies such as software factories, model-driven architecture (MDA), and master data December 2007
management (MDM). And there is ample evidence to support the claims that some
November 2007
organizations are succeeding at these strategies. Although you may not agree with these
strategies, you need to respect the fact that many organizations are making them work in their
environments. Similarly, organizations which believe that software development is more of an

ibm.com/…/art_versus_science 1/2
9/18/2009 Agility@Scale: Strategies for Scaling Ag…
art will find that agile and lean strategies are a better fit, and once again there is ample
evidence that organizations are succeeding with these approaches (there's also evidence that
agile projects are more successful than traditional projects, on average). Once again, you may
not agree with these strategies but you need to respect the fact that other people are making
them work in practice.

Trying to apply agile approaches within an organization that believes software development is
mostly a science will find it difficult at best, and will likely need to embark on a multi-year
program to shift their culture (likely an expensive endeavor which won't be worth the
investment). Similarly, trying to apply a software factory strategy in an organization that believes
that software development is mostly an art will also run aground. The bottom line is that one
size does not fit all, that one strategy is not right for all situations and that you need to
understand the trade-offs of various strategies, methodologies, techniques, and practices and
apply them appropriately given the situation that you face. In other words, it depends! If you are
embarking on a software process initiative, and you don't have the broad experience required to
effective choose between strategies (very few organizations do, although many believe
otherwise), then you should consider Measured Capability Improvement Framework (MCIF) to
help increase your chance of success.

Add a Comment Recommend this entry More Actions

Comments

1 kelleydg 1 Sep Permalink 0

Well put. I never considered Agile to be an approach that might appeal more to those who see software
development as an art form. This also can explain why some folks are uncomfortable with one
approach versus the other--it's not in line with the way they naturally think. Thank you for this food for
thought.

2 ScottAmbler 1 Sep Permalink 0

Perhaps a better way to say it was that agile appears to be attractive to people who consider software
development to be more of a craft than an engineering discipline.

3 jgerber 1 Sep Permalink 0

Thanks Scott, helps explain so many Software companies are following IBM's lead and jumping on
agile programming bandwagon.
http://www.infoworld.com/d/developer-world/software-companies-jump-agile-programming-bandwag
on-666

4 ScottAmbler 5 Sep Permalink 0

I suspect that people are "jumping on the agile bandwagon" due to the improved quality, improved
chance of delivering functionality that people need, better time to value, and better return on investment
(ROI) provided by agile teams compared to traditional teams. See the 2008 Project Success Survey
results at http://www.ambysoft.com/surveys/ (there are other links there too that you might find
interesting).

Previous | Main | Next

IBM developerWorks® Feedback: Survey Feedback: Discussion Report abuse My developerw orks terms and conditions

About IBM Privacy Contact Term s of use

ibm.com/…/art_versus_science 2/2