Topic: Mindset and culture
The way software defects are seen on traditional vs agile projects reveals something about the differences in organizational culture. Given the following causes of defects...
Type 1: Programming error
Type 2: Misunderstood requirement
Type 3: Requirement defined incorrectly
Type 4: Discovered requirement
...the typical response to each type of defect is exactly opposite on agile teams compared with traditional teams.
| Traditional mindset | Agile mindset | ||
|---|---|---|---|
 | Type 1 defects are good news. Lacking effective practices to prevent and/or correct coding errors early (such as TDD, automated and repeatable tests, and frequent feedback), Type 1 defects are very common on traditional projects. Catching them early in the process is definitely better than catching them later. They are also the most readily understood type of defect, and the most politically acceptable, since they do not call into question the finalized and formally-approved requirements...or the competence of the individuals who finalized and approved them! |  | Type 1 defects strongly indicate serious methodological problems. Few basic coding errors slip through the cracks when TDD is used in a disciplined way, when the team uses continuous integration with automated, repeatable tests, and when customers actively review incrementally-delivered results and provide feedback to the team. If the team is using pair programming as well as other agile practices, then the existence of many basic coding errors is an even stronger indication of problems. It's likely that more than one agile practice is being mis-used, and the team's effectiveness is suffering. |
 | Type 2 defects are acceptable. They can usually be explained away by non-technical folks as developer carelessness, and by developers as business analyst carelessness. Worst case, business analysts may have to admit that they could state their descriptions of requirements a little more clearly. Everyone can avoid blame by pretending that business people and technical people aren't expected to understand one another anyway. No one gets too badly hurt. |  | Type 2 defects are a "process smell" that warrants an investigation into the cause. Ideally, on an agile project there is no layer of isolation between the customer (Scrum term: Product Owner) and the developers (Scrum term: Team). When there is too much emphasis on an intermediary role such as Business Analyst to act as a translator between business-speak and techno-speak, many requirements are understood differently by different stakeholders, leading to defects of this type. |
| Type 3 defects are unwelcome and potentially politically dangerous. One of the tenets of the linear waterfall approach is the belief that once a phase has been completed, reviewed, and approved, its results are not to be questioned. To do so raises doubts about the competence of the people who completed, reviewed, and approved the results of the phase. When an incorrect requirement is detected in the context of this sort of process, it means the people who gathered and elaborated the requirements "failed" in some way. That is a good night into which they are unlikely to go gentle. | | Type 3 defects are acceptable. While a Type 3 defect might indicate the business drivers for the project were not well understood at the outset, it also qualifies as a sort of discovery. As we refine our understanding of requirements, we learn that some of the initially-stated requirements were simply wrong. This is far better than going forward on the wrong track, and is seen as positive. It is not taken to mean the people who created the initial list of requirements "failed" in any way. They listed the requirements according to their best understanding at the time, and that is perfectly okay. |
| Type 4 defects are politically dangerous. Traditional project management processes include elaborate, heavyweight change control procedures that are designed more to discourage change than to control it. The idea that a requirement might be discovered in the course of development flies in the face of the most fundamental assumption in traditional IT — the belief that all requirements can be accurately and completely predicted before any other work is started. | | Type 4 defects are good news. The whole idea of adaptive development is based on the understanding that no one can accurately and fully predict all the requirements of a new software system in advance. Not only is it perfectly normal for requirements to become clearer as the team makes progress, but agile thinkers would see it as a red flag if the team's understanding of the requirements did not change. It would suggest people are not paying attention to interim results. |
Posted by Dave Nicolette
at 4:32 PM EST
