Agile Otter Blog

People spend a lot of time and effort to improve the accuracy and precision of their estimating. We don't do that anymore. It turns out that agile teams, once they've established a reputation, don't need a lot of estimation skill and many teams around the world operate happily without making estimates at all, since they always work on the thinnest slice of the most important feature at any point in time. Now that I'm a greybeard programmer, I've come to believe five somewhat-controversial things about estimating. Highly accurate estimating does not make your customers successful. I'm always concerned about wasting a lot of time and effort (ie generating waste) in order to become good at something that does not make my customers more successful. If I reduce the standard deviation of my estimates by half, it doesn't mean that my eLearning students will be any more capable of learning or that the materials are any more clear. How much of my time is well...

The title of this blog is more controversial in appearance than in reality. DOWNTIME is merely an acronym to describe the 8 wastes: Defects Overproduction Waiting Non-utilized talent Transportation Inventory Motion Extra processing This I found at wikipedia's Muda entry , and thought it might be worth kicking a link and a quick definition on the blog for those who might want to also use a mnemonic trick.  Note that this is the 7 Wastes that are widely recognized, and the 8th waste of unused talent. This acronym doesn't tell you what to do about them, but that's what the kaizen event is about and we leave it to other experts to help you deal with recognized waste (for now).

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