Agile Otter Blog

The excitement (aside from work and family travel) lately has been at Agile In A Flash , where we released a new blog and card which reveals a process for naming tests . After the naming papers I've written while at Object Mentor, and the chapter I supplied to Bob Martin's Clean Code  and the subsequent video episode , I am known as a "naming guy."  I'm expected to always have a choice name in mind, in line with my own naming rules , for any circumstance in which I might find myself. True to form, anyone pairing with me runs the risk of being exasperated at my constant two-step of "What's that for, really?" and "Can we rename it right now?" My coworkers are often surprised when they see me use a silly or meaningless name early in a test or body of code. Why would I not know exactly what to name a variable, class, method, or test? How is a test fixture not obvious to me from the very beginning? Roy Osherove , in initial shock at the...

It's official. Your Agile Otter has joined forces with Jeff Langr again, and we will be producing a new Pragmatic Programmers project.  This time it's really a book, not a deck of cards, but we will try to maintain the same level of imagination and insight.

In my agile training classes, I run an experiment wherein people try to estimate and deliver work in a very short time box. I typically run three iterations, so teams can learn from their experiences and experiment with different work styles. I do not give them guidance, but allow them to seek their own paths and then I tabulate the results. To the team with the highest "score" at the end of the iteration, I ask what their competitive advantage is -- how they managed to get more done than their peers. Oddly enough, the answers tend to be the same no matter whether I'm teaching programmers, test engineers, or high-level executives. Here is the summary: Teamwork. Pairing and tripling the people on a task means that more gets done sooner. Teams relying on individual work assignments consistently underperform compared with their teamwork-ing peers, and often deliver nothing at all until they also adopt team-based work. Smaller Tasks. Winning teams trim only st...

I was surprised to find that Jeff and I have been talking so much about testing over at Agile In A Flash . Jeff and I are quite emphatic about the importance of TDD and automated testing in general. Some of our most popular cards are about testing.  It shows our bias that a lot of the value of Agile methods are lived out in the elevation of testing to a first-class concern. We always want to know that our code works. We never want to be in the dark about it. Quality should be a given in an agile project. Heck, quality should be king in any project. High-quality, low-functionality enables iterative and incremental development whether the team is agile or not. We always want tests to set the goal for us. While the blog (and deck) are not just about testing, testing holds a special place in our minds and hearts. I guess it should not have been surprised at all.

I know it's going to sound like I'm trying to talk my boss and yours out of giving us both raises, and of course I'm not, but I keep hearing people tell me they're worried that they can't work in teams because their system pits them against one another. Usually it's an excuse or reason for not pairing. "If I improve my colleague, he will beat me to the incentives" or "if we do his work first, then there's a chance I'll fall behind."  I'm not a fan of individual work assignments , and I'm not a fan of competitive incentives . Rather than rant about it, I'd like to point you to some other authors and how they feel about the topic: Daniel Pink suggests killing your performance ratings . InfoQ balanced comments pro and con individual rewards. Peter Scholtes says reviews are  ineffective, even harmful  and performance appraisal are incompatible . Esther Derby suggests ways to support team-based work  and  performance ...

Did you watch Monty Python's The Meaning Of Life ?  There is a great scene that takes place in the Very Big Corporation of America, excerpted here: CHAIRMAN: ...Item six on the agenda: the meaning of life. Now, uh, Harry, you've had some thoughts on this. HARRY:  That's right. Yeah, I've had a team working on this over the past few weeks, and, uh, what we've come up with can be reduced to two fundamental concepts. One:  people are not wearing enough hats.  Two: matter is energy. In the universe, there are many energy fields which we cannot normally perceive. Some energies have a spiritual source which act upon a person's soul. However, this soul does not exist ab initio, as orthodox Christianity teaches. It has to be brought into existence by a process of guided self-observation. However, this is rarely achieved, owing to man's unique ability to be distracted from spiritual matters by everyday trivia. [pause] BERT: What was that about hats, again? T...

One day, a fish came to visit some kangaroos. He saw right away that the kangaroos spent all their time hopping on the dusty ground and browsing among the shrubs. Their habits would never work, and surely lead to their deaths, if they were to come to the ocean reefs even for a single month! "Foolish kangaroos," he called to them, "heed my words and live! This hopping and browsing is pointless madness! You must learn to paddle and snatch live prey from among the rocks! The ocean is no place for hopping air-breathing creatures, so come follow me and learn the better way!" The kangaroos, amazingly well-adapted to their un-ocean-ly environment, dutifully ignored the fish. They looked for common ground for conversation, but somehow the topic always turned to the futility of hopping and the unpleasantness of a dry environment. Sometimes they asked polite questions, and the patient among them tried to explain that their way of life was forever on solid ground whe...