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