Does Agile hide development sins?

There are really only two key principles in software development that every project tries to adhere to:

1. To be highly focused on building the right thing (effectiveness principle).
2. Deliver code with few defects by preventing them from getting into the code or removing them as quickly as possible.

To be succinct it means build to the correct requirements and minimize defects.



At project completion your code falls into one of the above four buckets.  The amount of code in the correct requirements section with no defects is what determines if the project is successful. If you adhere to principle 1 then there should be little or no code in the red section.  If you adhere to principle 2 then the yellow section will be minimized.  The application of these two principles is what leads to a successful project.

Software projects are still failing at an alarming rate (see Understanding your chances) because people are still not understanding these two principles.  Initially principle 1 is much more important than principle 2; after all, who cares if you build a defect free system if it doesn't do what is needed?

For better or worse, so called Agile development  has become synonymous with virtually any iterative and incremental software process and is generally assumed to be Scrum or XP by many.

The Good News

The Agile manifesto supports principle 1 with the following statements:

•  Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Working software is the primary measure of progress.

This leads us to focus on an incremental approach to building software where your development cycle is shorter from 2-6 weeks.  Each development cycle has a requirements phase where you can adjust your aim and make sure that you stay on track.

The Bad News

Shorter development cycles  where you adjust your aim is critical to building the right software system, especially if you are faced with technical or requirements uncertainty (see Uncertainty trumps Risk). The problem is that iterative and incremental development will do very little to prevent defects from getting into your code or to get them out quickly once they are created.

With organizations adopting the so called Agile methodologies (Scrum, XP, etc) they are building better software by getting a handle on principle 1, the problem is that they are doing very little to address principle 2, i.e. minimizing defects.

For example, in Scrum all the defects get put into the back log to be addressed at a future time.  How often do people consider the source of the defect or whether it could have been avoided in the first place?

Defects come from multiple sources and need to be addressed by different people. The table below is from Bug Tracker Hell and How to Get Out! where we detail the different kinds of defects, how often they occur, and who has to fix them.

Defect Role Category	Frequency	Role
Requirements defect	9.58%	BA/Product Management
Architecture or design defect	14.58%	Architect
Code defect	16.67%	Developer
Testing defect	15.42%	Quality Assurance
Documentation defect	6.25%	Technical Writer
Database defect	22.92%	DBA
Website defect	14.58%	Operations/Webmaster

Agile won't help you eliminate requirements defects!

With a incremental build cycle that focuses on requirements each cycle you are virtually guaranteed to make some kind of forward progress on your project. But, if you have a poor requirements process and/or poor business analysts (product managers) then you may take 2-3 cycles to solve a problem that could have been solved in one cycle.  The mechanics of a short development cycle will bury defects in your requirements.

Agile won't help you eliminate design defects!

If your development team has built a suboptimal architecture then defects in that architecture will be difficult to detect.  You know that you have an architectural defect when what seems to be a simple change has a huge time estimate on it, something that ends up touching many of the source files. Agile will cover up these problems as people incrementally build out work around solutions to fixing the architecture.  In reality, your architecture will get worse and worse over time and this will manifest in slower and slower development.

Agile won't help you eliminate testing defects!

Defects in test plans and test cases occur 15.4% of the time.  These defects manifest in your bug tracker as Functions as Designed defects.  Each of these defects masks the fact that QA either:

• did not get a requirement
• got a bad requirement for the defect
• did not understand the requirement correctly

Since QA is a continuous process with Agile, QA will fix the test case during the cycle in which they discover it.  This does not leave you with any information on how to prevent these kinds of defects from happening again. Just these 3 categories of defects account for 40% of defects in your development process, and the way that most organizations will implement "Agile" development will bury these problems.  It may surprise you to learn that...

True Agile development does not have these problems.

So just because you are doing Scrum, XP, Crystal, DSDM, or Lean and Kanban software development does not mean that you are Agile.

What it Means to Be Agile

To really be Agile you must support all the principles behind the Agile manifesto. The Agile manifesto supports principle 2 with the following statements:

• Simplicity--the art of maximizing the amount  of work not done--is essential.
• Continuous attention to technical excellence and good design enhances agility.
• At regular intervals, the team reflects on how  to become more effective, then tunes and adjusts its behavior accordingly.

One of the consequences of implementing the simplicity principle above is to prevent defects from getting into the system and causing work for someone else.  This means categorizing your defects and understanding when any of the extended team members (BAs, architects, development, and QA) is creating defects that sandbag your overall development. It means conducting inspections at the requirements, design, and code level to remove defects before they get into the system.  Organizations that do inspections at all these levels achieve an overall defect removal of 97%.  Organizations that do not do inspections will only be able to remove about 80-85% of their defects  (see Capers Jones and Olivier Bonsignour, "The Economics of Software Quality").

To really be Agile you must support all the principles behind the Agile manifesto.