Agile Otter Blog

I'm Tim Ottinger. You may already know me. I'm a long-time developer, agilist, XPer, CI/CD, teaming/ensemble, TDD, and general software delivery specialist. I wrote the second chapter of Clean Code .  I am the originator and co-author of Agile in a Flash with Jeff Langr, and I wrote Use VIM Like a Pro . I'm mentioned in the "acknowledgements" sections of many other books on Code Craft, Agility, Design Patterns, because I’ve been heavily involved in the tech community and have done reviews and edits of their pre-publication materials. I worked with "Uncle Bob" Martin at Object Mentor (twice). With his company, I taught physicists at Stanford Linear Accelerator Center how to improve software design for high-energy physics. I worked with companies like Caterpillar, Xerox, and many others. I worked with Ian Murdoch (who founded the Debian Project) in his company, Progeny Linux Systems . We created software to aid in the creation of custom commercial Linux ...

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

The law of Raspberry Jam is "the more you spread it around, the thinner it gets." A useful principle when dealing with work-in-progress, attention span, goal-setting, etc. I found this gem recited in an email a while back and saved it, without really remembering who wrote it. If you know, please feel free to help attribute it. It quotes Goldratt's /Critical Chain/: There’s a lovely example of the evils of multitasking in Goldratt’s Critical Chain. Suppose you have three things to deliver: A, B and C. Suppose they all take, I don’t know, 2 days each to complete. If you did them one after the other, A will be finished by day 3, B by day 5, and C by day 7. AABBCC. Now suppose you want to satisfy the people who commissioned B and C that you’re paying attention to them, and you decide to multitask. So you decide to split things up, and work on them in one day blocks, ABCABC. The result is that now A is delivered on day 5, two days later than before, and B is delivered on d...

On Aug 4, 2008 I moved from Object Mentor where I was an Agile coach and mentor to various companies to Textura where I have been an internal coach and now am managing a team of developers. I realized that I need a new professional outlet now since I won't be filling up the pages of the Object Mentor blog. My friends recommended that I start working on personal branding by starting up an individual pro blog outside of my work environment. I will be writing from myself, and not from the point of view of any employer. Welcome to the result of that. Now I am working the agile transition from a whole different angle. Hopefully, this will be a great time of growth for me as well and I intend to blog my observations about agile practice as usual. I hope it will be a place where people can participate by giving me new observations, advice, and even possibly an occasional boot to the head. Enjoy. We will cover many miles together.