Last week, Moss Colum and Laura Dean gave the Boston Software Craftsmanship group a sneak peak of their Agile 2010 Pairing Games as Intentional Practice session. And, as a bonus, we got to try the games out during our code kata.

I know what you’re thinking, Abby, you’re a freakin’ geek. And I’m okay with that. But it was WAY fun so I wanted to share.

I love the premise behind this. A lot of us struggle when pairing with another person, so let’s create games we can play (intentional practice) to help us get better at the parts we’re struggling with.

I think we can learn not only how to pair better, but also how to incorporate games into our work as a way to continuously improve ourselves and how we collaborate with others.

Read More…..

A lot of people think Agile is about working faster, but that really isn’t right. It would be more accurate – and perhaps alleviate many of the arguments against agile practices – if we thought of agile as being about working slower because we’re being more deliberate. BUT, at the same time getting rid of all the crap that doesn’t add value, so that we do, indeed, end up delivering more functionality in a shorter period of time.

I like to think of Agile as the Just Do It methodology. In software development, we’re really great at this thing called “yak shaving.” If you’re not familiar with the term then take a moment to read: So There I Am, Shaving a Yak…. Go ahead, I’ll wait. It’s really funny, I promise.

“So there I was at the zoo, shaving a yak, all so I could take a few pictures of my dogs at the park.” – Bill Gaiennie

A really huge part of yak shaving – at least for me – is trying to figure everything out so that I can make sure I’m going about things the right way. Oh boy, I can plan and research and do proof of concepts like nobody’s business. But at the end of the day, I’ve got a bunch of “stuff” with no actual working software for the app I’m supposed to be building.

Agile instead says “You’re never going to know everything about the app until it’s already been written. Cope.” and instead gives us tools to continue to move forward by focusing on what we do know. And then, a funny thing happens. The more of the application that we build, the more we learn. And so, we’re able to move forward, not by focusing our time on what we don’t know, but rather by focusing on what we do know and building actual value out of it.

Read More…..

Goodness on the Internets:

An Open Letter to Micromanagers by Scott Berkun.

“Owners of thoroughbreds never stop their horses during a race, every ten seconds, to remind  the horse and jockey how to run, where the finish line is, or that it’d be a good idea to finish first. Why? It would slow them down. Only an idiot would do this…”

and so begins Scott’s letter to micromanagers everywhere. Complete with a link to anonymously send the letter to your favorite micromanager and signed, Hugs and Kisses, The People You are Micromanaging.  I love this guy.

TDD Triage.  Bob Martin addresses a number of questions around Test-Driven Development, hopefully dispelling some of the  religious extremist views on the topic and showing where TDD works and where it doesn’t. These include:

• Is TDD a replacement for architecture? (Nope)
• Is TDD a replacement for design? (Not even)
• Should TDD be used for every line of code? (Usually, but… actually, no)

How Nonsense Sharpens the Intellect. Alright, this is just awesome and reminiscent of Kathy Sierra’s suggestions to insert a little randomness into what we do. A NY Times article explains the science behind why nonsense and randomness actually help us understand things better. And, with that advice, I’ll end this here.

Bob Martin’s Craftsmanship and Ethics presentation is now freely available. Think of it as a 45 minute video on the key principles of agile programming. Or, if you’d prefer, a tutorial on how to become a professional developer.

As developers, our main product is our code. And, so, to be considered professionals, we must craft our product (code) in a disciplined manner. We should always, for example, check in the code a little cleaner then we found it so that our systems are always improving (as opposed to degrading). However, in this industry, one of our biggest problems is that we almost always check it in worse then we found it. Uncle Bob jokes,

"It’s difficult to call ourselves professionals when our primary outcome is a huge, stinking mess!"

"How many times have you been significantly slowed down by bad code? Martin asks and we can be sure all programmer hands went up. "Then why did you write it?" he asks. There is laughter because of the truth in his question. We have all been slowed by bad code and yet, we continue to allow bad code to be written on our projects. And why? Because we didn’t have time to write it well?

We fool ourselves into thinking we can defer the problems of bad code until later. But the problem is that the slow down is not something that occurs months from now, it’s immediate. "How many of you have stared at code you wrote 2 hours ago and thought, ‘what the hell does that do?!’"

"Bad code is not something that slows someone else down months from now. It slows us down immediately. We must not write bad code. Period. This is a fundamental issue of professional behavior."

And, so, Uncle Bob presents us with a number of principles we can follow if we want to become professionals. In doing so, he offers justification behind many of the agile practices – iterative development, pair programming, TDD, avoiding Big Up Front Designs (only Uncle Bob likes to call them "Turgid, Viscous Architectures"). And, what I think is arguably one of the most important lessons of agile, which is that "the only way to go fast is to go well."