Agile Otter Blog

I know it's simple, but why should it not be? Even simple things are hard. Reminder to self: don't skip three out of four boxes.

"Grandpa Tim, tell us about the old days." Grandpa Tim set aside his reading glasses and programming text. "Are you sure, children? It's nearly bed time. Maybe a story about ponies and puppies?" "No, Grandpa, we want to hear a scary story!" Tim looked around to be sure the lady of the house would not overhear and scold him for giving the little ones nightmares. "Very well," he sighed. "In the old, old, olden days programmers were isolated from each other by many barriers. Companies did not allow programmers in other companies to see their code, or to look at other companies' code. They built legal barriers and contracts that programmers had to sign if they wanted to make a living. This way, ideas could not be shared across company barriers. In many companies, they did not allow access to the internet for fear that ideas could escape from one company into another, or that people would spend time learning instead of typing....

Here are a few of the recommendations I've received: “Tim is the consummate software developer, with extensive knowledge and capability. I had the opportunity to pair with Tim many times over the course of year while at GeoLearning, and it was always the most enjoyable pairing session to look forward to. Tim is sharp, patient, knows how to explain things, and most importantly knows how to get things done. I'd pick Tim in a heartbeat for my "dream team" of developers.” J.L. February 1, 2011 “Tim deeply understands the fundamentals of agile, lean, and test-driven development and is able, like few others, to succinctly communicate their essentials in a practical, "this is how we're gonna do it" kind of way. Moreover, when reality and theory collide, Tim has the depth of understanding to help tweak and tailor practices and promote their implementation in way that meshes with an organization's existing culture/operations. If you want your d...

I've read some resume-writing tips and I've talked with good friends who have nailed a particular problem I'm having. I turn to my loving readership for general advice now. When reading a resume, I often see flashy hyperbole and unnecessary superlatives. I think "of course he's trying to make himself sound great, he wants something from me."  The more fantastically good the resume reads, the less I believe it.  I will be extra hard on people who sound like a combination of superman and Einstein, and might bypass them entirely and try to find someone more "honest." When writing a resume for myself, I strive to NOT trip that reflex. I write up my most satisfying successes as if they were workaday events, my biggest challenges as if they were normal problem-solving moments, and my best outcomes as if they were foregone conclusions.  I don't try to make it sound as if I did 8 impossible things before breakfast and had time for an extra scone, but...

I had a good morning conversation with some good people in twitter ( Jim Argeropoulos, Dean Goodmanson, others) about programmers and how many of them seem to have no real interest in the art/craft/vocation of programming. They tend to crank out the same code they did seven years ago, or longer, appending flags and if-then statements to masses of flags and conditionals, and never growing in their practice. I offered a metaphor of candles: A million candles, if not exposed to flame, will not light a room. For the symbolism-challenged, candles are people in the programming vocation and flame is an active interest (if not outright love) of the work we do.  Here is my extended analogy for your consideration: Burning Wicks are those who love programming and spend time learning, reading, studying, and improving their skills. They are contagious in their enthusiasm for better techniques and programming meta-considerations. They have done quite a bit of self-study, and have connect...

What would you say given only 60 seconds to answer:  What do you do?  Why did you start?  Why do you love it?  Why does it matter? You can make a 60-second (or less) film, answering these questions (or a subset thereof) for our collection. We hope to impact decision-making among young people, encouraging them to enter the software craft.  Can you help?

Thanks to George Dinwiddie and Mark Levinson and that marvel we call Twitter, your agile otter presents the worlds briefest summation of Agile: Do small things supremely well, and let them add up to large things. Use feedback to steer to the results you want. Defeat problems with teamwork. Maintain an even strain.

They're here! Now that I have extra decks of Agile In A Flash ,  I want to give them away in person as a door prize or in a contest of some sort.  The problem is that I'm located in the far NW 'burbs of Chicagoland.  I can get to Chicago or I can get to Milwaukee, maybe out to Rockland or some points in-between.  Invite me, and I'll see what I can do! I love hanging out with software developers of all types but prefer the meetings to be about agile, some programming language, or Linux.  I might even score some other goodies to hand out. Talk to me. If you want to talk to me about coaching your team, I might bring a copy to the interview, but I want the community to have dibs.