Agile Otter Blog

This is a mostly-verbatim post from a LinkedIn forum.  I thought it was worth sharing with the audience here, so you can help me refine my thinking. In the forum, another member suggested that agile and waterfall are opposite ends of a spectrum. He further suggested that a team can choose its own position along the "sliding scale" between the two extremes.  This is when it dawned on me that maybe I understand why this is not true.  Please pipe in with your insights, extensions, or corrections. It is possible that agile and waterfall are not two approaches to the same thing. If they were two approaches to the same thing, I think mixing them would make sense and the sliding scale makes sense. If, however, they are two different systems with different axiomatic bases, then the reasoning that is productive in the one will be surprisingly counter-productive in puzzling ways in the other. I suggest that the systems are axiomatically different. Agile values c...

How it Happens You realize that you're not getting as much done as you expected to get done. It's troublesome because you have plans and promises and releases to deal with. You're likely to end up the scapegoat when your behind-ness snowballs into a large organization-wide issue. You also have quality problems. Your team leads estimate that the teams are spending 70% of their effort on defect-fixing activities.  It dawns on you that you can get back 70% of the productivity of your team if you can spin up a separate team to handle bugs! Now one team can be 100% dedicated to adding new functionality without being encumbered by bug-fixing work.  After months, you find that the defect density has not improved from your effort. You see a ramp-up in the number of defects fixed per month as the bug team's diagnostic and corrective skills improve, but they are still lucky to hold even against the tide of defect injection. Why doesn't this work? What has g...