Agile Otter Blog

It's a common thread in agile transitions that people are not sure what pairing, teamwork, and self-organization will do to their status on the team. Will the team be so leveled that nobody will stand out? Will the weak be exposed and humiliated? I am going to write this as if there were two states, strong and weak. Before reading anything that follows, remember that everyone is good in some areas and weaker in others. I have seen javascript gurus who weren't very database-smart, and people who were great with requirements and product knowledge but had no sense of scalability or performance. Any human characteristics are spectra, not point measurements. With that in always in mind, read on: There is good news, more good news, and some hard and potentially sad news in all of this. The first bit of good news is that nobody who works in an agile team ever asks these questions. In reality, it's not a problem. Let's get down to cases. Rockstars If you are the rock s...

This week I made some social networking advancements and started to build a few other new skills. The first is Tweet Feed which is likely responsible for you seeing this short article. I am not going to have to hand-tweet the AgileInAFlash or AgileOtter articles because they're auto-tweeted for me. The second is that blogger's admin screens let me turn on the social button bar after each article, so readers may more easily promote anything they find interesting or outrageous. It's a small thing, but already I've seen a new tweet from the page. It's a very small thing, but sometimes small things matter. I'm on ohloh now. My friend Sam Hart has prodded me a bit, and I finally realized he's right (it takes me a while sometimes) and I should take some credit for the work I've done in the public space, like the PDK. I never realized that I was the check-in leader there. Sam wants me to pick it up and make it a living project again, and I'm thinkin...

I have our first video finished.  Notice how my face never appeared.  I'm going to have to get used to hearing my voice on these, maybe I'll do the full-frontal face thing in one of the future videos. Either way, we now have a commercial that explains what this whole Agile In A Flash thing is about.

I have played with Django, but never really did any work in it. Even my toy app died before I got to a "good working model" state with it, because I did not maintain focus and wandered off too much. Since then I've developed a keen interest in learning more web technology, and so this time is Django Charge 2.0. I visited some very nice, very smart people this week to took me into their offices and showed me some of their Django code. We started to talk about testing, and I made a small abortive attempt to do some plain-old-unit-testing in their python code base. It was not all that I hoped it would be (Dean, please revert that code if you haven't already). I ran out of time to play, but hopefully will be back to enjoy some pair programming goodness in the near future. The cool and interesting bit about Django testing is that testing through manage.py will have you standing up an instance of the app complete with database. The setup is fairly onerous, but the t...

Today the deck is released for purchase. I'm getting tweets and messages from people who have either purchased the eBook or placed an order for decks. Thanks to everyone for their support in our crazy little project. So far many retailers are selling. Prag Prog Amazon O'Reilly Borders Buy.Com Deep Discount E Campus

The one thing I haven't said about my time as a remote pair programmer is that remote pair programming is a brilliant idea and it matters. The reason I didn't mention it there was because that was work. This is personal development. We improve our skills and our exposure in the world by pairing with more people. I've been a shy guy, not always jumping into the pairing sessions at conferences, and I'm the poorer for it. I could have been soaking up mojo from the greats instead of hiding out. But remote pairing? You are not in front of a whole bunch of strangers who are potentially judging you. You're in a one-on-one situation with someone you couldn't have visited personally due to any number of travel constraints. It's just the two of you and your headphones. You can work on your code, or the other guy's code, and it doesn't matter. It can be 6am or 2am or noon on a saturday, any time your schedules just happen to coincide. This is something ...

Being a telecommuter or remote team member is considered a pretty sweet deal and is recognized as a more "green" way of working. Remotes don't share illnesses with their teammates, and yet work when ill. Remotes don't participate in office gossip or struggle with personalities the way locals can. The perceived problem with remotes is that they are unmanaged (in fact, they are impossible to micro-manage effectively). The actual problem with remotes is that they can be disconnected. The solution to the perceived and real problem seems to be in the sweet spot of remote pairing. I was lucky enough to work for a few years as a remote pair-partner. As a remote, I worked common hours just as my peers did. I joined them in the morning, took lunch when they did, and worked until they went home in the evening. We spend most of the day on-camera together (or at least in voice via headsets), sharing the screen and development tools, writing tests and code, exploring technic...

People, software, and organizations often grow in this way: they accumulate without assimilating, and aggregate without integrating. As a result, they tend to be disconnected and fragmented and without a real focus or direction. In all three cases, it's amazing how functional they can be considering the shape they are in. Perhaps this is the different between innovative young companies and the well-worn thinking paths of large ones, between young turks and hold functionaries, between greenfield software and legacy. If so, then can we renew our creativity, youth, vigor, and clarity by ordering and integrating ourselves? I would like to believe it is so. The idea, alas, is too grand for me. It's out here now, and maybe it will spark something more easily grasped and leveraged.

I had some thoughts cross my mind today, and wanted to write them down before they fade. I'm of some reputation in the agile community, a sometimes-recognized author, a consultant (ex-of Object Mentor, ex-of CSC Consulting) and an agile coach. I've taught thousands of developers to program in C or C++ or Python, how to do TDD in many more languages, and the intricacies of object-oriented design. I've refactored horrible code and tested and built tools and transformed teams. I am also a 48-year-old man who needs to establish his personal brand. Many of us are introverts by nature, and those of us with rural, midwestern upbringing tend to self-deprecation. I've always found self-promotion abhorrent. Writing a promotional bio actually makes me a little sick at my stomach. The shame of it is that I could have learned to be comfortable with it a long time ago. If I had begun the push earlier and had some coaching I would have made some different technology and career c...

I wrote earlier about code being under test , and how advantageous to have a test "under" several layers of testing. As I was looking through my old google docs, I found this drawing I'd made to explain layers of testing in a web app. Terminology is catered to the audience of the time, and will probably confuse some. For instance "controller" here is really more like the "model" layer with its duty of acting as facade and moderator for underlying objects. Its purpose is primarily ensuring business rules and performing a single broad function that includes potentially many objects at the lower level. The "API" objects here are the business objects. Again, tailored to the local terminology. Apologies. Maybe the Agile Otter should redraw the whole thing sometime soon. Anyway... The idea is pretty simple, but sometimes people don't quite understand why the code-behind needs to be thin and why they shouldn't re-implement functio...

This is a limited time offer. If you would like to have The Agile Otter working for you, this might be your chance. If you are looking to expand your technical team or need an experienced Agile coach, feel free to drop me a line (tottinge@gmail.com) and we can talk through particulars. I can work as a remote pair-programming partner (tech team) or on-site in NW Chicago burbs (coaching).