- To be highly focused on building the right thing (effectiveness principle).
- Deliver code with few defects by preventing them from getting into the code or removing them as quickly as possible.
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 NewsThe 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.
The Bad NewsShorter 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.
|Defect Role Category||Frequency||Role|
|Requirements defect||9.58%||BA/Product Management|
|Architecture or design defect||14.58%||Architect|
|Testing defect||15.42%||Quality Assurance|
|Documentation defect||6.25%||Technical Writer|
Agile won't help you eliminate requirements defects!
Agile won't help you eliminate design defects!
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
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 AgileTo 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.
To really be Agile you must support all the principles behind the Agile manifesto.