Agile Otter Blog

Some companies have wonderful, helpful, capable IT organizations. They are current with modern operating systems, networking, file sharing, caching and proxying, security, etc. They provide a high level of customer support to the business and software development. They rock, and work well with people. Other places, the corporate IT thinks they are  "the show" and the job of the organization is to follow their lead. They own the environment and are kind enough to allow developers and business to inhabit their world, provided they stay within the rules. Okay, that's unfair. It's often not really arrogance, it just seems that way from a distance. In reality, IT (especially corporate IT) can be a very insular world. They can specialize in the systems that the company used to have, and be open to extending -- say to the latest Micro$oft technologies -- but they just don't have any reason to know about OS X, Linux, Unix, or tablet devices. After all, everyone they k...

Over at Agile In A Flash blog, Jeff and I have announced a new contest called "Flash A Friend." You can win one deck for yourself, and another for a needy party you nominate. Winners will be chosen by purely subjective criteria, basically how much we are moved or intrigued by your nomination. Of course, the decks are also available at a reasonable price via pragmatic programmers .

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