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...

Dealing with product health is simple in theory. You need to have a central build-and-test server and a repo that is treated as the central repo for the developers (in git, servers have no built-in roles). It has to be set up to run all the tests, whether they are unit tests, story tests (cucumber, etc), or what-have you. Now, the thing you have to know is the state of your local machine, and the state of the build server. When I say GREEN , I mean "builds and all tests pass."   When I say RED  I mean that something doesn't build or did not pass all the tests. The Rules The rules in precedence order are: GET TO GREEN.   Green to green ; anything else is obscene. You need to know that your code is good, and the server's code is good, and you can push your code to the server. "But wait", you might say, "there are states unaccounted for here. What about pushing green to red?" "But Tim!" you may cry, "my code isn...