Agile vs Fragile: A Disciplined Approach or an Excuse for Chaos

On February 11-13, 2001, a group of seventeen people met at The Lodge at Snowbird ski resort in Utah.  This group shared a common desire to improve their skills on the ski slopes and to improve the software they developed. Their collaboration created the Agile Software Development Manifesto. The participants of this meeting represented different perspectives on software development, but they all agreed that they wanted to develop an alternative to long project cycles. They may have discussed the concepts of what makes a team agile vs fragile, but they left their meeting with a Manifesto for Agile Software Development signed by all participants:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

individuals and interactions over processes and tools
working software over comprehensive documentation
customer collaboration over contract negotiation
responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The Agile Manifesto establishes a set of 12 principles aimed at increasing the speed at which customers can realize the value of a development undertaking.  It focuses on delivering quick hits rather than protracted development timelines usually associated with traditional development methodologies, such as Waterfall.  While the principles of Agile are a refreshing focus on delivery, they are often hijacked to become an excuse for the undisciplined development organization.  The Agile framework’s focus on agility is anything but undisciplined, as illustrated by principles such as Test Driven Development (TDD). However, rogue development organizations have pointed to Agile as the impetus to abandon all vestiges of process, documentation, and (in many ways) quality.  These organizations have added a fifth principle to the manifesto:

speed of the delivery over quality of the delivered

This series of blogs will explore characteristics of effective Agile teams, and identify the characteristics of teams that are using Agile as an excuse for poor project delivery practices.  Let’s call them “Fragile” teams.  We will also help answer some of the common questions that testing teams have as it relates to Agile organizations.  These blog sessions will cover the following areas:

  • Agile or Fragile: How to tell which your organization is
  • Agile Characteristics: The characteristics of excellent Agile and Fragile teams
  • Agile Manifesto: What does it mean for processes and documentation?
  • Agile Testing: The role of “independent” testing in the Agile framework
  • Agile Tools: Do testing tools have a place in Agile development?
  • Agile Façade: Strategies for breaking down the façade

This blog article is the first in a series of 17 blog entries that have been published. In the next installment of the blog we will talk about how tell if your organization is Agile or Fragile. In the meantime…Keep on testing!




Agile vs Fragile: A Disciplined Approach or an Excuse for Chaos


Agile vs Fragile: How to tell which your organization is


Agile vs Fragile: Add Value to Customer


Agile vs Fragile: Change … Bring It On!


Agile vs Fragile: Deliver Small Wins Faster


Agile vs Fragile: Success Requires Participation


Agile vs Fragile: Empower the “Right” Employees


Agile vs Fragile: Quality Matters


Agile vs Fragile: Not a Death March


Agile vs Fragile: Technical Discipline Matters


Agile vs Fragile: Simplicity = Stability & Speed


Agile vs Fragile: Let the Team Shine


Agile vs Fragile: Retrospective Look Forward


Agile vs Fragile: What the Agile Manifesto means for processes and documentation


Agile vs Fragile: The role of “independent” testing in the Agile framework


Agile vs Fragile: Do testing tools have a place in Agile development?


Agile vs Fragile: Strategies for breaking down the façade


What's Next?

Did you enjoy this article? Help spread the word by sharing:

Join the Northway Navigator Club today and get access to restricted content including our best tips and tricks. Membership is free! You will also receive free email updates by registering.

Engage in the conversation and leave a comment:

Brian Copeland

About Brian Copeland (19 articles)

With over 25 years of senior level experience in the software development industry specializing in organizational transformation and development, Brian has been instrumental in the testing of critical business systems, from mission critical applications to commercial software. Mr. Copeland’s career has included 10 years as the Test Operations Manager for the Titan II, 34D, IVA, and IVB programs, managing both flight and ground software-testing facilities for Lockheed Martin. Mr. Copeland also served as the Sr. Manager of Quality Assurance for the shared services of Deloitte & Touché, LLP. His diverse experiences range across the aerospace, medical device, title insurance, legal services software, big four accounting firm, and banking industries. Brian led the global testing organization for The Nielsen Company, overseeing the successful transformation of the testing function made up of over 750 testing associates. Mr. Copeland has been a key-note speaker at the International Business Forum, and has been a featured speaker at HP Software Universe. Brian is a past president of the greater Cincinnati International Institute of Business Analysts (IIBA), and holds an ITIL v3.0 Foundations and RCV certifications.