Agile Otter Blog

Eric Ries has suggestions on why/how to move your engineering practice forward and gain speed and reliability while you're at it: So how can I help the engineering manager in pain? Here's my diagnosis of his problem: He has some automated tests, but his team doesn't have a continuous integration server or practice TDD. Hence, the tests tend to go stale, or are themselves intermittent. No amount of fixing is making any difference, because the fixes aren't pinned in place by tests, so they get dwarfed by the new defects being introduced with new features. It's a treadmill situation - they have to run faster and faster just to stay at the level of quality/features they're at today. The team can't get permission from the business leaders to get "extra time" for fixing. This is because the are constantly telling them that features are done as soon as they can see them in the product. Because there are no tests for new features (or operational...

Messages from the past have a way of reaching into the future and getting your attention. This week everyone is talking "apocalypse." This is because of an ancient mayan calendar which quits tracking time on Dec 21st. The joke (I hope we all know it's a joke) is that it stops because that's when time ends. Of course, my calendars used to run out every year (before Google Calendar). The word "apocalypse," according to my sources, was a theatrical term. It referred to the moment when the curtain was pulled back and all was revealed. When I learned that, the title of the biblical book "Revelations" finally made sense, as did more of the text within. Today I'm facing my own apocalypse. An ancient message (from two years ago) has come back and presented itself to me. I like this team. They're good people, and they understand their business. They write quite a lot of code, and they get along. There is nothing to dislike, and much anyone...

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