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

I read somewhere that a large number of software teams think they’re Agile because they do Daily Scrums.

Now I don’t like to get religious, and I certainly don’t believe you have to follow some list of Ten Specific Practices to “Be Agile.” But I do think that sometimes companies get a little overly anxious to jump on the agile bandwagon and before we know it we’re regaled with horror stories of agile project failures. But were they really agile? Or were they just doing Daily Scrums?

What should you do if your company is trying to go agile? How can you make sure that – even if you’re not following some textbook-perfect definition – that you’re actually doing enough of the right stuff to reap agile’s benefits?

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

While I love to write, I occasionally prefer the role of reviewer or editor. I find it a nice break to sit on the other side and evaluate someone else’s work for a change. How much more comfortable to critique someone else’s product then to summon the courage to create something myself!

But how much easier would it be to create if we had a magical safety-net that guaranteed whatever we did would turn out well? How much more would we accomplish if we knew our every endeavor would be a success? Imagine a kick ass editor or, in software, a fabulous tester who had our back. Let’s call them Rumpelstiltskin. Able to take Garbage In, and turn Greatness Out.

We might find that the tables had turned. That the need for courage had passed from the creator to the tester. We only have to give them straw. They have to find a way to turn it to gold.

I have seen this happen on software projects, where the senior developers’ time has been deemed too valuable to "waste" on bug fixes. Have you seen this? A team of developers up in their ivory tower, banging out new features, while a test and bug team come in to clean up behind them. All so the senior folks can go work on the next big thing.

Read More…..