Agile Otter Blog

We recently started talking about Taking Agile Back . I was surprised to hear how much response came from this. Now we have a community on google and presence on linked in and yahoo groups and twitter . People are coming from the woodwork to say that they're also sad about the state of agile practice and they either yearn to return to agile values, or they lament that they never were able to enjoy really practicing those values. But what do we do? I think that there are at least three immediate steps we can take. Remove barnacles Reinstate values Move forward Remove Barnacles The first is a tad negative. We should call out the things that have grown on the skin of agile (shallow, peripheral issues) and have obscured the heart of the principles.  I've already addressed some of the noise that has grown up around velocity and estimation . I've been suppressing a number of opinions on metrics and disengagement.  You can love or hate Linked-In, but ...

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

Your team is hard at work, testing and coding and planning, and suddenly the build breaks. Now what can you do? The broken build might not be your fault at all, and besides you have work of your own to do. You could go ahead and practice business-as-usual, but this is probably a bad idea. Here's what I say: Never pull from a broken build . Assume that version control is poison. If you are not the one fixing the build (and shouldn't you be?) then you should leave it be. The last thing you want to do is import brokenness into your local build environment. Import from a "green" build, and you will know that any brokenness is your problem. Test locally before considering pushing code to the CI build, even though it takes a bit more time. There is really no good time to NOT know that you've broken something. A little "due diligence" goes a long way. Never push to the CI server if your local build is broken . If your build is broken, it inconveniences...

Jim Hood (of Pillar Technology) and I just installed our first ever "ambient annunciator" to announce our build's breakage. Well, technically our first two. What it does is watch for a build to fail in Jenkins, then start playing a series of randomly-selected choices from our assortment of spooky public domain sound files. Some are musical interludes, some are animal sounds, some are just weird. Annunciator #2 video, woofer, and R/L speakers. Our intention is that these sounds, playing through a decent set of speakers, will create an atmosphere of something being "not quite right." With both systems playing test noises, it was a tad eerie. You really felt that there was something different about the space. It is a bit more subtle than flashing lights, and we're hoping this will be an advantage. Developers will know the build is broken, and will have incentive to get the space back to normal (it is a little annoying) but will still be able to have co...